¿Qué es spike testing?

¿Qué es spike testing?

El spike testing (prueba de picos de carga) es un test de rendimiento que somete al sistema a un salto súbito y muy grande de carga y después la retira, para comprobar si sobrevive al pico y con qué rapidez se recupera. A diferencia de un test de carga con rampa, casi no hay meseta: la subida es empinada y el resultado se juzga por lo que ocurre durante y después de la ráfaga.

Para una guía más larga sobre cómo diseñar un spike test e interpretar el resultado, consulta spike testing in performance testing en el blog de LoadFocus (en inglés).

Spike testing frente a test de carga y test de estrés

Un test de carga sube usuarios de forma gradual y los mantiene en el nivel que esperas en un día fuerte. Un test de estrés va más allá para encontrar el punto de rotura (mira load testing vs stress testing, en inglés). El spike test se define por su forma: tráfico normal, salto casi instantáneo a un nivel muy alto, mantenimiento breve y vuelta a lo normal. Responden a preguntas distintas:

• Test de carga: ¿cumple el sistema sus objetivos en el pico esperado?
• Spike test: ¿qué pasa si el tráfico se multiplica en segundos? ¿El escalado reacciona a tiempo y el sistema vuelve a la normalidad después, o se queda degradado?

La carga máxima que el sistema aguanta de forma sostenida es otra pregunta, que responde el test de capacidad.

Cómo funciona un spike test

1. Línea base. Ejecuta tráfico realista unos minutos para que cachés, pools de conexiones y autoescaladores estén en su estado normal.
2. Pico. Sube el número de usuarios virtuales (o la tasa de peticiones) al objetivo en segundos, no en minutos.
3. Mantenimiento breve. Conserva el máximo uno o dos minutos. Muchos picos reales son cortos.
4. Bajada y observación. Vuelve a la línea base y deja correr el test lo bastante para ver si tiempos de respuesta y errores se recuperan.

Ejemplo (cifras ilustrativas): una tienda online envía una notificación push a las 10:00. El tráfico normal es de 50 usuarios concurrentes. El test salta a 1.000 usuarios virtuales en 10 segundos, se mantiene 2 minutos, baja a 50 y sigue 5 minutos más. La guía de k6 de Grafana usa una forma parecida: 2 minutos de subida hasta 2.000 usuarios, sin meseta, y 1 minuto de bajada a cero.

Los back-ends sin servidor son un buen motivo para hacerlo. Para AWS Lambda, la documentación indica por defecto 1.000 ejecuciones concurrentes por región y una tasa de escalado de 1.000 entornos de ejecución nuevos cada 10 segundos por función, de modo que una ráfaga puede adelantar al escalador y ser limitada. Más detalle en función sin servidor.

Qué medir

• Tasa de errores durante el pico. Algunos errores son esperables; importa cuáles (timeouts, 429, 502, 503) y si desaparecen al acabar el pico.
• Percentiles del tiempo de respuesta. Mira p95 y p99, no la media. Consulta latencia.
• Tiempo de recuperación. Segundos desde el final del pico hasta que tiempos y errores vuelven a la línea base.
• Comportamiento del back-end. Eventos del autoescalador, CPU, conexiones a la base de datos y profundidad de colas. Sin monitorización del back-end ves el síntoma pero no la causa.

Errores comunes

• Subir demasiado despacio. Una rampa de 10 minutos es un test de carga. Lo importante es que el escalado no tenga tiempo de prepararse.
• Parar cuando acaba el pico. Los fallos persistentes (pools de conexiones agotados, workers caídos que no se reiniciaron) solo aparecen en la fase de recuperación.
• Un origen, una URL. Los picos reales vienen de muchos sitios y tocan varios endpoints. Varía el recorrido y el origen.
• Cachés calientes. Una caché o CDN ya llena oculta lo que haría el arranque en frío del evento.
• Esperar un aprobado limpio. Los errores bajo un pico son habituales. Ejecuta, ajusta y repite hasta que el modo de fallo sea aceptable.

Spike test con LoadFocus

En LoadFocus load testing puedes fijar usuarios virtuales, duración y rampa de un plan de JMeter, o usar escenarios de k6 con executors como ramping-vus, y lanzarlos desde varias de las 25 regiones cloud a la vez. Los planes de pago llegan a 20.000 usuarios virtuales concurrentes por test. El plan Free se limita a 10 usuarios virtuales y 60 segundos: sirve para comprobar un script y su forma, pero no para generar un pico real.

Preguntas frecuentes

¿En qué se diferencia un spike test de un test de estrés?

Un test de estrés sigue subiendo la carga hasta romper el sistema. Un spike test aplica un único salto súbito y comprueba supervivencia y recuperación. El estrés pregunta cuánto; el spike, con qué rapidez.

¿Cuánto debe durar un spike test?

El pico suele durar de uno a unos pocos minutos. Añade una fase base antes y una de recuperación después: en total, normalmente de 10 a 20 minutos.

¿Necesito autoescalado para hacer un spike test?

No. Sin autoescalado, el test muestra cuánto margen tiene la capacidad fija. Con autoescalado, muestra además si la capacidad nueva llega antes de que los usuarios lo noten.

¿Debo hacer un spike test en producción?

Mejor en un entorno de staging del tamaño de producción. Si no hay alternativa, acuerda una ventana horaria, empieza con poca carga y asegúrate de que alguien vigila el back-end.