El APM de New Relic nos permite conocer el rendimiento de nuestra aplicación PHP en tiempo real, compararlo con el histórico y ver tendencias y desviaciones. Esta visibilidad es especialmente útil a la hora de identificar problemas de rendimiento en entornos de producción, que generalmente son difíciles de reproducir en un entorno controlado.
El APM de New Relic se instala como un módulo de PHP en los servidores web y registra información sobre el rendimiento interno de la aplicación. Esta información se envía a la infraestructura de New Relic, en donde se analiza, procesa y presenta a través de su sitio web.
¿Cómo nos ayuda New Relic?
New Relic nos presenta un resumen general en el que consultar la salud general de la aplicación de un vistazo. Podemos seleccionar el período de tiempo que nos interese en cada momento.
De un vistazo podemos ver los tiempos de respuesta, el apdex (que mide la satisfacción del usuario con los tiempos de respuesta), el número de peticiones por minuto (throughput) y los errores.
En esta gráfica de las últimas 24 horas, vemos como durante la mañana se produjeron importantes incremento en los tiempos de respuesta de la web. El primero pico se produce entre las 8:40 y las 8:50 y luego un segundo pico entre las 10:50 y las 11:15. En este primer vistazo podemos parece que el mayor incremento se produce en las respuestas del servidor MySQL (la parte amarilla del gráfico).
- External Services
Aunque en este caso particular, la causa principal parece la base de datos, también podríamos revisar si la lentitud se debe al mal funcionamiento de un servicio externo al que consulte nuestra aplicación.
En la sección external services, vemos un listado de los tiempos de respuesta de las peticiones a servicios externos:
En este caso no vemos ningún pico en las horas en las que se han registrado los problemas. Aún así es interesante comenzar descartando esto, ya que en nuestra experiencia nos hemos encontrado varias veces con llamadas a servicios externos que causan problemas de rendimiento.
Por ejemplo en en otro caso anterior, vemos un incremento en los tiempos de respuesta en la página principal de Newrelic. Aquí el MySQL no parece ser la causa del problema:
Al revisar la sección «External Services», comprobamos que el incremento de los tiempos de respuesta coinciden con la subida en los tiempos de respuesta de un servicio externo:
Pero continuemos revisando el caso inicial: descartados los servicios externos, pasamos a revisar las transacciones, que es una de las secciones que nos dan la información más útil.
- Transactions
Aquí encontramos información sobre las transacciones que mayor impacto tienen en el rendimiento. En primer lugar, nos presenta un resumen de los tiempos de las transacciones, ordenador por su impacto global, aunque también los podemos ordenar por el tiempo de ejecución.
El primer método, nos muestra las transacciones que más afectan al rendimiento, y puede ser muy útil para tener una idea de en qué secciones centrarse a la hora de optimizar el rendimiento de forma general.
Si ordenamos por «slowest average» podremos buscar que la transacción más lenta independientemente de la frecuencia con la que se ejecute, como podría ser una sincronización de productos, una ordenación de un listado en el admin, etc.
Seleccionando una transacción lenta (en este caso una parte del proceso de pago) se abre una nueva sección con información sobre el rendimiento de la transacción durante el período de tiempo seleccionado.
Otro dato importante aquí, es la media de cuanto consume de media cada operación interna de la transacción y el número de veces que se ejecuta, que también es importante ya que también es habitual que los problemas de rendimiento se den debido a bucles más grandes de lo esperado.
Además, disponemos de un listado de transacciones individuales «lentas», que nos será muy útil para saber que ocurre con estas peticiones individuales. Si seleccionamos una de ellas (la que más tiempo haya requerido), podemos ver de forma gráfica las operaciones que se han realizado y sus tiempos.
Lo que vemos en esta transacción refuerza la opinión inicial de que el cuello de botella se genera en MySQL, sin embargo no afecta a todas las consultas: Vemos que los select a la tabla customer_entity_varchar (una tabla estándar de magento2), ocupan el 96% del tiempo de ejecución de la petición, siendo los tiempos de respuesta del resto de consultas muy inferiores.
Con esta información, parece probable que la tabla se encontrase bloqueada en ese momento, y este bloqueo evitase el correcto funcionamiento de varias secciones de la web.
Para saber a que partes afectaría un bloqueo de esta tabla, abrimos la sección Databases, y seleccionamos la consulta catalog_product_entity_varchar
y podemos ver cuáles son las principales transacciones afectadas por el bloqueo:
En este caso, el próximo paso sería revisar los trabajos programados que estaban en ejecución en el momento del problema, en busca de alguno que manipule la tabla catalog_product_entity_varchar o alguna tabla relacionada.
