Prueba de Carga con k6: Una Introducción Práctica
La mayoría de las fallas en pruebas de carga no vienen de la herramienta — vienen de probar lo que no hay que probar. Un solo endpoint bombardeado a 1.000 requests por segundo no te dice casi nada sobre cómo se comporta tu sistema cuando usuarios reales atraviesan un checkout, un login o una búsqueda reales.
Por qué elegimos k6
Somos agnósticos de herramientas por diseño, pero k6 se convirtió en nuestro punto de partida por defecto por unas cuantas razones concretas:
- Los scripts son JavaScript, así que los mismos ingenieros que escriben tu automatización de pruebas pueden escribir tus pruebas de carga sin aprender un DSL nuevo.
- Los thresholds son de primera clase. Definís los criterios de éxito/falla (
p95 < 300ms,error rate < 1%) directamente en el script, así una prueba de carga puede hacer fallar un pipeline de CI de la misma forma que un test unitario. - La salida se integra limpiamente con Grafana y Prometheus, algo que importa una vez que la prueba de carga deja de ser un evento aislado y pasa a ser parte de tu proceso de release.
Estructurar alrededor de un recorrido, no de un endpoint
Un script de prueba de carga útil refleja lo que es una sesión real:
import http from 'k6/http';
import { sleep, check } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 50 },
{ duration: '5m', target: 50 },
{ duration: '2m', target: 0 },
],
thresholds: {
http_req_duration: ['p(95)<300'],
http_req_failed: ['rate<0.01'],
},
};
export default function () {
const login = http.post(`${__ENV.BASE_URL}/login`, { user: 'test', pass: 'test' });
check(login, { 'logged in': (r) => r.status === 200 });
sleep(1);
const search = http.get(`${__ENV.BASE_URL}/search?q=laptop`);
check(search, { 'search ok': (r) => r.status === 200 });
sleep(2);
}
Notá que no hay un único objetivo fijo — stages sube, sostiene y baja la carga, que es lo que realmente revela los límites de capacidad en vez de solo confirmar que un servidor sobrevive a una ráfaga fija.
A dónde lleva esto
Una prueba de carga que refleja el uso real es también una prueba cuyos resultados son accionables: cuando el p95 se rompe, sabés exactamente qué paso del recorrido se degradó, no solo que “la API está lenta”. Esa es la diferencia entre un número en un reporte y un hallazgo sobre el que un equipo de ingeniería puede actuar.
Vamos a seguir esto con una nota sobre cómo distribuir corridas de k6 en distintas regiones para simular geografía de tráfico realista — suscribite por RSS para enterarte.