Calculadora de peticiones por segundo: el throughput máximo de tu servidor
Calcula peticiones por segundo de cuatro formas con la ley de Little: el throughput máximo de un servidor, la carga que generan usuarios concurrentes con su tiempo de pausa, el pico de RPS a partir del tráfico diario y los workers y servidores que necesitas, con espera en cola, margen y ancho de banda.
Cómo funciona
Ley de Little: L = λ × W · Throughput máximo = concurrencia ÷ tiempo de respuesta · Carga de usuarios = usuarios ÷ (tiempo de respuesta + tiempo de pausa) · RPS promedio = peticiones diarias ÷ 86,400; pico = promedio × relación pico/promedio · Workers = ⌈RPS × tiempo de respuesta ÷ utilización objetivo⌉ · Ancho de banda (Mbps) = RPS × KB × 8 ÷ 1,000
La ley de Little dice que el número promedio de peticiones dentro de un sistema es igual a la tasa de llegada por el tiempo que pasa cada una ahí (L = λ × W). En un servidor eso amarra tres números: peticiones por segundo, tiempo de respuesta y concurrencia. «Capacidad del servidor» divide el número de workers entre el tiempo de respuesta para obtener lo máximo que puede completar: un worker que responde en 200 ms llega como mucho a cinco peticiones por segundo. «Desde usuarios» convierte un escenario de prueba de carga en RPS: cada usuario virtual envía una petición, espera la respuesta y hace una pausa, así que el throughput es el número de usuarios entre ese ciclo. «Desde el tráfico diario» convierte las páginas vistas al día en un promedio y un pico por segundo, y «Workers necesarios» dimensiona la concurrencia para un RPS objetivo. Todos los modos aplican una utilización objetivo para que planees con margen, cuentan servidores a partir de los workers por instancia, estiman el ancho de banda de salida con el tamaño de la respuesta y, cuando se conoce la tasa de llegada, usan el modelo de colas de Erlang C para mostrar cuánto esperan las peticiones. Una tabla y una gráfica muestran cómo cambia el resultado si el tiempo de respuesta mejora o empeora.
Ejemplo resuelto
La API de Esteban responde en 200 ms en promedio, así que un worker hace 1 ÷ 0.2 = 5 req/s; con 10 workers llega a 50 req/s, es decir 3,000 peticiones por minuto, y al 75% de utilización una carga segura sostenida es de unas 37.5 req/s. Al revés: 1,000,000 de páginas vistas al día son 1,000,000 ÷ 86,400 = 11.6 req/s en promedio; con un pico de 4× son 46.3 req/s, hay 9.26 peticiones en curso y necesitas ⌈9.26 ÷ 0.75⌉ = 13 workers, dos servidores de ocho. Y 2,800 usuarios con 3 s de pausa y respuestas de 1 s envían 2,800 ÷ 4 = 700 req/s.
Fuentes: Little, J. D. C. (1961). A Proof for the Queuing Formula L = λW. Operations Research 9(3)
Preguntas frecuentes
¿Qué es la ley de Little?
Dice que el número promedio de elementos en un sistema es igual a la tasa de llegada por el tiempo promedio que cada uno pasa ahí (L = λ × W). Despejando, throughput = concurrencia ÷ tiempo de respuesta, que es la base de todos los resultados de esta calculadora.
¿Cómo convierto usuarios concurrentes en peticiones por segundo?
Divide el número de usuarios entre el tiempo que pasa entre sus peticiones: el tiempo de respuesta más el de pausa. 2,800 usuarios que esperan 1 s la respuesta y hacen una pausa de 3 s generan 2,800 ÷ 4 = 700 req/s. Sin pausas, los mismos usuarios generarían mucha más carga; por eso las pruebas de carga deben usar pausas realistas.
¿Cómo estimo el pico de RPS a partir del tráfico diario?
Divide las peticiones diarias entre 86,400 para obtener el promedio por segundo y multiplícalo por una relación entre pico y promedio. Una relación de 4 supone que el tráfico del día se concentra en unas seis horas; en lanzamientos, ofertas o noticias puede ser de 10× o más.
¿Por qué planear con 70–80% de utilización y no con 100%?
La espera en cola crece muy rápido cuando los workers están más ocupados. Con llegadas aleatorias, un grupo al 95% de utilización hace esperar a muchas peticiones, mientras que uno al 75% absorbe ráfagas y peticiones lentas. La estimación de cola en los resultados muestra este efecto con tus números.
¿Por qué mi servidor da menos peticiones por segundo que la estimación?
Porque la capacidad es un máximo teórico. En la práctica los tiempos de respuesta suben con la carga, los workers esperan a la base de datos o a bloqueos compartidos y las peticiones hacen fila. Haz una prueba de carga para conocer el número real.
¿Cómo aumento las peticiones por segundo?
Baja el tiempo de respuesta promedio (caché, consultas más rápidas, menos trabajo por petición) o sube la concurrencia útil (más workers, E/S asíncrona), siempre que los recursos de atrás aguanten el ritmo.
Calculadoras relacionadas
Esta calculadora tiene fines informativos. Verifica los resultados importantes antes de tomar decisiones.