Rendimiento vs latencia: cómo se relacionan bajo carga

El rendimiento (throughput) es la cantidad de trabajo que un sistema termina por unidad de tiempo, por ejemplo peticiones por segundo. La latencia es lo que tarda una unidad de trabajo, por ejemplo 120 milisegundos por petición. Con poca carga apenas se afectan entre sí; cuando la carga se acerca a la capacidad del sistema, el rendimiento deja de subir y la latencia empieza a crecer, y encontrar ese punto es justo para lo que sirve una prueba de carga.

El ejemplo de abajo es aritmética, sin ninguna prueba detrás. Las definiciones de las herramientas salen de la documentación de cada proyecto, comprobada el 16 de octubre de 2026.

¿Qué diferencia hay entre rendimiento y latencia?

El rendimiento cuenta el trabajo terminado a lo largo del tiempo; la latencia mide lo que tarda una unidad de trabajo. Un sistema puede tener latencia baja y rendimiento bajo, o rendimiento alto y latencia alta, así que necesitas las dos cifras para describirlo.

El glosario de JMeter calcula el rendimiento como el número de peticiones dividido entre el tiempo total, desde el inicio de la primera muestra hasta el final de la última, incluidas las pausas entre muestras, porque debe representar la carga sobre el servidor (comprobado el 16 de octubre de 2026). Eso hace del rendimiento una propiedad de toda la ejecución, mientras que la latencia pertenece a cada petición y se lee mejor como una distribución: mediana, p95, p99.

¿El ancho de banda es lo mismo que el rendimiento?

No. El ancho de banda es la cantidad máxima de datos que podría llevar un enlace de red; el rendimiento es lo que pasa de verdad. En una prueba de carga, el rendimiento suele referirse a peticiones terminadas, y el ancho de banda solo importa cuando cargas de datos grandes llenan el enlace antes de que la aplicación agote su capacidad.

La página comparativa de AWS resume la visión de red: la latencia es el retraso en la comunicación de red, el rendimiento es el volumen medio de datos que realmente pasa en un periodo y el ancho de banda es el máximo teórico (comprobado el 16 de octubre de 2026). Buena parte de lo que se encuentra en internet usa ese sentido de red. Las pruebas de carga usan las mismas palabras para peticiones en lugar de paquetes, y por eso conviene decir cuál de los dos significa un informe.

¿Qué significa “latencia” en una herramienta de pruebas de carga?

Depende de la herramienta. En JMeter, Latency es el tiempo hasta la primera parte de la respuesta, y el tiempo de respuesta completo se llama Elapsed time. En k6, http_req_duration abarca el envío, la espera y la recepción, y el tiempo hasta el primer byte es una métrica aparte.

El glosario de JMeter mide el Elapsed time desde justo antes de enviar la petición hasta justo después de recibir la última respuesta, y la Latency hasta justo después de recibir la primera. La referencia de métricas de k6 define http_req_duration como http_req_sending + http_req_waiting + http_req_receiving, sin la resolución DNS ni el establecimiento de la conexión, y llama a http_req_waiting el tiempo hasta el primer byte (ambos comprobados el 16 de octubre de 2026). Así que la Latency de JMeter equivale a http_req_waiting de k6, no a http_req_duration. Si comparas una “latencia” de JMeter con una “duration” de k6, la cifra de JMeter parecerá mejor sin serlo.

¿Cómo cambian el rendimiento y la latencia al crecer la carga?

Al principio, más carga significa más rendimiento, y la latencia se mantiene más o menos plana. Cuando el sistema llega a su capacidad, el rendimiento deja de crecer y cada usuario adicional solo añade espera, así que la latencia sube con la carga.

Un ejemplo, solo aritmética. Un servicio atiende como mucho 200 peticiones por segundo y responde en 0,1 segundos cuando no está ocupado. Cada usuario virtual envía una petición y luego hace una pausa de 1 segundo. Con un número fijo de usuarios, la forma de la ley de Little para el modelo cerrado los relaciona: usuarios = peticiones por segundo × (latencia + tiempo de reflexión), como muestra paso a paso nuestro artículo sobre la ley de Little.

Hasta 220 usuarios, el rendimiento crece al mismo ritmo que ellos. A partir de ahí se queda fijo en 200, y la latencia tiene que absorber el resto: 300 usuarios necesitan 300 ÷ 200 = 1,5 segundos por vuelta, lo que deja 0,5 segundos de latencia. Los sistemas reales suelen curvarse de forma más gradual, porque las colas empiezan a formarse antes del techo exacto. Con una prueba de tasa de llegada el panorama es más duro: si las peticiones llegan a más de 200 por segundo, la acumulación crece mientras dure el exceso, que es la diferencia que explica el artículo sobre el modelo de carga abierto vs cerrado.

¿Cómo encuentras el codo en tus propios resultados?

Sube la carga por escalones, mantén cada escalón lo suficiente para que se estabilice y anota el rendimiento y un percentil de latencia de cada uno. El codo es el primer escalón en el que el rendimiento deja de subir con la carga mientras la latencia empieza a crecer.

Algunas cosas hacen fiable esa lectura:

• Mantén cada escalón unos minutos, para medir el rendimiento en un tramo estable y no en una rampa.
• Lee un percentil, no solo la media; la media puede seguir tranquila mientras el pequeño porcentaje de peticiones más lentas se vuelve mucho más lento.
• Revisa los errores en cada escalón. Los fallos rápidos cuentan como peticiones terminadas con tiempos cortos, así que un sistema que falla puede mostrar más rendimiento y menos latencia.
• Vigila el generador de carga. Si su CPU está saturada, el techo que encontraste puede ser el suyo.

El gráfico de tiempo de respuesta frente a usuarios virtuales de LoadFocus muestra el tiempo de respuesta medio y máximo frente a los usuarios virtuales activos, un punto por cada nivel alcanzado, y ahí es donde aparece el codo en una prueba por escalones.

¿Se puede subir el rendimiento sin subir la latencia?

A veces. Añadir capacidad mueve el techo, así que la latencia se mantiene plana más tiempo. Agrupar trabajo (batching) suele hacer la concesión contraria: sube el rendimiento haciendo esperar a cada petición.

El algoritmo de Nagle de TCP es el ejemplo clásico de esa concesión. La RFC 896 retiene los segmentos nuevos mientras haya datos enviados en la conexión sin confirmar, de modo que la red lleva menos paquetes y más llenos, y cada escritura pequeña puede esperar (comprobado el 16 de octubre de 2026). Agrupar peticiones y usar búferes de escritura funciona igual: más trabajo por segundo, más tiempo por elemento. Cuando cambies algo de esto, repite la prueba por escalones y compara las dos curvas, no una sola cifra.

¿Cuál de los dos va en tus criterios de aprobación?

Los dos, unidos. Un objetivo de latencia dice poco sin el rendimiento con el que se midió, y un objetivo de rendimiento dice poco si la latencia se duplicó para alcanzarlo. Exprésalos como una pareja, por ejemplo p95 por debajo de 300 milisegundos a 200 peticiones por segundo con menos de un 1 % de errores.

Nuestra guía de criterios de aprobación en pruebas de carga muestra cómo escribir y automatizar esa pareja. Si tu herramienta espera a las respuestas lentas antes de enviar la siguiente petición, sus cifras de latencia pueden quedarse cortas; la coordinated omission explica cómo ocurre y cómo evitarla. La entrada del glosario de LoadFocus sobre la latencia explica de dónde viene la latencia y por qué importan los percentiles.

FAQ

¿Una latencia baja significa un rendimiento alto? No necesariamente. Un sistema puede responder rápido a cada petición pero atender pocas a la vez, o atender muchas a la vez mientras cada una espera. Solo conoces las dos cosas después de medirlas bajo la misma carga, idealmente en varios niveles de carga.

¿Qué diferencia hay entre latencia y tiempo de respuesta? En el uso cotidiano suelen significar lo mismo. En JMeter, Latency es el tiempo hasta la primera parte de la respuesta y Elapsed time el tiempo de respuesta completo, así que comprueba cuál muestra un informe antes de comparar herramientas.

¿Por qué deja de subir el rendimiento en una prueba de carga? Algo ha llegado a su límite: la CPU, una base de datos, un pool de conexiones, un límite de peticiones (rate limit) o el propio generador de carga. A partir de ahí, los usuarios adicionales solo hacen cola, lo que se ve como latencia en aumento con el rendimiento plano.

Lecturas relacionadas

• Ley de Little en pruebas de carga: dimensionar y comprobar
• Modelo de carga abierto vs cerrado: cuál usar y cuándo
• Coordinated omission: qué es y cómo evitarla
• Criterios de aprobación en pruebas de carga: cómo fijarlos
• Latencia de cola: qué es y cómo medirla
• Puntuación Apdex: qué es y cómo se calcula
• Ley de Amdahl: fórmula, ejemplos y límites

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.