Throughput (rendimiento)

El throughput (rendimiento) es cuánto trabajo realiza un sistema por unidad de tiempo: solicitudes por segundo (RPS) en una API, transacciones por segundo (TPS) en un sistema de pagos, mensajes por segundo en un consumidor de colas. Mide la capacidad, mientras que la latencia mide cuánto tarda cada unidad de trabajo individual. Necesitas ambas, además de la tasa de errores, para describir el rendimiento.

Cómo se relacionan throughput, latencia y concurrencia

En un sistema estable, la ley de Little vincula las tres:

concurrent requests in flight = throughput × average response time

Example: 200 requests/second × 0.25 seconds = 50 requests in flight

Con usuarios virtuales que hacen pausas entre acciones, el tiempo de reflexión (think time) se suma al ciclo: throughput ≈ usuarios ÷ (tiempo de respuesta + think time). Así, 100 usuarios con un tiempo de respuesta de 0,5 s y 4,5 s de think time generan unas 20 solicitudes por segundo, no 100. Por eso “probamos con 1.000 usuarios” significa poco hasta que indicas también el think time y la tasa de solicitudes resultante.

Cómo se comporta el throughput con una carga creciente

A medida que aumenta la carga, el throughput primero sube al mismo ritmo. En algún momento un recurso se satura (CPU, un pool de conexiones, un componente de un solo hilo) y el throughput se aplana mientras la latencia sube con fuerza. Si se sigue empujando, el throughput puede llegar a caer, porque el sistema gasta su esfuerzo en colas, reintentos y timeouts. Encontrar esa meseta es el principal resultado de una prueba de estrés, y define la capacidad práctica.

Consejos para las pruebas

• Expresa los objetivos como tasa más latencia. “500 RPS con p95 por debajo de 300 ms y menos de un 1 % de errores” se puede probar. “Aguanta mucho tráfico” no.
• Cuenta solo el trabajo exitoso. Un servidor que responde 2.000 RPS con la mitad de errores 500 no está haciendo 2.000 RPS de trabajo útil.
• Usa carga por tasa de llegada cuando sea posible. Generar una tasa fija de solicitudes muestra directamente si el sistema puede sostenerla; un pool fijo de usuarios enviará, sin avisar, menos solicitudes a medida que las respuestas se ralenticen.
• Revisa el generador de carga. Si la máquina que ejecuta la prueba está al 100 % de CPU, has medido el throughput del generador, no el del sistema.
• Ten en cuenta los rate limits. Un gateway que devuelve 429 limita el throughput medido; decide si estás probando el limitador o el servicio que hay detrás.