Pruebas de carga y estrés

1) Términos y objetivos

Prueba de carga: validación en el rango de trabajo (target RPS/competencia) frente a SLO (por ejemplo, p95 <200 ms, error rate <0. 5%).
Prueba de estiramiento - ir más allá (hasta/más allá de la saturación de la CPU/DB/red), observación de la degradación y mecánica de recuperación.
Prueba de spike - ráfagas bruscas de carga (× N durante minutos).
Soak/Endurance es una larga carrera (horas/día) para buscar fugas, derivación de GC, fragmentación, ráfagas de colas.
Prueba de capacidad: cálculo de la meseta de ancho de banda (punto de saturación) y el inventario.

Objetivos: confirmar SLO, fijar la meseta, entender los cuellos de botella, calibrar la escala automática y los límites.

2) Modelo de tráfico: abierto vs cerrado

Modelo cerrado (concurrency-driven): número fijo de usuarios virtuales (VUs), cada uno después de responder hace think time.
Modelo abierto (arrival-rate): intensidad fija de recepción de solicitudes (RPS), independientemente de las respuestas.

Little’s Law: `L = λ W`

'L' es el número medio de solicitudes atendidas simultáneamente,

'λ' - intensidad (RPS),

'W' es el tiempo medio de respuesta.
De ahí la valoración de la necesaria competitividad del generador: 'concurrency ≈ target_RPS p95_latency'.

3) Métricas: lo que medimos

SLI de latencia: p50/p90/p95/p99 y cola p99. 9; separados para las rutas «calientes» y «frías».
Errores: '5xx', '4xx' (válido/no válido), timeouts, abortado.
Ancho de banda: RPS constante, throughput subprocesos/bytes.
Recursos: CPU, RAM/heap, pausas GC, disco IOPS/lat, banda de red, número de conexiones/FD.
Colas y retroexcavadoras: profundidad, tiempo de espera, número de solicitudes shed/limited.
Eficiencia de caché: hit/miss, tormentas de calentamiento.
BD/caché/colas: p95 consultas, bloqueos, conflictos, utilización de grupos.

4) Stands y datos

Equivalencia de configuración: versiones de software, límites (uLimit, conntrack), configuración JVM/GC, pool 's.
Topología: LBs, CDN, WAF, TLS, los mismos «hops» de red.
Datos: distribuciones realistas (dimensiones de los objetos, claves «calientes «/» frías », regionalidad).
Inicio frío/cálido/caliente: pasos separados; asegúrese de probar cachés «fríos».
Aislamiento de fondo: desactivar los jobes/coronas irrelevantes o tener en cuenta su efecto.

5) Escenarios (perfiles de carga)

1. Baseline: aceleración escalonada a RPS objetivo, retención 10-30 min.
2. Ramp & Hold: crecimiento suave hasta X% por encima del objetivo, retención → análisis de colas.
3. Spike: × instantánea 2- × 5 ráfaga en 1-5 min, luego retorno.
4. Stress to Failure: pasos antes de fallas; fijamos el primer punto de incumplimiento de SLO y el punto de «ruptura».
5. Soak: 6-24 h con variabilidad de tráfico (día/noche), seguir las caras/deriva.
6. Mixed: mezcla de endpoints por distribución real (Zipf/pareto), diferentes pesos.

6) Proceso paso a paso

Identificar SLO y perfiles de tráfico de destino.
Seleccione un modelo de carga (abierto/cerrado), especifique una tasa de arrival o VUs.
Preparar los datos y los modos «caliente «/» frío ».
Personalizar la telemetría (tracks/métricas/logs), la corelación con la rana de prueba.
Calentamiento y ejecución, recolección de artefactos (perfiles CPU/heap, gráficos flame, explain/slow-logs DB).
Análisis de cuellos de botella, formación de acciones items.
Reprogon después de ficks, actualización de basline y capacity playbook.

7) Cuellos de botella y fijos típicos

CPU-bound servicio: perfilado → eliminación de funciones calientes, alocaciones, ramificaciones; vectorización, caché friendly de la estructura.
Red/TLS: keep-alive, HTTP/2/3, conexión pooling, temporizadores correctos, reducción de la chatarra.
DB: índices, batchings, consultas preparadas, grupos de connects, división R/W, almacenamiento en caché de resultados, deduplicación de consultas.
Cachi: tamaño, TTL, request coalescing, protección contra tormentas, warming, bolas regionales.
Colas/corredores: límites de recepción/paralelismo, tamaño de batch, consumidores idempotent, techos DLQ.
Garbatage/pausas: afinación GC, alquiler de amortiguadores, pooling de objetos dentro de límites razonables.
I/O/disco: entrada/salida asíncrona, compresión, compresión de respuestas con un nivel razonable.

8) Límites y protección

Budget de los temporizadores: de arriba a abajo para evitar las cascadas.
Rate limit/token baquetas: degradación predecible en lugar de «muerte larga».
Circuit breaker y shading de baja prioridad en saturación.
Backpressure: señales y limitación del paralelismo hacia el interior de la cadena.
Bulkheads: aislamiento de las piscinas bajo endpoints críticos.
Idempotency: claves para repeticiones seguras bajo los retratos.

9) Herramientas y cuándo elegirlas

k6 es un JS conciso, excelente soporte para arrival-rate, integración y grafos.
Gatling - Scala DSL, un generador de alto rendimiento.
JMeter es flexible, rico en ecosistemas; conveniente para protocolos/complementos.
Locust - Python scripts, conveniente para la lógica compleja de flow personalizado.
Vegeta/hey/wrk - microbenches y correas de puntos en HTTP.
tc/netem, toxiproxy - inyección de degradación de red.
Flamegraph/profiler - Buscar «lugares calientes» CPU/heap.

10) Ejemplos (sketches)

k6 (modelo abierto, mix endpoints)

javascript import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
scenarios: {
open_model: {
executor: 'constant-arrival-rate',
rate: 800, timeUnit: '1s', duration: '20m',
preAllocatedVUs: 500, maxVUs: 2000
}
},
thresholds: {
'http_req_duration{kind:hot}': ['p(95)<200'],
'http_req_failed': ['rate<0. 005']
}
};

export default function () {
const r = Math. random();
let res;
if (r < 0. 6) {
res = http. get('https://svc/api/hot', { tags: { kind: 'hot' }});
} else if (r < 0. 9) {
res = http. get('https://svc/api/warm', { tags: { kind: 'warm' }});
} else {
res = http. post('https://svc/api/heavy', JSON. stringify({ n: 1000 }), { headers: { 'Content-Type': 'application/json' }});
}
check(res, { 'status is 2xx': (r) => r. status >= 200 && r. status < 300 });
sleep(0. 2);
}

Gatling (escalones y spike)

scala setUp(
scn. inject(
rampUsersPerSec(50) to 500 during (10 minutes),
constantUsersPerSec(500) during (20 minutes),
spikeUsers(2000). during(30. seconds)
)
). protocols(http. baseUrl("https://svc"))

Plan de carga (esqueleto YAML)

yaml profile: "mix-traffic"
targets:
- endpoint: GET /api/hot weight: 0. 6
- endpoint: GET /api/warm weight: 0. 3
- endpoint: POST /api/heavy weight: 0. 1 schedule:
- step: { rps: 300, hold: 10m }
- step: { rps: 600, hold: 10m }
- step: { rps: 900, hold: 10m }
guardrails:
slo:
p95_ms: 200 error_rate: 0. 5%
abort_if:
- metric: error_rate op: ">"
value: 2%
window: 2m

11) Automatización y ciclo de vida

Perf-smoke en cada PR (ejecución corta de endpoints clave).
Corridas nocturnas de «capacity» en el stage con reportes y artefactos de perfiles.
Gates en CI/CD: fail bild en regresión p95/p99> X% de basline o crecimiento de error rate.
Versionar baslines y almacenar perfiles/flamgrafos como artefactos.
Etiquetas de relevancia: qué servicio/endpoint está cubierto, qué perfil de tráfico se utiliza.

12) Anti-patrones

El generador y el servicio probado en la misma máquina → resultados distorsionados.
Sólo el modelo cerrado (VUs) para las APIs → una subestimación de las colas y una puntuación incorrecta.
Corridas a través de un CD/caché vacío sin un comienzo frío.
No hay distribuciones realistas (todas las solicitudes son iguales).
No hay telemetría (sólo RPS/latencia en el lado del generador).
Comparación sin bases estables y control del entorno.
«Optimización» a través de un aumento del tiempo de espera en lugar de corregir la causa.

13) Check-list del arquitecto

1. ¿Definidos los SLO y la carga tipo/pico?
2. ¿Ha seleccionado el modelo correcto (abierto/cerrado) y ha pintado el perfil de tráfico?
3. El stand es equivalente en confecciones y topología, ¿hay modo frío/caliente?
4. Telemetría y perfiles incluidos, ¿marcas de prueba de heridas colocadas?
5. Pasos: baseline/ramp/spike/stress/soak - ¿cubierto?
6. ¿Se fijan puntos de saturación y se planea un stock (margen de seguridad)?
7. ¿Límites configurados, rompedores, retroexcavadoras, idempotency, pólizas de shading?
8. Hay CI-Gates para la regresión p95/p99 y error rate, basline versionados?
9. Después de las ficciones - ¿Reprogon y actualización de playbook en potencia?
10. ¿Está documentado el plan de escala automática y los modos de emergencia?

Conclusión

Las pruebas de carga y estrés no son «carreras» únicas, sino una práctica de ingeniería continua. El modelo de tráfico realista, los stands correctos, la telemetría y la automatización en CI/CD convierten el rendimiento de la «magia secreta» en una capacidad controlada por métricas: sabes dónde está tu techo, qué tan seguro es el stock y qué cambios mejoran realmente la experiencia de los usuarios.