Rendimiento y escalado en Laravel

El trabajo de rendimiento tiene un final previsible. Un sprint se va en optimización, las gráficas bajan, y mes y medio después están exactamente donde empezaron. Los arreglos no estaban mal. No había nada que los sujetara en su sitio.

Cómo transcurre un encargo

Medir primero, desde producción. Tráfico real, muestreado, segmentado por endpoint. Un p95 de 2,4 segundos en el listado de pedidos es una afirmación accionable; «la aplicación va lenta» no lo es, y tampoco un perfilado hecho en una máquina de desarrollo contra una base de datos sembrada.

Encontrar la causa, no el síntoma. Un endpoint lento en Laravel es casi siempre una de cinco cosas: el número de consultas, una sola consulta sin índice utilizable, trabajo que debería haberse encolado, una llamada a un tercero en la ruta de la petición, o la serialización de muchos más datos de los que la respuesta necesita. Trazamos cada una hasta la línea que la produjo.

Arreglar al nivel correcto. Mover trabajo a una cola, añadir el índice que el plan de la consulta quiere de verdad, cargar la relación por adelantado, sustituir una tubería de colecciones por un agregado, cachear un valor cuyo coste justifique de verdad el problema de invalidación que crea. Estos son los cambios que se sostienen.

Defender el resultado. Un presupuesto en CI: una aserción sobre el número de consultas en los endpoints que importan, y un build que falla para el pull request que lo supere. El presupuesto es el entregable; la gráfica es un efecto secundario.

Por qué vuelve la gráfica

Porque una gráfica es un resultado y de un resultado no es dueño nadie. Un presupuesto es una cifra dentro de una prueba, comprobada por una máquina, en cada pull request, y hace fallar el build de quien lo superó mientras todavía recuerda qué cambió.

Por eso la mayoría de los clientes no nos necesitan una segunda vez para esto. Optimizar sin presupuesto es endeudarse contra el trimestre siguiente: la misma relación pierde su carga anticipada en silencio, el mismo informe gana una columna más que resulta ser un accessor con una consulta detrás, y la regresión llega un commit razonable cada vez, de gente que no tenía forma de saberlo.

Adónde se va el tiempo en realidad

Ordenado por la frecuencia con que es la respuesta:

La base de datos. Normalmente el número de consultas y no una consulta concreta, y por eso es un encargo propio cuando es el problema entero y no una parte de él.

Trabajo que no debería estar en la petición. Un PDF renderizado, una imagen redimensionada, un webhook entregado, un informe generado. Cada uno de ellos pertenece a una cola, y moverlos suele ser la mayor mejora disponible.

Un tercero en la ruta crítica. Una búsqueda de direcciones, un servicio de impuestos, la llamada de estado de un proveedor de pagos. Su latencia es su latencia, su caída es su caída, y ninguna de las dos se ve en su propio perfilado hasta que las busca.

La serialización. Un endpoint que devuelve doscientos campos porque el resource se escribió como «todo lo del modelo», hidratando relaciones para producir una lista de nombres.

La caché usada como parche. Cachear no es gratis: compra velocidad con obsolescencia, y una aplicación con una docena de claves de caché inconexas y ninguna estrategia de invalidación ha cambiado un problema de rendimiento por uno de corrección.

Escalar, una vez que es eficiente

Solo entonces la infraestructura es la respuesta, y el orden importa: una aplicación ineficiente escalada horizontalmente es una aplicación ineficiente por la que paga varias veces.

Cuando está justificado, el trabajo son réplicas de lectura con el enrutado decidido de forma explícita y no global, almacenes de sesión y caché que no sean la base de datos principal, workers de cola escalados por separado de la capacidad web porque fallan de otra manera, y un despliegue que no tira el trabajo en vuelo. Octane donde la medición diga que el arranque del framework es de verdad una parte significativa de la petición, que es menos a menudo de lo que sugiere su reputación.

Qué recibe

Un documento de hallazgos priorizado con cada problema trazado hasta su causa y dimensionado por esfuerzo, los arreglos implementados como pull requests revisables, la configuración del presupuesto en CI, y una comparación de antes y después contra tráfico de producción una vez que el cambio lleve el tiempo suficiente en vivo como para significar algo.

Cuando el techo resulta ser la propia arquitectura —que pasa— los hallazgos lo dicen y ponen una cifra a la alternativa al lado. Esa es una conversación para la semana uno y no para el resumen de cierre.