Pruebas de carga y estrés

Pruebas de carga y estrés

1) Por qué es necesario

• Confirmar capacidad (cuántas sesiones RPS/competitivas soportará el sistema con el SLO especificado).
• Localice los cuello de botella (CPU/IO/DB/red/bloqueo/grupos).
• Configurar los presupuestos de actuación y «gates» en CI/CD.
• Reducir el riesgo de lanzamientos (regresión p95/p99, aumento de errores en pico).
• Planificar capacidad/costo (skale out y reservas).

2) Tipos de pruebas de perforación

Carga (carga de trabajo): tráfico realista cercano a los picos; validación de SLO.
Stress (estrés): crecimiento hasta/por encima del límite → comportamiento en la degradación donde se rompe.
Spike (pulso): rápido salto de carga → elasticidad/auto-scale.
Soak/Endurance (largo): horas/día → fugas, fragmentación, deriva latency.
Capacity/Scalability: cómo cambia throughput/latency en scale-out; la ley de Amdal/Gustafson.
Smoke perf: una corta corrida de «humo» en cada lanzamiento (performance-sanity).

3) Modelos de generación de tráfico

Modelo cerrado (fixed VUs/concurrency): 'N' usuarios, cada uno hace consultas → cola en el cliente. El riesgo de ocultar la sobrecarga.
Modelo abierto (arrival rate): flujo de solicitudes con intensidad de λ (req/s), como en la vida real. Más correcto para las API públicas.

La ley de Little: 'L = λ × W'.
Para pool/servicio: paralelismo mínimo ≈ 'λ × W' (añadir 20-50% de margen).
Donde 'λ' es throughput, 'W' es el tiempo medio de servicio.

4) Perfiles de carga y scripts

User journey mix: share de scripts (login, browse, deposite, checkout...).
Think-time: pausas del usuario (distribuciones: exponencial/lognormal).
Perfil de datos: tamaño de respuesta, payload, variabilidad de parámetros.
Correlación: vincula los pasos (cookies/tokens/ID) como en un flow real.
Caché frío/caliente/caliente: corridas individuales.
Read vs Write: balance de lecturas/grabaciones, idempotencia para retraídas.
Multi-región: RTT, distribución por POP/ASN.

5) Entorno de prueba

Aislamiento: el stand está cerca de venderse por topología/ajustes (pero no «golpear» el prod).
Datos: enmascaramiento PII, volúmenes, índices como en la venta.
Generadores de carga: no se apoyan en la CPU/red; ranners distribuidos, sincronización de tiempo.
Observabilidad: métricas/tracks/logs, sintética perimetral, exportación de perfiles CPU/heap.

6) Métricas y SLI

Throughput: RPS/transacciones en segundos.
Latency: p50/p95/p99, TTFB, server time vs network.
Errors: una fracción de 5xx/4xx/errores de dominio.
Saturation: CPU, load avg, GC, disco IOps/latencia, network, pool wait.
SLI de negocios: éxito de depósito ≤ 5s, confirmación de pedido ≤ 2s.

Tome los umbrales de SLO (por ejemplo, "99. 95% ≤ 300 ms"), monitor burn-rate durante la carrera.

7) Búsqueda de cuellos de botella (metodología)

1. Calienta constantemente el sistema en un 60-80% de la carga objetivo.
2. Aumente con pasos (ramp) → fije dónde crece p95/p99 y error-rate.

• colas en grupos (DB/HTTP),
• el crecimiento de WAIT/Locks (DB),
• Pausas GC/heap,
• retransmits/packet loss de red,
• latencia de disco/errores de caché.
• 4. Localice: búsqueda binaria por ruta de consulta, perfiladores (CPU/alloc/lock-profile).
• 5. Fije la «botella» → afinación → repetición de la carrera.

8) Comportamiento bajo estrés

Degradación graceful: límites, circuit-breakers, colas con backpressure, modo «aceptado en el procesamiento».
Retraídas: máximo 1, sólo idempotentes; jitter; el presupuesto de los retiros ≤ el 10% de RPS.
Fail-open/Fail-closed: para dependencias no críticas, permite fail-open (caché/tapones).
Cascading failure: aislamiento de grupos/cuotas (bulkhead), temporizadores rápidos, desactivación «suave» de funciones (feature flags).

9) Herramientas (selección de tareas)

k6 (JavaScript, open/open-model, rápido, cómodo en CI).
JMeter (rico en ecosistema, GUI/CLI, plugins, pero más pesado).
Gatling (Scala DSL, alto rendimiento).
Locust (Python, flexibilidad de scripts).
Vegeta/hey/wrk (micro-benchi y verificación rápida).

Regla: una herramienta «principal» + CLI ligero para smoke-perf en PR.

10) Ejemplos (snippets)

10. 1 k6 (modelo abierto con tasa de arrival)

js import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
scenarios: {
open_model: {
executor: 'ramping-arrival-rate',
startRate: 200, timeUnit: '1s',
preAllocatedVUs: 200, maxVUs: 2000,
stages: [
{ target: 500, duration: '5m' },  // до 500 rps
{ target: 800, duration: '5m' },  // стресс
{ target: 0,  duration: '1m' }
]
}
},
thresholds: {
http_req_duration: ['p(95)<300', 'p(99)<800'],
http_req_failed: ['rate<0.005'],
},
};

export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/catalog?limit=20`);
sleep(Math.random() 2); // think-time
}

10. 2 JMeter (idea de perfil)

Thread Group + Stepping Thread или Concurrency Thread (open-like).
HTTP Request Defaults, Cookie Manager, CSV Data Set.
Backend Listener → InfluxDB/Grafana; Assertions por tiempo/código.

10. 3 Locust (Python)

python from locust import HttpUser, task, between class WebUser(HttpUser):
wait_time = between(0.2, 2.0)
@task(5)
def browse(self): self.client.get("/api/catalog?limit=20")
@task(1)
def buy(self): self.client.post("/api/checkout", json={"sku":"A1","qty":1})

11) Datos, correlación, preparación

Seed-data: directorios, usuarios, balances, tokens - como en la venta.
Enmascaramiento/anonimización de PII; generación de sintéticos sobre distribuciones reales.
Correlación: extraer ID/tokens de las respuestas (RegAmb/JSONPath) y usarlos en los pasos siguientes.

12) Observabilidad durante las corridas

RED-dashboards (Rate, Errors, Duration) a lo largo de las rutas.
Exemplars: pasar de métricas a pistas (trace_id).
Registros de errores: sampling + agregación, duplicados/idempotencia.
Sistema: CPU/GC/heap, discos/red, pool wait.
DB: consultas superiores, bloqueos, índices escaneados, bloat.

13) Automatización y performance Gates

CI: corridas cortas en el merge (por ejemplo, k6 2-3 minutos) con rápidos.
Nightly/Weekly: soak/stress largos en un entorno separado; informes y tendencias.
Lanzamientos canarios: análisis de SLO (error-rate, p95) como «gate» de promoción.
Regresiones: baseline vs build actual; alertas en deterioro> X%.

14) Planificación de capacidad y costo

Curvas de throughput→latency: identificar el punto knee (rodilla) - después de él p99 crece bruscamente.
Scale Out: mida la eficiencia de escala (delta RPS/delta nodos).
Costo: «RPS por $/hora», reserva para eventos máximos + reserva de DR.

15) Anti-patrones

Golpear en el prod sin control o probarlo en un ambiente «vacío» que no es como el prod.
Modelo cerrado con VU fijas que oculta la sobrecarga.
La ausencia de think-time/datos → éxitos de kash poco realistas o viceversa es una tormenta a los orígenes.
Un escenario «/ping »en lugar de flow personalizado.
Falta de observabilidad: «solo vemos RPS y latencia media».
Retrés incontrolables → uno mismo-DDoS.
Mezcla de pruebas y optimizaciones sin fijar hipótesis/cambios.

16) Lista de verificación (0-30 días)

0-7 días

Identifique SLI/SLO y los perfiles de tráfico de destino (mix, think-time, datos).
Seleccione la herramienta (k6/JMeter/Locust), levante los dashboards RED.
Prepare el stand y los datos de seed, desactive los límites/captcha de terceros.

8-20 días

Construye escenarios: open-model (rate arrival), frío/caché caliente/caliente.
Ejecute load → stress → spike; fije el punto knee y los cuellos de botella.
Introduce las gates de actuación en el CI (micro-ejecución).

21-30 días

Soak-prueba 4-24 h: fugas/deriva GC, estabilización.
Documente los límites, el plan de capacidad, las ilustraciones «RPS→p95/oshibki».
Prepare el runbook «cómo aumentar los límites/skale» y «cómo degradarse».

17) Métricas de madurez

Hay perfiles realistas (mix, think-time, datos) que cubren ≥ el 80% del tráfico.
RED-dashboards + rastreo están conectados para todas las pruebas.
Las getas de rendimiento bloquean las liberaciones en caso de regresión de p95/errores.
La capacidad y el punto knee están documentados por servicios clave.
Pasos mensuales de soak/stress e informes de dinámica.
La resistencia al «spike» está confirmada por el scale automático y la falta de cascade-fail.

18) Conclusión

Las pruebas de carga son una práctica de ingeniería regular, no una «medición» única. Modele a los usuarios reales (open-model), mida lo que refleja la experiencia del cliente (SLI/SLO), mantenga la observabilidad y las «gates» en CI/CD, conduzca pasos de stress/spike/soak y fije el punto knee. Entonces los eventos de pico y los «cisnes negros» se convierten en escenarios manejables y el rendimiento en un parámetro predecible y medible de su plataforma.