Servidor o aplicación: cómo se mide el cuello de botella

Tiempo hasta el primer byte en cada salto

Las teorías sobre un sitio lento se forman con facilidad y se zanjan con dificultad. Tres mediciones las zanjan. Tome el tiempo hasta el primer byte a través del edge público, otra vez directamente contra el origen saltándose el edge, y otra vez en el host de la aplicación contra localhost. La diferencia entre dos lecturas adyacentes es el coste de esa capa.

# through the edge
curl -s -o /dev/null -w 'dns=%{time_namelookup} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://site.example/

# direct to the origin, edge bypassed
curl -s -o /dev/null -w 'ttfb=%{time_starttransfer}\n' --resolve site.example:443:ORIGIN_IP https://site.example/

# on the host, nothing in front of the application
curl -s -o /dev/null -w 'ttfb=%{time_starttransfer}\n' http://127.0.0.1/

Lo que queda en localhost es la aplicación y los servicios a los que llama. La capa con el mayor hueco es adonde va el resto del trabajo.

Margen mientras duele

Lea los contadores durante el período lento, no después.

vmstat 1 5        # r (run queue), wa (I/O wait), st (steal), id (idle)
iostat -x 1 5     # await and aqu-sz per device
free -m           # the available column, not used

Una run queue larga con poco idle es una máquina limitada por CPU. Un I/O wait alto con await alto en el dispositivo es storage. El steal es un vecino en un hipervisor compartido llevándose ciclos que el guest quería. CPU ociosa, memoria disponible y dispositivos con await bajo debajo de un sitio lento significan que la máquina espera algo que no es suyo: una llamada externa, un lock, una consulta lenta por razones distintas del hardware. Añadir hardware en ese punto produce una máquina más ociosa que sigue lenta.

Hay una tercera categoría entre las dos, y es frecuente: el pool. La página de status de PHP-FPM muestra una listen queue. Una cola de peticiones en espera con CPU ociosa significa que todos los workers están ocupados, normalmente bloqueados en la misma llamada lenta, y el sitio es lento por un techo de configuración y no por un techo de recursos. La misma forma aparece como un pool de conexiones a la base de datos saturado o como una cola de backend llena en HAProxy. La máquina es inocente y el código aún no ha sido condenado. El tamaño del pool y la llamada a la que espera son las dos lecturas siguientes.

Lea el tráfico antes que el código

El access log dice qué clase de problema es este. Encuentre primero el log por vhost. El log por defecto puede contener una pequeña fracción del tráfico real, y un recuento sobre el archivo equivocado da una respuesta equivocada con toda seguridad.

tail -n 100000 access.log | awk -F'"' '{print $2}' | sort | uniq -c | sort -rn | head

Unas pocas URL repetidas miles de veces son el sitio llamándose a sí mismo, y la solución es una cache delante de esas URL. Peticiones que avanzan en el orden del sitemap son un crawler, y la solución es un rate limit. Una subida amplia y uniforme en muchas URL es demanda, y la solución es capacidad.

Colapse el slow log y el log de consultas

Un slow log es un montón de stack traces hasta que se indexa. Active el slow log de PHP-FPM con un umbral que capture las peticiones de las que se quejan los usuarios, después agrupe cada trace por el frame en el que quedó bloqueado, la hoja, y cuente. La lista ordenada es corta y en lo alto suele haber una llamada externa o una consulta.

En el lado de la base de datos, ordene por digest, no por plan. La parametrización inconsistente parte una consulta lógica en muchos planes que parecen inofensivos uno a uno. Sumado por digest, el verdadero dueño del tiempo de la base de datos se reensambla en una sola fila.

-- MySQL and Percona: by statement digest
SELECT digest_text, count_star, sum_timer_wait
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC
LIMIT 10;

-- SQL Server: by query hash
SELECT query_hash, COUNT(*) AS plans, SUM(total_worker_time) AS cpu
FROM sys.dm_exec_query_stats
GROUP BY query_hash
ORDER BY cpu DESC;

Antes de escribir cualquier índice, verifique el recuento real de filas y los índices que ya existen. Un índice en una tabla que no lo necesita es una ruta de escritura más lenta.

Lea la fuente primaria, no una historia plausible

Cada fila sustituye una teoría por una lectura. La última importa en un sistema en enforcing: el log de auditoría responde a la pregunta sin cambiar la postura de seguridad para hacerla.

Demuéstrelo, después verifique con la misma medición

La correlación da un sospechoso. Una perturbación pequeña y reversible lo condena: detenga las consultas sospechosas durante unos segundos y observe si la carga se rellena. Si se rellena de inmediato, el tráfico en vivo es el motor y la solución pertenece al edge, delante de las peticiones que no deberían llegar siquiera a la base de datos. Hasta que se conoce la causa, el sistema es de solo lectura. Cuando la solución está puesta, se verifica con la medición que encontró el problema: si el tiempo hasta el primer byte por salto lo localizó, el tiempo hasta el primer byte por salto confirma que ha desaparecido.

Qué arreglamos y qué devolvemos

No cambiamos su código. Nombramos la línea, mostramos la medición que la señala y mantenemos el sitio en marcha mientras usted la corrige.