Estima el TPS máximo que puede sostener tu arquitectura y qué componente se convierte en cuello de botella, según las especificaciones del servidor, el runtime y la configuración de base de datos.
La base es la ley de Little: la concurrencia es igual al TPS multiplicado por el tiempo de respuesta. Despejando al revés, el techo de TPS de cualquier recurso es su capacidad concurrente dividida entre el tiempo de respuesta.
Ese cálculo se hace por separado para cada recurso: CPU, sockets, pool de hilos y pool de conexiones a la base de datos. Cada uno tiene su propio techo, independiente de los demás.
Después, el más bajo de todos se convierte en el techo del sistema completo y ese recurso se muestra como cuello de botella. Por mucho que amplíes los otros, el rendimiento no sube ni un punto mientras no toques ese.
Por ejemplo, el techo de CPU es el número de núcleos dividido entre el tiempo de cómputo por petición y multiplicado por el número de servidores. Cuatro núcleos con 2 ms de cómputo dan 2.000 peticiones por segundo por servidor.
Un hilo por petición (el Spring MVC clásico) mantiene el hilo ocupado durante toda la espera de E/S externa. Por eso el pool de hilos se agota primero y el TPS se estanca mientras la CPU sigue prácticamente ociosa.
Aquí el techo es el tamaño del pool dividido entre el tiempo total de proceso y multiplicado por el número de servidores. Lo importante es que ese tiempo total incluye la espera de la base de datos y de las API externas, no solo el cómputo.
En cambio, hilos virtuales, Go y Node.js no retienen un hilo durante la E/S, así que esa restricción desaparece y el crecimiento continúa hasta chocar con la CPU o con el número de sockets disponibles.
Node.js tiene además una advertencia propia: si el cómputo de CPU por petición llega a 20 ms o más, existe riesgo de bloquear el bucle de eventos, y la herramienta lo señala con esa configuración. Traducido: el cálculo pesado no encaja en un bucle de eventos único.
Las lecturas que aciertan en caché no llegan nunca a la base de datos, así que la presión sobre el pool de conexiones baja exactamente en esa proporción.
En el cálculo, la lectura efectiva es la proporción de lecturas multiplicada por uno menos la tasa de acierto. Con un 80% de lecturas y un 50% de aciertos, solo un 40% del total acaba llegando a la base de datos.
De ahí que cuanto más pesada en lecturas sea tu carga, más rinde la caché. En cargas dominadas por escrituras, subir la tasa de acierto no alivia nada al maestro, porque las escrituras siempre van a él.
Con una topología maestro/réplica, las escrituras van al maestro y la lectura efectiva se reparte entre las réplicas, y cada lado obtiene su propio techo. Añadir réplicas solo ayuda al lado de lectura.
Activar la cola modela delegar en ella las llamadas externas lentas, de modo que la latencia externa desaparece de la ruta de la petición y en su lugar se contabilizan solo 5 ms como coste de encolar el mensaje.
Si la API externa tardaba 300 ms, el tiempo total por petición se desploma. En el modelo de hilos retenidos esa diferencia se traduce directamente en más rotación del pool, y por eso el efecto se ve mucho más espectacular ahí.
El segundo beneficio es la seguridad bajo sobrecarga: el tráfico que excede la capacidad se guarda en la cola en vez de acumularse dentro del servidor y devorar su memoria.
Sin cola, y con el cuello de botella en la capa de aplicación, el exceso se apila como conexiones en espera en memoria. La herramienta suma esa carga al cálculo y declara agotamiento de memoria si supera la RAM disponible.
La estimación asume que cada petición en curso ocupa 1 MB de memoria. Cuanta más concurrencia, más consumo, de forma directamente proporcional.
A eso se suma una base fija: en el modelo de hilos, 512 MB más 1 MB por hilo; en el asíncrono, 100 MB por núcleo de CPU. Ahí se ve por qué agrandar el pool de hilos sin criterio se come la memoria.
Cuando el consumo supera la RAM disponible, el cuello de botella pasa a ser agotamiento de memoria (OOM) sea cual sea el recurso que limitaba antes. Es un modo de fallo muy real: te sobra techo de TPS pero el servidor cae por memoria primero.
Ampliar el pool de hilos sube el TPS y sube el consumo de memoria al mismo tiempo. Poner números a esa disyuntiva es justamente el objetivo de esta herramienta.
Esto es una simulación puramente matemática: no se envía ninguna petición a un servidor real y todos los números se calculan dentro de tu navegador.
El modelo está simplificado a propósito. No refleja las pausas del recolector de basura, ni el ancho de banda de red, ni la E/S de disco, ni el coste de cambio de contexto entre hilos, ni la contención de bloqueos o la eficacia de los índices en la base de datos.
Tampoco tiene en cuenta la variabilidad del tiempo de proceso entre una petición y otra. En sistemas reales lo que define la percepción de lentitud es la latencia de cola (p99) y no la media, y ahí nace la mayor diferencia con la realidad.
Usa el resultado como punto de partida para dimensionar y orientar una decisión de ampliación, y confirma después con una prueba de carga real usando herramientas como k6 o JMeter.
Para ver de forma intuitiva cómo crecen la cola y la latencia cuando sube la concurrencia.
No. Es una simulación local que no envía tráfico a ningún servidor.
Teoría de colas básica: a partir de la tasa de llegadas y la de servicio calcula la espera.