Ley de Little en pruebas de carga: dimensionar y comprobar
8 min de lectura
La ley de Little en pruebas de carga dice que el número medio de usuarios o peticiones dentro de un sistema es igual al ritmo al que lo atraviesan multiplicado por el tiempo medio que cada uno pasa en él: L = λW. Con un número fijo de usuarios virtuales, eso se convierte en usuarios = vueltas por segundo × (tiempo de respuesta + tiempo de reflexión), lo que te dice antes de una prueba si el plan puede alcanzar su tasa objetivo y, después, si los resultados cuadran. Trabaja con medias sobre un tramo estable de la prueba, así que no dice nada de los percentiles.
Los ejemplos de abajo son aritmética, sin ninguna prueba detrás. Los datos sobre herramientas salen de la documentación de cada proyecto, comprobada el 9 de octubre de 2026.
| Término | Definición de Little | Usuarios virtuales fijos (modelo cerrado) | Tasa de llegada (modelo abierto) |
|---|---|---|---|
| L | Número medio de elementos en el sistema | Usuarios virtuales, esperando o en pausa | Iteraciones en curso |
| λ | Tasa media de llegada | Vueltas completadas por segundo | La tasa que fijas |
| W | Tiempo medio dentro del sistema | Tiempo de respuesta + tiempo de reflexión por vuelta | Duración de una iteración |
¿Qué dice la ley de Little?
A largo plazo, el número medio de elementos en un sistema de colas es igual a su tasa media de llegada multiplicada por el tiempo medio que cada uno pasa en él. Si conoces dos de las tres magnitudes, puedes calcular la tercera.
John D. C. Little publicó la demostración en 1961 en Operations Research con el título A Proof for the Queuing Formula: L = λW. En su revisión por el 50.º aniversario, de 2011, escribe que se cumple en condiciones notablemente generales: para una sola cola o una red entera, para una subclase de elementos o para todos, y sea cual sea el orden de servicio. El mismo artículo traslada los términos a un servidor: peticiones en proceso, peticiones por segundo y tiempo de respuesta medio.
¿Qué significan L, λ y W en una prueba de carga?
Depende de dónde trazas el límite del sistema. Alrededor del servidor, L son las peticiones en curso y W el tiempo de respuesta; alrededor de la vuelta completa de un usuario virtual, L son todos los usuarios virtuales y W el tiempo de respuesta más el tiempo de reflexión.
En una prueba con modelo cerrado, cada usuario está siempre en algún punto de su vuelta: esperando una respuesta o haciendo una pausa entre dos pasos. Con el límite alrededor de la vuelta, todos cuentan como «dentro», λ es el ritmo al que terminan las vueltas y W la duración media de una vuelta, incluido el tiempo de reflexión que añade el script:
usuarios = vueltas por segundo × (respuesta + reflexión)
Alrededor del servidor, la misma ley da las peticiones en vuelo: peticiones por segundo × tiempo de respuesta medio, la cifra que tienen que absorber tus pools de conexiones y tus hilos de trabajo. Mantén los tres valores en el mismo límite y el mismo tramo de tiempo; mezclarlos da resultados plausibles y equivocados.
¿Cómo se dimensiona una prueba con modelo cerrado usando la ley de Little?
Convierte la tasa de peticiones objetivo en vueltas por segundo y multiplícala por la duración esperada de una vuelta: el resultado es el número de usuarios virtuales que necesita el plan. Usa el tiempo de respuesta que esperas con la carga objetivo, que suele ser mayor que el que ves con pocos usuarios.
Un ejemplo, solo aritmética. El objetivo son 100 peticiones por segundo, cada vuelta envía 4 peticiones que deberían tardar 0,5 segundos cada una, y el script hace 3 pausas de 2 segundos de media:
vueltas por segundo = 100 peticiones/s ÷ 4 peticiones = 25
duración por vuelta = 4 × 0,5 s + 3 × 2 s = 8 s
usuarios virtuales = 25 vueltas/s × 8 s = 200
Toma 200 como mínimo. Si las respuestas tardan 1 segundo con esa carga, una vuelta dura 10 segundos y el mismo objetivo necesita 250 usuarios.
¿Por qué los mismos usuarios envían menos peticiones cuando el sistema se ralentiza?
El número de usuarios es fijo, así que cuando una vuelta se alarga, las vueltas por segundo tienen que bajar. La carga cae justo cuando el sistema empieza a sufrir.
Mantén los 200 usuarios y haz que cada petición tarde 2 segundos. Una vuelta dura ahora 4 × 2 + 6 = 14 segundos, y 200 ÷ 14 da unas 14,3 vueltas, o unas 57 peticiones por segundo. La prueba sigue mostrando 200 usuarios mientras funciona a poco más de la mitad de la tasa prevista. El artículo sobre el modelo de carga abierto vs cerrado explica por qué eso oculta la saturación; la ley de Little predice el tamaño de la caída.
También muestra cómo se ve un límite de capacidad. Cuando la tasa de peticiones ya no puede subir, cada usuario extra solo añade espera: con un techo de 25 vueltas por segundo, 300 usuarios suponen 12 segundos por vuelta y 400 usuarios, 16. El gráfico de LoadFocus tiempo de respuesta vs usuarios virtuales representa el tiempo de respuesta medio y máximo frente al número de usuarios virtuales activos, un punto por cada nivel alcanzado, y ahí es donde aparece esa subida constante.
¿Cómo se comprueba una prueba terminada con la ley de Little?
Toma la tasa de peticiones y el tiempo de respuesta medios de un tramo en el que el número de usuarios se mantuvo estable, reconstruye a partir de ellos el número de usuarios y compáralo con lo que configuraste. Una diferencia grande significa que parte del tiempo se escapa de tus cifras.
Otro ejemplo aritmético. Una prueba mantiene 200 usuarios y registra 80 peticiones por segundo con una media de 0,6 segundos, con las mismas 4 peticiones y 6 segundos de pausas por vuelta. Son 20 vueltas por segundo de 4 × 0,6 + 6 = 8,4 segundos cada una, suficiente para 168 usuarios. Los 32 restantes significan que cada vuelta duró en realidad 10 segundos, así que hay unos 1,6 segundos por vuelta sin explicar. Dónde buscar:
- El establecimiento de conexiones. En k6,
http_req_durationdeja fuera la resolución DNS y la conexión (referencia de métricas, comprobada el 9 de octubre de 2026). - El generador de carga. Un generador saturado retrasa el script entre peticiones.
- El tiempo de reflexión. Las pausas aleatorias pueden durar de media más de lo previsto.
- La ventana. Si se solapa con una rampa, hubo de media menos usuarios activos.
k6 también mide la vuelta directamente: vus cuenta los usuarios virtuales activos e iteration_duration la duración de una iteración completa, así que los usuarios activos deberían quedar cerca de las iteraciones por segundo × la duración media de una iteración.
¿Qué pasa con las pruebas por tasa de llegada?
La ley se cumple con el límite alrededor de cada iteración: las iteraciones en curso son iguales a la tasa de llegada por la duración de una iteración. Ese es el número de usuarios virtuales que la herramienta tiene que tener listos.
La guía de k6 sobre la asignación de VU para los ejecutores de tasa de llegada los estima como la duración mediana de una iteración × la tasa, más una constante para la variabilidad (comprobado el 9 de octubre de 2026). Es la ley de Little con la mediana en lugar de la media; unas pocas iteraciones lentas suben la media por encima de la mediana, por eso importa el margen.
LoadFocus ejecuta scripts de k6 en su nube, y allí los escenarios de tasa de llegada se ejecutan con un número fijo de usuarios; el validador de scripts lo avisa cuando añades un script así. Dimensiona esas pruebas con el cálculo del modelo cerrado de arriba y cuenta con que la tasa baje si las respuestas se ralentizan.
¿Dónde deja de funcionar la ley de Little?
Relaciona medias sobre un tramo en el que el sistema está en equilibrio. Los percentiles, las ventanas cortas y las rampas quedan fuera.
- Solo medias. Una prueba puede cumplir la ley mientras una de cada veinte peticiones espera diez veces la media; juzga también los resultados por percentiles.
- Un tramo estable. La demostración de 1961 supone un proceso estacionario, y la revisión de 2011 muestra que la fórmula también es exacta en una ventana finita que empieza y termina vacía. Una meseta de prueba no es ninguna de las dos cosas, así que elige una larga, en la que tantos usuarios terminen vueltas como las empiecen.
- Rampas. Mientras se añaden usuarios, el pico configurado no es L: usa la media temporal de usuarios de la ventana o deja la rampa fuera.
- Errores. Los fallos rápidos cuentan como peticiones completadas con tiempos cortos, así que un sistema que falla puede seguir cuadrando la ecuación. Revisa primero la tasa de errores.
FAQ
¿La ley de Little necesita llegadas de Poisson o un tipo de cola concreto? No. Las demostraciones de la revisión de Little no suponen nada sobre el patrón de llegadas ni sobre los tiempos de servicio, y el resultado se cumple sea cual sea el orden de servicio. Solo hace falta que las medias existan en el periodo que mides.
¿Puede la ley de Little predecir el tiempo de respuesta p95? No. Relaciona tres medias, así que puede comprobar un tiempo de respuesta medio, pero no dice nada sobre la forma de la distribución ni sobre el pequeño porcentaje más lento.
Lecturas relacionadas
- Modelo de carga abierto vs cerrado: cuál usar y cuándo
- Tiempo de reflexión en pruebas de carga: cómo fijarlo
- Cómo hacer una prueba de carga: guía paso a paso
- Rendimiento vs latencia: cómo se relacionan bajo carga
- redis-benchmark: cómo usarlo y leer sus resultados
- Ley de Amdahl: fórmula, ejemplos y límites
- Teoría de colas: qué es y por qué se dispara la latencia
Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.