¿Qué es capacity testing?

¿Qué es capacity testing?

Capacity testing mide la carga máxima sostenible que un sistema puede manejar mientras sigue cumpliendo sus service-level objectives (SLOs). La salida es un número limpio: "este sistema maneja X usuarios concurrentes / Y peticiones por segundo a p95 latency por debajo de Z." Ese número es la base para sizing de infraestructura, compromisos contractuales y reclamos de capacidad de cara al cliente.

Capacity testing vs breakpoint testing

Ambos rampan carga más allá del peak esperado. La diferencia es el criterio de parada:

• Capacity testing se detiene cuando los SLOs se violan por primera vez (p95 cruza tu umbral, error rate excede 0,5%, throughput deja de escalar linealmente). La salida es la carga más alta que aún cumplió los SLOs.
• Breakpoint testing continúa más allá de la violación SLO para encontrar el punto de fallo duro: donde el sistema crashea, da errores totalmente o deja de aceptar peticiones. La salida es el techo absoluto, a menudo muy por encima del rendimiento aceptable.

Capacity = máximo con SLO compliance. Breakpoint = máximo antes del fallo total. La brecha entre ambos es tu margen de seguridad.

Cuándo ejecutar un capacity test

• Sizing de infraestructura. Conocer la capacidad de un node te dice exactamente cuántos nodes necesitas para el tráfico objetivo más margen.
• Negociación de contrato. Enterprise sales pregunta "¿puede esto manejar 50.000 usuarios?" — capacity testing da una respuesta honesta.
• Compromiso SLA. Prometer 99,9% de disponibilidad a una carga específica requiere evidencia de que la carga está dentro de la capacidad.
• Validación pre-launch. Marketing prevé 5.000 usuarios concurrentes al lanzamiento. Capacity testing confirma que el sistema lo maneja con margen, o señala que 5.000 está por encima de la capacidad y necesita scaling.
• Configuración de autoscaling. Capacidad por pod dividida por utilización objetivo te da el trigger de scale-out.

Métricas clave de capacity test

1. VU count o RPS máximo sostenible. La salida principal. El nivel de carga al que los SLOs se cumplieron por última vez.
2. Margen al breakpoint. Ratio capacity / breakpoint. Una capacidad al 80% del breakpoint es sana; capacidad al 99% del breakpoint es frágil.
3. Utilización de recursos en capacidad. CPU, memoria, conexiones BD, thread pool al número de capacidad. Te dice qué dimensión escalar.
4. Tiempo en capacidad. ¿Mantiene el sistema la carga de capacidad durante la duración SLO completa (15 min, 1 hora, 24 horas)? Algunos sistemas alcanzan un VU count alto brevemente pero degradan con el tiempo bajo carga sostenida.

Cómo ejecutar un capacity test

Mismos scripts que load testing, con un step-ramp que pausa en cada nivel lo suficiente para confirmar SLO compliance. En JMeter, usa el Stepping Thread Group para mantener en cada nivel de VU durante 5-15 minutos antes de subir. En k6, configura un escenario ramping-vus multi-etapa con holds sostenidos en cada step.

Define tu umbral SLO primero (ej. "p95 latency bajo 800 ms, error rate bajo 0,5%"). La capacidad es el step más alto en el que el SLO aguantó durante la duración hold completa. Baja un step para margen de seguridad.

Ejecuta desde LoadFocus para capacity testing distribuido donde los load generators en múltiples regiones testean la capacidad geo-distribuida del sistema, no solo single-region.

Para capacity testing que informe compromisos de capacidad a nivel de junta directiva, LoadFocus ofrece load testing services donde los ingenieros ejecutan el test, documentan la capacidad con contexto de infraestructura y producen un informe apto para stakeholders.