Las pruebas de carga y rendimiento simulan el tráfico que esperas en un lanzamiento o una campaña y miden cómo responde tu aplicación antes de que lleguen los usuarios. Con herramientas como k6 o Apache JMeter fijas umbrales de tiempo de respuesta y de errores, y sabes si el sistema aguanta. Si tu web ya está en marcha, encajan en un plan de mantenimiento web en Madrid con optimización de velocidad.
Una campaña de pago sigue cobrando cada clic aunque la página de destino devuelva errores. Si la aplicación se satura el día del lanzamiento, pagas el tráfico y pierdes la venta. El testing automatizado de aplicaciones web con Playwright y CI verifica que todo funciona; la prueba de carga, que sigue funcionando con miles de usuarios a la vez.
Al terminar sabrás qué prueba lanzar antes de una campaña y qué umbral incluir en las pruebas de aceptación formales del software si trabajas con un proveedor.
Qué son las pruebas de carga y rendimiento
Las pruebas de carga y rendimiento son ejecuciones controladas que generan peticiones contra una aplicación a un ritmo definido y registran cuánto tarda cada respuesta y cuántas fallan. Su resultado responde a una pregunta de negocio concreta: cuántos usuarios simultáneos soporta el sistema sin degradar la experiencia ni perder pedidos.
Se diferencian de las métricas de Core Web Vitals y su impacto en SEO, que miden lo que percibe un único visitante en su navegador. La prueba de carga mide el servidor cuando todos llegan a la vez.
Tipos de pruebas de carga según lo que quieres saber
Cada tipo de prueba de carga responde a una pregunta distinta. La guía de tipos de prueba de Grafana k6 los clasifica en seis:
- Smoke: valida que el script funciona con carga mínima.
- Average-load: reproduce el tráfico normal esperado.
- Stress: supera la carga media para ver cómo se comporta el sistema en su límite.
- Spike: simula un pico súbito y corto, como el envío de una newsletter o un anuncio en televisión.
- Soak: mantiene la carga durante horas para destapar fugas de memoria y conexiones que no se liberan.
- Breakpoint: sube la carga de forma gradual hasta encontrar el punto de rotura.
Antes de una campaña, ejecuta como mínimo un smoke y después un spike con el doble del tráfico previsto. En aplicaciones serverless, el spike destapa además el arranque en frío que compara el artículo de serverless frente a contenedores en una aplicación de empresa.
k6 o JMeter para pruebas de rendimiento
Grafana k6 y Apache JMeter son dos herramientas de código abierto para pruebas de rendimiento, y se eligen por cómo trabaja tu equipo:
- Grafana k6: Scripts: JavaScript, versionables junto al código. Integración: si un umbral falla, k6 termina con código de salida distinto de cero y el pipeline se detiene.
- Apache JMeter: Base: aplicación 100% Java, versión 5.6.3 con Java 8 o superior según la página de descargas de Apache JMeter. Protocolos: además de HTTP, prueba SOAP, REST, JDBC y JMS desde una interfaz gráfica.
El modelo de carga importa tanto como la herramienta. En un modelo cerrado, cada usuario virtual espera a terminar su petición antes de lanzar otra, así que si el servidor se frena la prueba también afloja. La literatura de pruebas llama a ese sesgo coordinated omission, y k6 lo evita con los ejecutores de tasa de llegada, que siguen un modelo abierto.
Métricas y cuellos de botella que deciden el lanzamiento
Las métricas que deciden si puedes lanzar son pocas y se fijan como umbral antes de ejecutar la prueba:
- Percentil 95 del tiempo de respuesta: la media esconde a los usuarios lentos. El p95 marca a partir de cuánto espera el 5% peor servido.
- Tasa de errores: respuestas 5xx y tiempos de espera agotados. El ejemplo de umbral de la documentación de k6 la fija por debajo del 1%.
- Saturación de recursos: CPU y conexiones abiertas en la base de datos durante la prueba, leídas en la monitorización de trazas y alertas en producción.
Cuando la prueba se rompe, revisa primero la capa de datos. Las consultas sin índice o el límite de conexiones se trabajan con una optimización de PostgreSQL para alto tráfico, y las lecturas repetidas se descargan con una caché en Redis para aplicaciones web.
CodeZone Pro Tip: define en k6 un pico con tasa de llegada programada y umbrales que cortan la prueba en cuanto se rompe el objetivo de servicio.
// pico-campana.js · ejecutar con: k6 run -e BASE_URL=<url de preproducción> pico-campana.js
import http from 'k6/http';
import { check } from 'k6';
export const options = {
scenarios: {
pico_campana: {
// Tasa de llegada programada: si el servidor se frena, la carga no afloja
executor: 'ramping-arrival-rate',
startRate: 10,
timeUnit: '1s',
preAllocatedVUs: 100,
maxVUs: 400,
stages: [
{ target: 50, duration: '2m' }, // tráfico previsto de la campaña
{ target: 100, duration: '1m' }, // pico al doble del previsto
{ target: 0, duration: '1m' },
],
},
},
thresholds: {
// Objetivo de servicio: el 95% de las peticiones por debajo de 500 ms
http_req_duration: [{ threshold: 'p(95)<500', abortOnFail: true, delayAbortEval: '30s' }],
// Menos de un 1% de errores; si se supera, k6 sale con código distinto de cero
http_req_failed: ['rate<0.01'],
},
};
export default function () {
const res = http.get(`${__ENV.BASE_URL}/`);
// Sin sleep: con tasa de llegada, el ejecutor ya marca el ritmo de iteraciones
check(res, { 'respuesta 200': (r) => r.status === 200 });
}Este script convierte el plan de medios en una cifra comprobable: si la portada no responde en medio segundo al doble del tráfico previsto, la prueba se para y sabes que hay que optimizar antes de activar la campaña.
Lo Que Cuesta Descubrir el Límite el Día de la Campaña
Descubrir el límite con usuarios reales cuesta el presupuesto de medios y la confianza del cliente que encontró la web caída. Medirlo antes cuesta un script y una ventana de pruebas en preproducción. Repite la prueba tras cada cambio grande de infraestructura, porque el límite se mueve con cada despliegue.
En Codezone preparamos y ejecutamos pruebas de carga sobre una réplica de tu entorno y te entregamos los cuellos de botella priorizados. Dinos cuándo es tu próxima campaña y cuánto tráfico esperas y medimos si tu aplicación llega.
