Was ist Spike Testing?

Was ist Spike Testing?

Spike Testing ist ein Performance-Test, bei dem die Last plötzlich sehr stark ansteigt und danach wieder fällt. Er zeigt, ob ein System den Ansturm übersteht und wie schnell es sich danach erholt. Anders als beim Lasttest mit Anstiegsphase gibt es kaum ein Plateau: Der Anstieg ist steil, und bewertet wird, was während und nach der Lastspitze passiert.

Eine ausführlichere Anleitung zum Entwerfen und Auswerten finden Sie im Blogartikel Spike Testing in der Performance-Testing-Praxis (auf Englisch).

Spike Testing, Lasttest und Stresstest im Vergleich

Ein Lasttest baut Nutzer schrittweise auf und hält sie auf dem Niveau, das Sie an einem starken Tag erwarten. Ein Stresstest geht darüber hinaus, um die Bruchstelle zu finden (siehe Load Testing vs. Stress Testing, englisch). Ein Spike-Test ist über seine Form definiert: normaler Verkehr, ein fast sofortiger Sprung auf ein sehr hohes Niveau, kurzes Halten, zurück auf Normalniveau. Die Fragen unterscheiden sich:

• Lasttest: Erreicht das System seine Ziele bei erwarteter Spitzenlast?
• Spike-Test: Was passiert, wenn sich der Traffic in Sekunden vervielfacht? Skaliert das System rechtzeitig, und kehrt es danach zum Normalzustand zurück?

Die maximale dauerhaft tragbare Last ist eine eigene Frage, die der Kapazitätstest beantwortet.

So läuft ein Spike-Test ab

1. Basislinie. Realistischen Verkehr einige Minuten laufen lassen, damit Caches, Verbindungspools und Autoscaler im Normalzustand sind.
2. Spike. Die Zahl der virtuellen Nutzer (oder die Anfragerate) innerhalb von Sekunden, nicht Minuten, auf das Ziel anheben.
3. Kurz halten. Die Spitze ein bis zwei Minuten halten. Viele echte Spitzen sind kurz.
4. Absenken und beobachten. Zurück auf die Basislinie und weiterlaufen lassen, bis erkennbar ist, ob Antwortzeiten und Fehler sich erholen.

Beispiel (Zahlen zur Veranschaulichung): Ein Onlineshop verschickt um 10:00 Uhr eine Push-Benachrichtigung. Normal sind 50 gleichzeitige Nutzer. Der Test springt innerhalb von 10 Sekunden auf 1.000 virtuelle Nutzer, hält 2 Minuten, fällt auf 50 zurück und läuft weitere 5 Minuten. Der k6-Leitfaden von Grafana nutzt eine ähnliche Form: 2 Minuten Anstieg auf 2.000 Nutzer, kein Plateau, dann 1 Minute Abfall auf null.

Serverlose Back-ends sind ein guter Grund für einen solchen Test. Für AWS Lambda nennt die Dokumentation standardmäßig 1.000 gleichzeitige Ausführungen pro Region und eine Skalierungsrate von 1.000 neuen Ausführungsumgebungen alle 10 Sekunden pro Funktion. Ein Ansturm kann den Scaler also überholen und gedrosselt werden. Details unter serverlose Funktion.

Was Sie messen sollten

• Fehlerrate während der Spitze. Einige Fehler sind zu erwarten. Entscheidend ist, welche (Timeouts, 429, 502, 503) und ob sie nach der Spitze verschwinden.
• Antwortzeit-Perzentile. Betrachten Sie p95 und p99, nicht den Mittelwert. Siehe Latenz.
• Erholungszeit. Sekunden vom Ende der Spitze, bis Antwortzeiten und Fehler wieder auf Basisniveau sind.
• Verhalten des Back-ends. Autoscaler-Ereignisse, CPU, Datenbankverbindungen und Warteschlangenlänge. Ohne Back-end-Monitoring sehen Sie das Symptom, aber nicht die Ursache.

Häufige Fehler

• Zu langsamer Anstieg. Ein Anstieg über 10 Minuten ist ein Lasttest. Entscheidend ist, dass die Skalierung keine Vorbereitungszeit hat.
• Abbruch mit dem Ende der Spitze. Hängende Fehler (erschöpfte Verbindungspools, abgestürzte Worker ohne Neustart) zeigen sich erst in der Erholungsphase.
• Eine Quelle, eine URL. Echter Ansturm kommt von vielen Orten und trifft mehrere Endpunkte. Variieren Sie Ablauf und Herkunft.
• Warme Caches. Ein bereits gefüllter Cache oder CDN verdeckt, was ein kalter Start des Ereignisses bewirken würde.
• Erwartung eines glatten Bestehens. Fehler unter einer Spitze sind üblich. Testen, anpassen, wiederholen, bis die Fehlerart akzeptabel ist.

Spike-Test mit LoadFocus

Mit LoadFocus Load Testing legen Sie für einen JMeter-Testplan Anzahl virtueller Nutzer, Dauer und Anstiegszeit fest oder nutzen k6-Szenarien mit Executors wie ramping-vus und starten sie gleichzeitig aus mehreren der 25 Cloud-Regionen. Bezahlte Tarife erlauben bis zu 20.000 gleichzeitige virtuelle Nutzer pro Test. Der Free-Tarif ist auf 10 virtuelle Nutzer und 60 Sekunden begrenzt: genug, um ein Skript und seine Form zu prüfen, aber nicht für einen echten Ansturm.

Häufige Fragen

Wie unterscheidet sich ein Spike-Test von einem Stresstest?

Ein Stresstest erhöht die Last weiter, bis das System bricht. Ein Spike-Test setzt einen einzelnen plötzlichen Sprung und prüft Überleben und Erholung. Stress fragt, wie viel; Spike fragt, wie schnell.

Wie lange sollte ein Spike-Test laufen?

Die Spitze selbst dauert oft ein bis wenige Minuten. Dazu kommen eine Basisphase davor und eine Erholungsphase danach, insgesamt meist 10 bis 20 Minuten.

Brauche ich Autoscaling für einen Spike-Test?

Nein. Ohne Autoscaling zeigt der Test, wie viel Reserve die feste Kapazität hat. Mit Autoscaling zeigt er zusätzlich, ob neue Kapazität rechtzeitig eintrifft.

Sollte ich einen Spike-Test in Produktion fahren?

Besser in einer Staging-Umgebung in Produktionsgröße. Wenn es Produktion sein muss: Zeitfenster abstimmen, klein beginnen und das Back-end beobachten lassen.