Qu'est-ce que le spike testing ?

Qu'est-ce que le spike testing ?

Le spike testing (test de pic de charge) est un test de performance qui soumet un système à un saut soudain et très important de charge, puis la retire, pour vérifier s'il survit au pic et à quelle vitesse il récupère. Contrairement à un test de charge avec montée progressive, il n'y a presque pas de palier : la montée est raide, et le résultat se juge sur ce qui se passe pendant et après la rafale.

Pour un guide plus complet sur la conception d'un spike test et la lecture de son résultat, voir spike testing in performance testing sur le blog LoadFocus (en anglais).

Spike testing, test de charge et test de stress

Un test de charge fait monter les utilisateurs progressivement et les maintient au niveau attendu un jour de forte affluence. Un test de stress dépasse ce niveau pour trouver le point de rupture (voir load testing vs stress testing, en anglais). Le spike test se définit par sa forme : trafic normal, saut quasi instantané vers un niveau très élevé, maintien bref, retour à la normale. Les questions posées diffèrent :

• Test de charge : le système tient-il ses objectifs au pic attendu ?
• Spike test : que se passe-t-il quand le trafic est multiplié en quelques secondes ? La montée en charge réagit-elle à temps, et le système revient-il à la normale ensuite ou reste-t-il dégradé ?

La charge maximale supportée durablement est une autre question, traitée par le test de capacité.

Comment se déroule un spike test

1. Référence. Faites tourner un trafic réaliste quelques minutes pour que caches, pools de connexions et autoscalers soient dans leur état normal.
2. Pic. Portez le nombre d'utilisateurs virtuels (ou le débit de requêtes) à la cible en quelques secondes, pas en minutes.
3. Maintien bref. Gardez le maximum une à deux minutes. Beaucoup de pics réels sont courts.
4. Retour et observation. Revenez à la référence et laissez tourner assez longtemps pour voir si temps de réponse et erreurs se rétablissent.

Exemple (chiffres illustratifs) : une boutique en ligne envoie une notification push à 10 h 00. Le trafic normal est de 50 utilisateurs simultanés. Le test passe à 1 000 utilisateurs virtuels en 10 secondes, tient 2 minutes, retombe à 50 et continue 5 minutes. Le guide k6 de Grafana utilise une forme proche : 2 minutes de montée jusqu'à 2 000 utilisateurs, aucun palier, puis 1 minute de descente à zéro.

Les back-ends sans serveur sont une bonne raison d'en faire un. Pour AWS Lambda, la documentation indique par défaut 1 000 exécutions simultanées par région et un rythme de montée en charge de 1 000 nouveaux environnements d'exécution toutes les 10 secondes par fonction : une rafale peut donc dépasser le scaler et être limitée. Détails dans fonction sans serveur.

Que mesurer

• Taux d'erreurs pendant le pic. Quelques erreurs sont attendues ; ce qui compte, c'est lesquelles (timeouts, 429, 502, 503) et si elles cessent à la fin du pic.
• Percentiles du temps de réponse. Regardez p95 et p99, pas la moyenne. Voir latence.
• Temps de récupération. Secondes entre la fin du pic et le retour des temps de réponse et des erreurs à la référence.
• Comportement du back-end. Événements de l'autoscaler, CPU, connexions à la base de données et profondeur des files. Sans supervision du back-end, vous voyez le symptôme mais pas la cause.

Erreurs fréquentes

• Monter trop lentement. Une montée de 10 minutes est un test de charge. L'intérêt est que la montée en charge n'ait pas le temps de se préparer.
• S'arrêter à la fin du pic. Les pannes persistantes (pools de connexions épuisés, workers plantés non redémarrés) n'apparaissent que pendant la récupération.
• Une source, une URL. Les vrais pics viennent de partout et touchent plusieurs endpoints. Variez le parcours et l'origine.
• Caches chauds. Un cache ou un CDN déjà rempli masque ce que donnerait le démarrage à froid de l'événement.
• Attendre un succès net. Les erreurs sous un pic sont courantes. Exécutez, ajustez, recommencez jusqu'à ce que le mode de défaillance soit acceptable.

Spike test avec LoadFocus

Avec LoadFocus load testing, vous réglez utilisateurs virtuels, durée et montée en charge d'un plan JMeter, ou vous utilisez des scénarios k6 avec des executors comme ramping-vus, et vous les lancez depuis plusieurs des 25 régions cloud à la fois. Les offres payantes vont jusqu'à 20 000 utilisateurs virtuels simultanés par test. L'offre Free est limitée à 10 utilisateurs virtuels et 60 secondes : suffisant pour vérifier un script et sa forme, pas pour créer un vrai pic.

Questions fréquentes

En quoi un spike test diffère-t-il d'un test de stress ?

Un test de stress augmente la charge jusqu'à la rupture. Un spike test applique un seul saut soudain et vérifie la survie et la récupération. Le stress demande combien ; le spike, à quelle vitesse.

Combien de temps doit durer un spike test ?

Le pic dure souvent d'une à quelques minutes. Ajoutez une phase de référence avant et une de récupération après : en tout, généralement 10 à 20 minutes.

Faut-il de l'autoscaling pour faire un spike test ?

Non. Sans autoscaling, le test montre la marge de la capacité fixe. Avec autoscaling, il montre aussi si la capacité supplémentaire arrive avant que les utilisateurs soient touchés.

Peut-on faire un spike test en production ?

Mieux vaut un environnement de préproduction dimensionné comme la production. Sinon, convenez d'une plage horaire, commencez petit et faites surveiller le back-end.