Sitio web lento, servidor inactivo: encontrar adónde va el tiempo

Por qué la base de datos es la sospechosa habitual

Cuando una página se ralentiza, la base de datos es donde el síntoma se hace visible primero. Las conexiones se acumulan, la lista de procesos se llena de consultas en estado sending data, y el slow query log empieza a crecer. Todo eso es real, y nada de eso dice adónde fue el tiempo. La base de datos está al final de la mayoría de las rutas de petición. Una página que la llama doscientas veces en lugar de dos, un worker que mantiene una conexión abierta mientras espera a una pasarela de pago, una caché que se está saltando en cada acceso: cada uno de ellos aparece como carga de base de datos, porque la base de datos hace exactamente lo que se le pide, más veces de las que debería pedírsele.

Lo mismo vale para el servidor. Una máquina con carga alta es una máquina a la que se le está dando trabajo. Si el trabajo es necesario es una pregunta que la gráfica de carga no puede responder.

Trace una petición, no todo el sitio

El método es elegir una URL lenta y seguirla por los niveles, midiendo en cada frontera. Empiece desde fuera, desde una máquina que no esté en la misma red, y deje que curl informe de adónde va el tiempo antes de que llegue el primer byte.

$ curl -o /dev/null -s -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' https://www.example.com/slow-page

Si el tiempo hasta el primer byte es la mayor parte del total, la espera está en el lado del servidor. Si el total es mucho mayor que el tiempo hasta el primer byte, la página es pesada o la ruta entre el visitante y el borde es la historia, y el servidor no formó parte de la espera.

En la máquina, muestree la CPU mientras la petición lenta está en curso, no una hora tranquila después.

$ mpstat -P ALL 1 5
$ vmstat 1 5

Un servidor mayormente inactivo durante una petición lenta, sin iowait y sin steal, se ha exonerado a sí mismo. El tiempo se está gastando esperando a algo, no computando.

Después la aplicación. La mayoría de los frameworks pueden registrar, por petición, el número de consultas emitidas, el tiempo total pasado en ellas y el tiempo pasado en llamadas HTTP salientes. Actívelo para la URL lenta. Dos números zanjan la discusión: cuántas consultas emite una página, y cuánto del tiempo de reloj se pasó completamente fuera de la aplicación.

Por último la base de datos, con el slow query log activado y el umbral lo bastante bajo como para capturar lo que importa.

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.2;
SET GLOBAL log_queries_not_using_indexes = ON;

Lea el registro para la ventana de la petición lenta. Un puñado de consultas que tardan segundos cada una es un problema de base de datos. Miles de consultas que tardan un milisegundo cada una es un problema de aplicación del que se está culpando a la base de datos.

Los patrones que salen de la medición

Con los niveles separados, la causa tiende a tomar una de unas pocas formas.

Un endpoint llamado en bucle. Un front end que vuelve a pedir el mismo recurso en cada cambio de estado, o una página que emite una consulta por fila en lugar de una consulta por página. La base de datos responde rápido a cada llamada; el problema es la cantidad.

Una llamada síncrona a otro. Un proveedor de pagos, un ERP, una API de envíos, un gestor de etiquetas, sentados en la ruta de la petición detrás de un timeout largo. El servidor está inactivo durante toda la espera, y la página es tan lenta como el tercero más lento del que depende.

Una caché que se está anulando. Cabeceras que prohíben la caché en páginas que no cambian, o ninguna caché de borde delante de tráfico anónimo que nunca fue dinámico.

Pools dimensionados a ojo. Pools de workers, de conexiones y de buffers configurados demasiado grandes tan a menudo como demasiado pequeños. Un pool mucho mayor de lo que la máquina puede servir de forma concurrente convierte una cola en un thrashing.

El agotamiento real es la última forma, y cuando aparece suele estar aguas abajo de una de las tres primeras. Que la máquina se quede sin algo es el final de la historia, no el principio.

Qué cambia un servidor más grande

Añadir núcleos o memoria acorta la parte de la petición que estaba computando. Si esa parte ya era pequeña, la página no se vuelve más rápida; la espera se traslada con ella. El bucle sigue en bucle, el tercero sigue tardando lo suyo, la caché sigue anulada. La ampliación además esconde la medición que habría encontrado la causa, porque la gráfica que estaba en rojo ahora está en ámbar, y el ticket se cierra.

Por eso trazamos antes de presupuestar. Una plataforma sana se mantiene aburrida, y el trabajo consiste en encontrar el nivel al que pertenece el tiempo, incluso cuando ese nivel está por encima de todo lo que operamos, y en devolver la medición que señala la línea.