Prueba de carga

Una prueba de carga (load testing) somete un sistema al tráfico que realmente se espera, normalmente el pico de carga habitual, y mide cómo se comporta: percentiles de latencia, tasa de errores, throughput (rendimiento) y uso de recursos. La pregunta que responde es “¿cumple sus objetivos de rendimiento con la carga que tenemos prevista?”. No se trata de romper el sistema; eso es una prueba de estrés.

Ejemplo (k6)

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

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // ramp up to 100 virtual users
    { duration: '10m', target: 100 }, // hold at expected peak
    { duration: '1m', target: 0 },    // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1200'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/products');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1); // think time between iterations
}

Si se supera cualquiera de los umbrales, k6 termina con un código distinto de cero, de modo que el mismo script puede funcionar como compuerta (gate) en CI.

Carga, estrés, resistencia y picos

Tipo	Perfil de carga	Pregunta que responde
Carga	Pico esperado, sostenido	¿Cumplimos los objetivos en el pico normal?
Estrés	Creciente, por encima de lo esperado	¿Dónde y cómo se rompe, y se recupera?
Resistencia (soak)	Carga normal durante horas	¿Se degrada con el tiempo (fugas, agotamiento de pools)?
Pico (spike)	Salto repentino y luego caída	¿Sobrevive a una ráfaga y vuelve a escalar hacia abajo?

Cómo hacerlo bien

• Modela el tráfico real. Usa la combinación de endpoints, tamaños de payload y tiempos de reflexión (think time) que muestran las analíticas de producción, no una única URL martilleada en bucle.
• Usa un entorno similar a producción. Los resultados de un servidor de staging infradimensionado solo hablan de ese servidor.
• Juzga por percentiles, no por promedios. Un promedio oculta la cola lenta, que es precisamente de lo que se quejan los usuarios.
• Observa también el lado del servidor. CPU, memoria, conexiones a la base de datos y profundidad de colas explican por qué cambió la latencia.
• Acuerda los objetivos antes. Sin una meta explícita como “p95 por debajo de 500 ms a 200 solicitudes por segundo”, una prueba de carga produce números, pero no un veredicto.