Performance
Volver a todos los artículos
performance

Prueba de Carga con k6: Una Introducción Práctica

Performance360 Engineering2 min de lectura

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.