¿Qué es latencia?

¿Qué es latencia?

Latencia es el tiempo entre que un cliente envía una petición y recibe el primer byte de respuesta. En un contexto web eso significa: el usuario hace click, el browser envía una petición HTTP, el server la procesa, la respuesta empieza a llegar. El reloj de ese round-trip es la latencia, normalmente expresada en milisegundos.

El número end-to-end esconde una pila de piezas contribuyentes: DNS lookup, TCP handshake, TLS handshake, procesamiento server-side (código de aplicación, query a base de datos, llamada a API downstream), transmisión de respuesta. Una latencia de 600 ms podría ser 50 ms de DNS, 80 ms de TLS, 400 ms de procesamiento server y 70 ms de retorno de red. Encontrar la pieza lenta es el trabajo de performance engineering.

Latencia vs throughput

Dos métricas, a menudo confundidas, que miden cosas diferentes:

• Latencia: cuánto tarda una sola petición. Medida en milisegundos. Mejorar latencia hace peticiones individuales más rápidas.
• Throughput: cuántas peticiones procesa el sistema por unidad de tiempo. Medido en RPS (peticiones por segundo). Mejorar throughput significa que el sistema sirve más usuarios sin frenarse.

Son independientes. Un sistema puede tener baja latencia y bajo throughput (rápido para un usuario, se cae a 100 usuarios). Puede tener alta latencia y alto throughput (un pipeline batch que procesa millones de registros por segundo pero tarda minutos por registro). Los sistemas de producción necesitan ambos.

Latencia y throughput se intercambian bajo carga. Añade más usuarios concurrentes a un sistema a capacidad fija y la latencia sube al contender los recursos. La forma de esa subida es lo que load testing, capacity testing y scalability testing miden.

Por qué los promedios engañan

La latencia promedio esconde la cola. Si 99 peticiones devuelven en 100 ms y una tarda 30 segundos, el promedio es 400 ms. Suena bien pero mapea a un usuario real esperando 30 segundos. Los percentiles arreglan esto:

• p50 (mediana): la mitad de las peticiones son más rápidas. Útil como sanity check, inútil para SLOs.
• p95: el 95% de las peticiones son más rápidas. El umbral SLO de latencia estándar.
• p99: el 99% de las peticiones son más rápidas. Caza la cola de outliers lentos que p95 esconde.
• p99,9 / max: el peor 0,1% de las peticiones. A menudo dominado por pausas GC, contention de locks, cache misses fríos. Importa para sistemas high-traffic donde 0,1% son millones de usuarios.

Cualquier informe de load test creíble muestra percentiles, nunca solo promedios.

Fuentes de latencia

1. Red. Distancia geográfica, tiempo de resolución DNS, handshake TCP / TLS. Un RTT de 100 ms de US a Europa es física; el round-trip no puede ser más rápido que la luz por el cable. Los edges CDN reducen esto sirviendo desde una location más cercana.
2. Procesamiento server-side. Código de aplicación, queries de base de datos, llamadas a API downstream. Normalmente la fracción más grande. Perfila para encontrar la pieza lenta.
3. Garbage collection / pausas de runtime. Pausas GC de JVM, pausas STW de Go, contención GIL de Python. Visible en colas p99+ como ráfagas de peticiones lentas.
4. Contención de recursos. Esperas en pool de conexiones de BD, contención de locks, backlogs de cola. La latencia escala bruscamente cuando la contención toca saturación; ese es el codo en la curva del load test.
5. Renderizado client-side. TTI (time to interactive) del browser incluye parse JS, hidratación, render. No latencia en el sentido API pero importa para velocidad percibida por usuario.

Cómo medir latencia

La latencia la reporta cada herramienta de load testing. En k6, la métrica integrada http_req_duration reporta p50, p95, p99 por defecto; añade thresholds: { http_req_duration: ['p(95)<500'] } para fallar el test si p95 excede 500 ms. En JMeter, el listener Aggregate Report muestra promedio, mediana, p90, p95, p99.

Para latencia de producción, instrumenta el server con APM (Datadog, New Relic, Honeycomb) y el browser con RUM (real-user monitoring). La latencia real-user incluye la cola larga de redes lentas, hardware mobile y terminación TLS compartida que los load tests sintéticos no ven.

Ejecuta tests centrados en latencia desde LoadFocus contra 25+ regiones cloud para ver cómo difiere la latencia por geografía. Una p95 de 50 ms desde us-east-1 es irrelevante si tus usuarios están en Sydney y la p95 real desde allí es 600 ms.

Si tu equipo necesita análisis de latencia desglosado por endpoint, región y hora del día contra carga production-shape, LoadFocus ofrece load testing services donde los ingenieros diseñan la matriz de tests, ejecutan los escenarios y redactan el desglose de latencia.