Qu'est-ce que le spike testing ?

Qu'est-ce que le spike testing ?

Le spike testing est un test de performance qui envoie une rafale soudaine et nette de trafic contre un système (typiquement 5-10x la charge normale, rampée en secondes plutôt qu'en minutes) et mesure si le système absorbe le spike, se dégrade gracieusement ou échoue franchement. L'objectif est de valider l'elastic scaling, le temps de réaction de l'autoscaler et la capacité du système à récupérer quand le spike retombe.

Spike testing vs load testing

Un load test rampe les utilisateurs sur des minutes et tient à la concurrence cible pour une fenêtre soutenue. Vérification sous peak attendu. Un spike test saute de la charge normale à bien au-dessus du peak presque instantanément, puis retombe. La forme fait la différence : load est un plateau plat, spike est une tour haute et étroite.

Les questions que chacun répond diffèrent :

• Load test : mon système peut-il atteindre les SLOs au peak attendu ?
• Spike test : que se passe-t-il quand le trafic double en 30 secondes ? L'autoscaling réagit-il à temps ? Le système récupère-t-il quand le spike retombe, ou reste-t-il dégradé ?

Quand exécuter des spike tests

• Avant un événement connu à trafic burst. Lancement de produit, campagne marketing virale, minute zéro du Black Friday, fanout programmé de push notifications.
• Pour valider l'autoscaling. Si votre infrastructure dépend d'AWS Auto Scaling Groups, Kubernetes HPA ou des limites d'exécution concurrente de Lambda, les spike tests confirment que le scaler réagit avant que la crête du spike ne passe.
• Pour tester le comportement rate-limit et circuit-breaker. Votre API gateway délaisse-t-elle des requêtes gracieusement ou renvoie-t-elle des 5xx ?
• Après des changements CDN ou edge-cache. Le cache absorbe-t-il le spike ou est-ce une ruée vers l'origin ?

Pour la charge maximale soutenable qu'un système gère (plutôt que la rafale qu'il peut absorber), voir capacity testing.

Métriques clés de spike test

1. Temps pour se stabiliser. Secondes du début du spike jusqu'au retour du système aux percentiles normaux de response time. Les temps longs indiquent une latence de l'autoscaler.
2. Error rate pendant le spike. Brefs blips 5xx sont normaux ; soutenu >1% signifie que la capacité s'est épuisée.
3. Courbe de récupération après chute du spike. Le système revient-il au baseline en une minute, ou reste-t-il dégradé pendant des dizaines de minutes (signe de pannes collantes, pools de connexion morts, workers OOM-killed qui n'ont pas redémarré) ?
4. Temps de réaction de l'autoscaler. Métrique côté cloud : l'ASG / HPA a-t-il ajouté de la capacité, et quand ?

Comment exécuter un spike test

Mêmes scripts que load testing, profil de charge différent. Dans JMeter, utilisez le plugin Ultimate Thread Group pour définir un ramp étagé ou instantané d'une petite baseline vers la cible du spike. Dans k6, configurez un scénario ramping-arrival-rate avec une étape de ramp-up aiguë, tenez 60-300 secondes, puis rampez à la descente.

Exécutez le spike depuis LoadFocus quand vous avez besoin de trafic depuis plusieurs régions cloud frappant simultanément. Les spike tests single-source manquent le pattern géo-distribué d'une vraie campagne.

Si vous préférez ne pas écrire vous-même les scripts de spike test, LoadFocus propose des load testing services où les ingénieurs construisent et exécutent les scénarios pour votre profil de trafic.