¿Qué es spike testing?

¿Qué es spike testing?

Spike testing es un test de rendimiento que lanza una ráfaga súbita y aguda de tráfico contra un sistema (típicamente 5-10x la carga normal, rampada en segundos en lugar de minutos) y mide si el sistema absorbe el spike, degrada con elegancia o falla del todo. El objetivo es validar elastic scaling, tiempo de reacción del autoscaler y la capacidad del sistema para recuperarse cuando el spike cae.

Spike testing vs load testing

Un load test rampa usuarios durante minutos y se mantiene en la concurrencia objetivo durante una ventana sostenida. Verificación bajo peak esperado. Un spike test salta de carga normal a muy por encima del peak casi al instante, luego vuelve a caer. La forma es la diferencia: load es una meseta plana, spike es una torre alta y estrecha.

Las preguntas que cada uno responde difieren:

• Load test: ¿puede mi sistema cumplir SLOs en el peak esperado?
• Spike test: ¿qué pasa cuando el tráfico se duplica en 30 segundos? ¿Reacciona el autoscaling a tiempo? ¿Se recupera el sistema cuando el spike baja, o se queda degradado?

Cuándo ejecutar spike tests

• Antes de un evento conocido con tráfico burst. Lanzamiento de producto, campaña de marketing viral, minuto cero de Black Friday, fanout programado de push notifications.
• Para validar autoscaling. Si tu infraestructura depende de AWS Auto Scaling Groups, Kubernetes HPA o límites de ejecución concurrente de Lambda, los spike tests confirman que el scaler reacciona antes de que la cresta del spike pase.
• Para testear comportamiento de rate-limit y circuit-breaker. ¿Tu API gateway descarga peticiones con elegancia o devuelve 5xx?
• Tras cambios de CDN o edge-cache. ¿La caché absorbe el spike o estampida al origin?

Para la carga máxima sostenible que un sistema maneja (en lugar de la ráfaga que puede absorber), ver capacity testing.

Métricas clave de spike test

1. Tiempo a estabilizarse. Segundos desde el inicio del spike hasta que el sistema vuelve a percentiles normales de response time. Tiempos largos indican latencia del autoscaler.
2. Error rate durante el spike. Picos 5xx breves son normales; sostenido >1% significa que la capacidad se agotó.
3. Curva de recuperación tras caída del spike. ¿Vuelve el sistema al baseline en un minuto, o se queda degradado decenas de minutos (señal de fallos pegajosos, pools de conexión muertos, workers OOM-killed que no rearrancaron)?
4. Tiempo de reacción del autoscaler. Métrica cloud-side: ¿añadió capacidad el ASG / HPA, y cuándo?

Cómo ejecutar un spike test

Mismos scripts que load testing, perfil de carga distinto. En JMeter, usa el plugin Ultimate Thread Group para definir un ramp escalonado o instantáneo desde una baseline pequeña al objetivo del spike. En k6, configura un escenario ramping-arrival-rate con una etapa de ramp-up afilada, mantén 60-300 segundos, después rampa de bajada.

Ejecuta el spike desde LoadFocus cuando necesites tráfico desde múltiples regiones cloud golpeando simultáneamente. Los spike tests single-source pierden el patrón geo-distribuido de una campaña real.

Si prefieres no escribir los scripts de spike test tú mismo, LoadFocus ofrece load testing services donde los ingenieros construyen y ejecutan los escenarios para tu perfil de tráfico.