Tu aplicación funciona perfectamente con diez usuarios. ¿Qué pasa el día de la venta, con diez mil? Pruebas de carga versus pruebas de estrés describe dos formas diferentes de responder a esta pregunta, y mezclarlas conduce a pruebas que no prueban lo que usted cree que sí.

Esta guía explica qué muestra cada uno, los tipos de pruebas relacionadas y cómo leer los resultados. Ejecutamos el cálculo del percentil pequeño a continuación en Python 3.13, con números simulados. Los scripts k6 son ejemplos ilustrativos que no ejecutamos, y los recuentos de usuarios y los objetivos son inventados, así que reemplácelos por los suyos propios. Ejecute estas pruebas únicamente en sistemas de su propiedad o que tenga permiso para realizar pruebas, ya que el tráfico intenso puede parecer un ataque y provocar interrupciones reales.

La respuesta corta

Una prueba de carga pregunta: ¿podemos manejar el tráfico que esperamos y cumplir nuestros objetivos mientras lo hacemos? Una prueba de estrés pregunta: ¿cuánto podemos tomar antes de fallar, cómo fallamos y qué tan rápido nos recuperamos?

Piense en un puente. Una prueba de carga recorre el número esperado de camiones y confirma que está bien. Una prueba de estrés sigue agregando peso para conocer su límite y si avisa primero. Afortunadamente, es más barato romper un software que un puente.

Pruebas de carga frente a pruebas de estrés una al lado de la otra

¿Qué son las pruebas de carga?

Las pruebas de carga simulan el tráfico realista esperado y miden cómo se comporta el sistema. Necesita un objetivo con el que realizar la prueba, por ejemplo: “con 500 usuarios simultáneos, el 95 % de las solicitudes de pago finalizan en 800 ms, con menos del 1 % de errores”.

Así es como podría verse como un script k6. Las pruebas de k6 están escritas en JavaScript y thresholds convierten sus objetivos en un resultado de aprobado o reprobado:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

El sleep importa. Sin tiempo para pensar, cada usuario virtual golpea el servidor continuamente, produciendo mucho más tráfico que el mismo número de personas reales.

¿Qué son las pruebas de estrés?

Las pruebas de estrés van deliberadamente más allá de los niveles esperados. No estás intentando pasar. Quiere respuestas a preguntas como:

• ¿A qué nivel el rendimiento empieza a desmoronarse?
• ¿Qué componente falla primero: la base de datos, los servidores de aplicaciones o una llamada de un tercero?
• ¿Falla elegantemente con errores claros o falla y pierde datos?
• ¿Se recupera por sí solo cuando cae el tráfico?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

Esa etapa final de recuperación con frecuencia se olvida y puede ser la más valiosa. Un sistema que maneja bien las fallas pero que nunca se recupera sin un reinicio manual aún significa una interrupción que alguien debe arreglar en medio de la noche. Idealmente, bajo una carga extrema, un sistema debería deshacerse del trabajo de forma controlada, devolviendo 503 respuestas claras en lugar de agotarse el tiempo.

Spike, remojo y otros tipos

Las pruebas de carga y estrés pertenecen a una familia más amplia de pruebas de rendimiento:

Las pruebas de inmersión detectan problemas que las pruebas cortas nunca detectan. Una pequeña pérdida de memoria puede parecer inofensiva durante veinte minutos y sólo provocar que el servicio se caiga después de dos días. Las pruebas de picos se adaptan a eventos como las ventas flash, donde el tráfico no aumenta gradualmente.

Métricas que importan

¿Por qué los promedios engañan?

Los promedios ocultan las solicitudes lentas de las que se queja la gente real. Para mostrar esto, generamos 100 tiempos de respuesta simulados, donde 95 fueron rápidos (80 a 200 ms) y 5 fueron muy lentos (2,5 a 4 segundos), luego calculamos las estadísticas comunes:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Mire de cerca esos números. La media de 302 ms no describe a nadie. Las solicitudes típicas tardaron unos 150 ms, mientras que las lentas tardaron más de 3 segundos. Incluso p95 parece saludable a 199 ms, y sólo p99 revela el problema. Una cifra como p95 significa que el 95% de las solicitudes fueron así de rápidas o más rápidas.

Y el uno por ciento de las solicitudes no es un hecho raro. Si una página realiza 50 solicitudes, un p99 lento afecta a una gran proporción de visitas a la página. Establezca objetivos en los percentiles que le interesen y analicen varios juntos.

Herramientas

Cualquiera de estos puede ejecutar pruebas de carga y de estrés. Elija el que se ajuste a las habilidades de su equipo, en lugar de buscar una lista de funciones. Para usar uno en su canalización, consulte qué es CI/CD.

Cómo planificar una prueba

1. Establezca objetivos. Utilice análisis reales para encontrar su tráfico pico y defina objetivos.
2. Elija recorridos. Modele comportamientos de usuario realistas, como navegación, búsqueda y pago, en proporciones realistas. Acceder sólo a la página de inicio resulta poco.
3. Utilice un entorno realista. Un servidor de prueba pequeño no puede predecir la producción. Tenga en cuenta cualquier diferencia.
4. Prepare los datos. Utilice volúmenes realistas, porque una consulta que es rápida en 100 filas puede rastrear 10 millones.
5. Advertir a la gente. Informe a su equipo de operaciones y a terceros, y no realice pruebas de carga a un proveedor de pagos por accidente. Simular servicios externos cuando corresponda.
6. Empiece poco a poco. Primero ejecute una pequeña prueba de humo para confirmar que su script funciona.
7. Supervise todo. Sin métricas del servidor, verá que se ralentizó, pero no por qué.
8. Repetir. Ejecútelo nuevamente después de cada corrección y mantenga una línea de base para comparar.

leyendo los resultados

Las bases de datos son un cuello de botella común, por lo que si el problema son las consultas, lea nuestra guía para optimización de consultas SQL. Esa última fila de la tabla es una trampa importante: verifique siempre también el estado de la máquina que genera la carga.

Errores comunes

• Confundir a los usuarios con las solicitudes. Deje claro si un objetivo significa usuarios simultáneos o solicitudes por segundo.
• Dejar de lado el tiempo para pensar. Esto aumenta el tráfico y genera resultados engañosos.
• Pruebas demasiado tarde. Una semana antes del lanzamiento no deja tiempo para solucionar problemas de arquitectura.
• Utilizando un único punto final. El tráfico real combina lecturas, escrituras y búsquedas.
• El almacenamiento en caché lo oculta todo. Es posible que las solicitudes repetidas idénticas solo prueben su caché, así que varíe los datos.
• Prueba una vez. El rendimiento cambia con cada versión, así que ejecute pruebas con regularidad.

Conclusión

Ejecute pruebas de carga para confirmar que puede manejar el tráfico que espera y pruebas de estrés para saber qué sucede cuando no puede. Empiece poco a poco: elija el recorrido del usuario más importante, establezca un objetivo claro y ejecute una prueba breve en comparación con la puesta en escena con la supervisión activada. Esa primera ejecución normalmente te enseña algo y puedes construir a partir de ahí.

Preguntas frecuentes

sigue aprendiendo