Pregunta 195 / 200Intermedio Sin código

¿Cómo es una metodología real de testing de carga/performance — qué medís realmente y cómo diseñás el test?

El testing de carga no es 'pegarle mucho a la API y ver qué pasa' — es una rampa diseñada con objetivos explícitos de pass/fail, percentiles de latencia de cola, y un ojo atento al propio modelo de carga.

APRENDE HACIENDOPon a prueba tu intuición3 pasos

Antes de leer la guía, escribe tu respuesta con un ejemplo concreto.

Usa los ejemplos y la explicación de la lección para comprobar tu idea.

Reflexión personal. No se envía a ningún servicio de IA.

#El Testing de Carga Responde una Pregunta Distinta a "¿Funciona?"

Los tests funcionales responden "¿el sistema produce la salida correcta?". El testing de carga responde una pregunta completamente distinta: "¿cómo cambia el comportamiento del sistema — latencia, tasa de error, uso de recursos — a medida que aumenta la demanda concurrente, y en qué punto deja de escalar de forma controlada?" Un sistema puede ser funcionalmente perfecto y aun así caerse bajo carga porque un pool de conexiones se agota, un lock se convierte en cuello de botella, o las pausas de garbage collection empiezan a dominar el tiempo de respuesta una vez que hay suficientes requests en vuelo al mismo tiempo. Nada de eso aparece llamando a la API una vez y chequeando la respuesta.

#Las Cuatro Formas de un Test de Carga

Test de carga — subí hasta tu pico de tráfico esperado (por ejemplo, "Black Friday, 3x lo normal") y sostenelo, para confirmar que el sistema cumple sus objetivos de latencia y tasa de error en ese nivel.
Test de estrés — seguí aumentando la carga más allá del pico esperado hasta que algo se rompa, específicamente para encontrar el punto de quiebre y cómo falla (degradación controlada con errores claros, versus una caída en cascada).
Test de resistencia (soak) — sostené una carga moderada y sostenible durante horas, para atrapar problemas que solo aparecen con el tiempo: memory leaks, agotamiento del pool de conexiones, discos de logs llenándose, degradación lenta que un test corto no revelaría.
Test de pico (spike) — saltá el tráfico de golpe desde la línea base a varias veces lo normal, sin rampa, para chequear si el autoescalado y los pools de conexiones reaccionan lo suficientemente rápido, o si el salto repentino en sí mismo causa fallas en cascada.

#Diseñando un Test de Carga: La Forma en el Tiempo

La rampa de subida importa tanto como el estado estable: saltar directo al pico esconde cómo se comporta el sistema mientras los autoescaladores, pools de conexiones y cachés todavía se están calentando, que es exactamente la condición que produce un pico de tráfico real. Sostener un estado estable el tiempo suficiente (no solo un minuto) es lo que separa una señal real del ruido — ráfagas cortas pueden verse bien únicamente porque un pool de conexiones todavía tenía margen sobrante de antes de que empezara el test.

#Qué Medís Realmente, y Por Qué Importa Cada Cosa

Métrica	Por qué importa	Error común
Latencia p50 (mediana)	Lo que experimenta un request "típico"	Tratarla como representativa de todo el sistema -- esconde todo lo que pasa en la cola de la distribución
Latencia p95 / p99	Lo que sienten tus usuarios con más mala suerte; a menudo 5-10x la mediana bajo carga	Reportar solo el promedio, que un puñado de requests muy lentos apenas mueve
Tasa de error (%)	Timeouts, errores 5xx y conexiones caídas a medida que aumenta la carga	No distinguir errores del cliente (requests mal formados) de errores del servidor (problemas de capacidad)
Throughput (requests/seg)	La tasa sostenida que el sistema realmente puede procesar, no solo aceptar	Confundir "requests enviados" con "requests completados con éxito"
Punto de saturación	El recurso específico que llega primero a su techo -- CPU, pool de conexiones de BD, thread pool, profundidad de cola -- y dónde la latencia se dispara visiblemente	No correlacionar métricas de aplicación con métricas de infraestructura en la misma línea de tiempo, así que ves que se rompió pero no por qué

#La Trampa que Vigilan los Ingenieros Senior: Coordinated Omission

Heads up

Un modelo de carga cerrado — donde cada usuario virtual espera a que termine su request actual antes de enviar el siguiente — subestima silenciosamente el dolor de una degradación real. Si el servidor se vuelve más lento, cada usuario virtual emite menos requests por segundo, así que la tasa de requests medida por el propio generador de carga baja justo cuando las cosas están empeorando, escondiendo la verdadera latencia de cola detrás de una muestra más chica de "respuestas que sí volvieron". Un modelo de carga abierto — que emite nuevos requests en un cronograma fijo sin importar si los anteriores ya volvieron — refleja mejor cómo se comportan usuarios reales e independientes (no esperan educadamente a que se resuelva el último click antes de hacer el siguiente), y saca a la luz explosiones de latencia de cola que un modelo cerrado puede promediar silenciosamente hasta esconderlas. Esta brecha entre la latencia medida y la real bajo carga se suele llamar coordinated omission, y es una de las razones más comunes por las que un test de carga reporta "se ve bien" una semana antes de un incidente real con la misma forma de tráfico.

#Diseñando el Test en Sí: una Checklist Práctica

Definí el pass/fail antes de correrlo. "p95 bajo 300ms y tasa de error bajo 0.1% con 500 usuarios concurrentes" es un objetivo testeable; "a ver cómo le va" no lo es — necesitás un SLO contra el cual comparar, no solo un gráfico para mirar después.
Modelá tráfico realista, no tráfico uniforme. Los sistemas reales tienen una mezcla de lecturas baratas y escrituras costosas, patrones de acceso sesgados (algunos registros son mucho más calientes que otros), y tiempo de espera entre los requests de un usuario — un test de carga que golpea un solo endpoint uniformemente lo más rápido posible prueba algo, pero no lo que parece el tráfico de producción.
Igualá la topología y el volumen de datos de producción. Un test de carga contra una base de datos con 500 filas y una caché caliente va a pasar sin importar planes de consulta que se desmoronan con la cantidad real de filas de producción; testeá contra un dataset de tamaño realista, y considerá probar con caché fría al menos una vez.
Correlacioná métricas de aplicación e infraestructura en la misma línea de tiempo. La latencia y la tasa de error te dicen que algo se degradó; la CPU, la memoria, el uso del pool de conexiones de la BD y la profundidad de cola, vistos en el mismo eje temporal, te dicen qué se saturó primero.
Automatizá la versión de camino crítico como gate de regresión. Un test de carga liviano contra los endpoints clave, corrido en un cronograma o antes de releases importantes, atrapa regresiones de performance mucho antes de que un test de estrés encuentre el punto de quiebre absoluto — no necesitás correr toda la suite de estrés en cada deploy para sacarle valor al testing de carga en CI/CD.

🧠 Check your understanding
0/2 · 0/2 answered
1. Un generador de carga usa un modelo de carga cerrado, donde cada usuario virtual espera una respuesta antes de enviar su siguiente request. ¿Cuál es el riesgo específico que esto genera?
2. ¿Qué métrica refleja mejor lo que realmente están experimentando tus usuarios con menos suerte bajo carga?

¿Cómo se testea de forma confiable código asíncrono/concurrente sin sleeps inestables?¿Cómo es el testing de caos y resiliencia cuando forma parte del CI en lugar de ser un GameDay puntual?