Latencia de cola: qué es y cómo medirla
7 min de lectura
La latencia de cola es el tiempo de respuesta de las pocas peticiones más lentas, que suele darse como el percentil 99 o 99,9. Importa porque una acción del usuario a menudo espera a muchas peticiones, así que un retraso que afecta a 1 petición de cada 100 puede llegar a la mayoría de tus usuarios. Una prueba de carga que solo muestra la media o la mediana no la refleja.
| Llamadas al backend por página | Parte de las páginas con al menos una llamada lenta (1 de cada 100) |
|---|---|
| 1 | 1,0 % |
| 5 | 4,9 % |
| 10 | 9,6 % |
| 20 | 18,2 % |
| 50 | 39,5 % |
| 100 | 63,4 % |
La tabla supone que cada llamada es lenta con un 1 % de probabilidad, con independencia de las demás: la parte es 1 - 0.99^n.
¿Qué se considera la cola?
La cola es la parte de la distribución de tiempos de respuesta por encima de un percentil alto, casi siempre p99 y p99,9. La mediana describe una petición típica, y la cola describe las peticiones de las que se queja la gente.
Un percentil es un corte: p99 = 800 ms significa que el 99 % de las peticiones tardó 800 ms o menos y el 1 % tardó más. En un histograma de tiempos de respuesta, la cola queda a la derecha de ese corte, a menudo como un tramo largo y fino lejos del pico principal. Nuestra guía de rendimiento vs latencia explica cómo miden la latencia y los percentiles las herramientas de pruebas de carga.
¿Por qué importa tanto la latencia de cola?
Porque las peticiones se multiplican. Una página o una llamada de API que se reparte entre muchos servicios solo termina cuando responde el más lento, así que la cola de cada servicio se convierte en la experiencia típica del conjunto.
La referencia es «The Tail at Scale», de Jeffrey Dean y Luiz André Barroso, publicado en Communications of the ACM en 2013 (PDF del artículo, comprobado el 19 de octubre de 2026). Su ejemplo: un servidor que suele responder en 10 ms pero tarda un segundo en el percentil 99. Si una petición toca uno de esos servidores, 1 de cada 100 peticiones de usuario es lenta. Si tiene que reunir respuestas de 100 en paralelo, el 63 % de las peticiones de usuario tarda más de un segundo. Incluso con solo 1 llamada lenta de cada 10.000, un servicio con 2.000 servidores ve casi 1 de cada 5 peticiones por encima del segundo.
También publican mediciones de un servicio real de Google: el percentil 99 de una sola petición hoja era de 10 ms, pero llegaba a 140 ms hasta que terminaban todas las peticiones hoja, y esperar al 5 % más lento suponía la mitad de ese tiempo.
¿Qué causa la latencia de cola?
Sobre todo interferencias de otro trabajo en la máquina o en la red. La misma petición es rápida casi siempre y lenta cuando está pasando otra cosa.
Dean y Barroso enumeran los sospechosos habituales:
- Recursos compartidos: otro trabajo en la misma máquina que compite por núcleos de CPU, cachés del procesador, ancho de banda de memoria o de red.
- Demonios en segundo plano que se despiertan y se llevan una parte de la máquina.
- Tareas de mantenimiento como la compactación de registros o la recolección de basura en entornos gestionados.
- Colas en servidores y conmutadores de red, que amplifican todas las demás fuentes.
- Límites de potencia y temperatura que frenan una CPU tras un pico de trabajo.
En las pruebas de carga, la misma lista aparece como pausas de GC en servicios JVM o Node.js, un pool de conexiones agotado, una consulta lenta a la base de datos que solo disparan algunas peticiones, cachés frías tras un despliegue y reintentos después de un timeout. Una cola que crece con la carga apunta a colas de espera; una cola presente incluso con poca carga apunta a algo periódico, como el GC o una tarea programada.
¿Cómo se mide la latencia de cola en una prueba de carga?
Reúne suficientes muestras, pide a tu herramienta los percentiles adecuados y nunca promedies percentiles entre máquinas o ventanas de tiempo.
Suficientes muestras. El p99 lo decide el 1 % más lento de las peticiones, así que una ejecución de 500 peticiones lo apoya en 5 de ellas. Para un p99 estable necesitas miles de peticiones por transacción, y para el p99,9 decenas de miles. Las pruebas de humo cortas sirven para detectar errores y poco para juzgar la cola.
Los percentiles adecuados. Los valores por defecto suelen quedarse antes de la cola. En k6, summaryTrendStats es por defecto avg,min,med,max,p(90),p(95), así que el p99 solo aparece si lo añades (referencia de opciones de k6, comprobada el 19 de octubre de 2026):
k6 run --summary-trend-stats="med,p(95),p(99),p(99.9),max" \
script.js
El Aggregate Report de JMeter muestra las líneas del 90 %, 95 % y 99 %, y las propiedades aggregate_rpt_pct1 a aggregate_rpt_pct3 cambian qué percentiles aparecen (comprobado el 19 de octubre de 2026).
Nada de percentiles promediados. El p99 de una ejecución completa no es la media de los p99 de cada minuto ni la de los p99 de cada generador de carga. Junta las muestras en bruto o un histograma y calcula el percentil una sola vez. El artículo sobre coordinated omission trata HdrHistogram, la herramienta habitual para eso, y una segunda trampa: un generador de carga que espera las respuestas lentas envía menos peticiones mientras el sistema va lento, y esconde justo la cola que buscas.
LoadFocus, que publica este sitio, muestra en cada ejecución las tarjetas P95 y P99, un histograma de tiempos de respuesta construido a partir de las muestras individuales y las peticiones más lentas, de modo que una cola larga a la derecha del pico se ve de un vistazo.
¿Cómo se fija un límite de aprobación para la cola?
Pon un límite al p99 de cada transacción clave, junto a un límite de p95 y otro de tasa de errores. Básalo en lo que necesitan los usuarios de esa transacción y haz que la ejecución dure lo suficiente para que el p99 sea estable.
Un conjunto razonable para una API de pago podría ser: p95 por debajo de 400 ms, p99 por debajo de 1.200 ms y errores por debajo del 0,5 %. En k6 son umbrales sobre http_req_duration como p(99)<1200, y un umbral superado hace que k6 termine con un código distinto de cero (umbrales de k6, comprobado el 19 de octubre de 2026). LoadFocus tiene un campo Max P99 response time junto a Max P95 para pruebas cloud, JMeter y k6, y cada ejecución recibe entonces un PASS o un FAIL. Nuestra guía de criterios de aprobación en pruebas de carga cubre el resto del conjunto.
Si además informas de una puntuación Apdex, recuerda que mete toda petición por encima de cuatro veces T en la misma franja, así que no distingue una cola de 2 segundos de una de 30. El p99 sí.
¿Cómo se reduce la latencia de cola?
Elimina las fuentes de variabilidad donde puedas y diseña los clientes para que una llamada lenta no retenga toda la respuesta.
Arreglos habituales, más o menos del más barato al más costoso:
- Ajusta el GC y el tamaño de los pools para que las pausas y la espera de una conexión libre sigan siendo cortas bajo carga.
- Deja margen. Las colas de espera crecen de golpe cerca de la saturación, así que la capacidad libre acorta la cola; la guía de rendimiento vs latencia muestra cómo encontrar el codo.
- Pon timeouts y limita los reintentos para que una llamada atascada falle rápido en lugar de acumular todo lo que viene detrás.
- Usa peticiones de cobertura (hedged requests) en lecturas idempotentes: envía una segunda copia a otra réplica si la primera no ha respondido a tiempo. Dean y Barroso describen enviar la copia solo después de la latencia esperada del percentil 95, lo que limita la carga extra a un 5 % aproximadamente. En una de sus pruebas, una copia enviada a los 10 ms bajó el percentil 99,9 de 1.800 ms a 74 ms con solo un 2 % más de peticiones.
- Reduce el fan-out. Menos llamadas al backend por página significa menos ocasiones de caer en la cola, como muestra la tabla del principio.
Tras cada cambio, repite la misma prueba con el mismo perfil de carga y compara p99 y p99,9 entre ejecuciones.
FAQ
¿La latencia de cola es lo mismo que el p99? El p99 es la forma más común de expresarla, y la cola es todo el extremo lento de la distribución. Sigue también el p99,9 y el máximo cuando la ejecución tenga suficientes peticiones.
¿Por qué mi p99 es tan superior a mi media? Porque unas pocas peticiones lentas apenas mueven la media y definen por completo el p99. Una diferencia grande es normal; una diferencia que crece con la carga suele indicar colas de espera.
¿Cuántas peticiones necesito para medir el p99? Como mínimo unos miles por transacción, para que el p99 se apoye en decenas de peticiones lentas. Para el p99,9, cuenta con decenas de miles.
Lecturas relacionadas
- Coordinated omission: qué es y cómo evitarla
- Rendimiento vs latencia: cómo se relacionan bajo carga
- Puntuación Apdex: qué es y cómo se calcula
- Criterios de aprobación en pruebas de carga: cómo fijarlos
- Ley de Little en pruebas de carga: dimensionar y comprobar
- YCSB: cargas de trabajo A-F, ejecución y límites
- SLO vs SLA: diferencia, SLI y presupuesto de error
Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.