Misterios de desarrolladores anteriores — una historia frecuente sobre problemas de coste y rendimiento
Un día, hablando con un cliente, surgió un tema que, sin importar quién sea el cliente, siempre acaba apareciendo:
- ¿Por qué nuestros sistemas van más lentos que antes? ¡No hemos cambiado nada!
- ¿Hay algo que podamos hacer para dejar de acumular problemas y optimizar costes además de mejorar el rendimiento?
A veces los problemas se ven a simple vista, y otras veces son bastante difíciles o se consideran imposibles porque demasiada gente ya los ha investigado y no había una explicación sencilla más allá de “estáis ejecutando un monolito” o “deuda técnica”. Esa era la respuesta por defecto hasta que conocí Datadog, APM y su Profiler.
Hoy os voy a mostrar un caso de uso muy claro de cómo la combinación APM+Profiler puede señalarte la línea exacta que causa un problema que ni siquiera esperabas que fuera el verdadero culpable. Una sola función tan poco optimizada que, al corregirla, hizo que toda una tienda multinacional experimentara una reducción de ~50% en las latencias
Este cliente en particular ejecuta una tienda Magento bastante personalizada con muchos plugins, lo cual no parece nada fuera de lo común. Tienen millones de productos, de los cuales recientemente han hecho cambios en los inventarios y ahora Google solicita casi 20 mil peticiones de productos sin caché por hora como carga sostenida durante varios días — pronto serían semanas. El crawler de Google Search y Google Merchant estaban golpeando con mucha fuerza. La infraestructura tuvo que escalarse considerablemente para soportar ese pico de tráfico, y había que hacer algo para mejorar el rendimiento además de no estar permanentemente sobreescalados y pagando de más hasta que Google terminara su rastreo.
Entonces, ¿qué viene ahora? Ya sabíamos lo que Google estaba haciendo gracias a todos los logs de nginx exportados: la página de productos tenía que ser revisada (nunca mejor dicho).
Así es como se veía una traza normal de producto (sin las consultas a la base de datos o se vuelven muy ruidosas), con el p50 alrededor de 3.8s (podéis ver que la captura actual equivale a un p71):
Esa plantilla del header que se está construyendo parece muy sospechosa. No debería tardar tanto, y el uso de CPU está claramente al 100% durante esa función. ¿Qué puede hacer el profiler por mí aquí? ¡Ya veo que el header es el problema! — ¿O no lo es? — Con un clic en “Open in Profiling” puedo saltar a una explicación más detallada de esa petición específica sobre qué funciones, namespaces, librerías… el código ejecutó durante ese tiempo - sin necesidad de instrumentación personalizada.
Claramente hay un bucle, un bucle muy grande, haciendo algo que los mejores de nosotros adivinaríamos que podría mejorarse fácilmente. Y recordad, ahora podemos ver las líneas individuales que desencadenaron todo (lo cual todavía me deja alucinado).
Resultó ser una simple comprobación que se hacía sobre cada plugin instalado en ese sitio hasta encontrar un plugin y versión específicos — lo cual habría causado cada vez más problemas a medida que el sitio escalara. La comprobación se cambió por una simple consulta a la base de datos preguntando lo correcto en lugar de recorrer todos los plugins.
¿Todo ese preámbulo solo para esto?
Aquí viene la parte buena. Esto es el header. Esto no solo mejoró la página de producto, sino todo el sitio.
Este es el flame graph corregido actual para el mismo catalog/product/view
Las flechas muestran la misma parte del header seleccionada. Sí, el código hace exactamente lo mismo. ¡Y hemos reducido el tiempo de respuesta a un p50 de 1.9s!
Aquí podéis ver la diferencia drástica del p95 en los tres endpoints principales: productos, categorías y búsquedas (por favor, ignorad la reconstrucción de índices de búsqueda durante la noche).
Y así es como se ven las métricas internas del profiler de PHP:
Las líneas grises representan el mismo punto en el tiempo, días antes y el día siguiente. Esto muestra un claro descenso en la asignación de memoria así como en el uso de CPU, liberando recursos literalmente a la mitad y permitiendo el doble de ancho de banda dentro de la misma capacidad de infraestructura, ahorrando una buena parte de la factura de AWS (sin contar las bases de datos, pero os hacéis una idea).
La integración de Datadog APM+Profiler con PHP así como con otros lenguajes es un simple flag de on/off. El esfuerzo es mínimo, y proporciona una visibilidad clara de cómo se están utilizando tus recursos, ayudándote a mejorar el rendimiento, reducir costes, mejorar la estabilidad, el SEO y la experiencia de usuario en general.
¿A qué estás esperando?
Regístrate hoy y diles que viste este post.
Para dar contexto a quienes no me conocen, trabajo como Consultor Independiente de servicios IT. Mi enfoque principal es DevOps/SRE, y mi querido amigo y navaja suiza es Datadog, quienes orgullosamente me nombraron como uno de sus Ambassadors. Ayudo a empresas a implementar sistemas escalables y fiables así como a adoptar la cultura de Observabilidad. ¡No dudes en contactarme si estas cosas suenan bien para tu empresa!