Typen von Lasttests

Die folgenden Testtypen basieren auf den grundlegenden Fragen, die weiter oben im Leitfaden aufgeführt wurden.

Wie viel Last kann meine Anwendung aushalten?

Wenn Sie einen Test einrichten, um zu ermitteln, welcher Last Ihre Anwendung standhalten kann, entscheiden Sie zunächst, ob Sie die Werte in Anfragen pro Sekunde (req/s), in der Antwortzeit (Sekunden) oder in der Anzahl gleichzeitiger Benutzer messen möchten. Definieren Sie für beide Fälle, welcher Teil der Anwendung getestet wird.

• Das Surfen auf der Website ist eine Belastung, die durch den Besuch einer Reihe von Seiten oder Endpunkten oder durch das Abrufen von Daten von einem einzigen Endpunkt aus erreicht wird, wobei für jede Anfrage unterschiedliche Parameter verwendet werden. Sie können dies häufig erreichen, indem Sie die grundlegenden Tools verwenden, die im Abschnitt Zu verwendende Tools beschrieben sind. Da ein Cache häufig eine wichtige Komponente einer Anwendung ist, sollten Sie entscheiden, ob Sie eine Caching-Ebene in den Test einbeziehen möchten.

• Für das Testen von Transaktionsworkflows, z. B. bei einem Checkout, bei dem Anfragen voneinander abhängen und Daten zwischen Anfragen übertragen werden, sind komplexere Tools erforderlich. Da die Anzahl der Anfragen im Kontext einer mehrstufigen Transaktion nur begrenzt relevant ist, ist es zudem genauer, die gesamte Transaktion zu zählen, die vom Tool als separater Datenpunkt ausgegeben werden muss. Die Tools Apache JMeter und k6 können so konfiguriert werden, dass sie diese Datenpunkte bereitstellen.

Definieren Sie den akzeptablen Schwellenwert für die Leistung und Fehlerrate Ihres Zielsystems. Bei einigen Systemen sind Ihnen die Antwortzeiten möglicherweise egal, solange das Ereignis erfolgreich verarbeitet wurde. Definieren Sie für viele Anwendungen, z. B. solche mit Benutzerinteraktion, Grenzwerte dafür, was für den Endbenutzer akzeptabel ist.

Oft ist es hilfreich, die Tests schrittweise durchzuführen. Die Belastung wird mit jedem Schritt erhöht, bis Sie den definierten Schwellenwert erreichen. Bei wiederholten Tests können Sie aus früheren Tests lernen und Ihre Schrittweite verbessern, sodass Sie in einem Test weniger Schritte ausführen und dennoch valide Ergebnisse erzielen.

Kann meine Anwendung X Last bewältigen?

Ähnlich wie im vorherigen Test kann die Last in diesem Test je nach Art der Anwendung, die Sie testen, als Req/s oder als gleichzeitige Benutzer definiert werden. Dieser Test ist eine vereinfachte Version des vorherigen Tests. Hier muss eine bestimmte Arbeitslast eingereicht werden, und das System sollte in der Lage sein, damit umzugehen. Es ist wichtig, ein Testtool zu wählen, das die Angabe des von Ihnen benötigten Ladevolumens unterstützt.

Die Zeit für die Ausführung des Tests kann ebenfalls relevant sein. Einige Auswirkungen können nur beobachtet werden, wenn ein Test über einen längeren Zeitraum ausgeführt wird. Gegendruck kann beispielsweise zu einer Überlastung der Warteschlangen führen. Wenn Sie ein Produktionssystem replizieren und daraus stichhaltige Schlüsse ziehen möchten, kann sich die für die Ausführung des Tests benötigte Zeit auf die Größe des Testsystems auswirken.

Wird meine Anwendung automatisch hoch- und herunterskaliert?

Elastizität ist ein wichtiges Verkaufsargument der Cloud und eine wichtige Quelle für Kostensenkungen. Es sollte Teil Ihres Weges in die Cloud sein, zu testen, ob Ihre Anwendung richtig skaliert wird, sodass Sie gut von der Elastizität profitieren können.

Wichtige Metriken, die für die Hoch- und Herunterskalierung verwendet werden, müssen identifiziert werden. In der Regel handelt es sich dabei um die CPU-Last der Zielsysteme. Ein Endpunkt, der CPU-Last erzeugt, kann als Ziel verwendet werden.

Da für diesen Test keine Repräsentabilität erforderlich ist, können Sie davon profitieren, wenn Sie auf einen Endpunkt abzielen, der frei von Nebenwirkungen ist. Sie möchten auch keinen Datenfluss initiieren, der Daten speichert, die sich ansammeln könnten, oder der nachfolgende Prozesse initiiert und entweder unnötige Kosten verursacht oder die Last blockiert.

Führen Sie den Test in einem schrittweisen Prozess durch, wobei Sie die Last schrittweise erhöhen. Die Intervalle sollten lang genug sein, damit die Metriken bei jedem Schritt die Skalierung einleiten können. Wenn Sie beispielsweise in einer Regel festlegen, dass die CPU-Last über einen Zeitraum von 5 Minuten höher als 70 Prozent sein soll, sollten Ihre Schritte länger als 5 Minuten sein, um Zeit für die Initiierung und Ausführung des Skalierungsereignisses zu haben. Sie möchten auch sehen, ob die Skalierung funktioniert hat und die von Ihnen verursachte Lastsituation behoben wurde.

Erwägen Sie, Ihren Skalierungstest mit mehr als einem Server zu beginnen. In einer kleinen Umgebung kann die Skalierung langsam sein und mehrere Zyklen erfordern, um die Last zu bewältigen. Und ein EC2-Auto-Scaling-Cluster kann seine Größe nur verdoppeln. Das heißt, wenn Sie mit einem Server beginnen und den Lasttest starten, kann das maximale erste Skalierungsereignis nur aus zwei Servern bestehen. Wenn für die erzeugte Last drei Server erforderlich wären, würden Sie zwei Skalierungsereignisse benötigen, was 20 Minuten oder länger dauern könnte.

Überwachen Sie den gewünschten Auslöser für das Hochskalierungs-Ereignis und ob die Skalierung für die tatsächliche Last angemessen war.

Wenn Sie ein Herunterskalierungs-Ereignis implementiert haben, können Sie dieses auch schrittweise testen. Überwachen Sie, ob das Herunterskalieren für die bestehende Last anwendbar und angemessen ist, und stellen Sie sicher, dass es nicht zu einem sofortigen erneuten Hochskalieren führt.

Verschlechtert sich das Verhalten meiner Anwendung mit der Zeit bei einer konstant hohen Last?

Einige Auswirkungen können nur beobachtet werden, wenn die Belastung über einen längeren Zeitraum erfolgt. Einer der wichtigsten Effekt ist der Gegendruck. Das bedeutet, dass sich die Leistung der Client-Systeme verschlechtert, wenn ein System zu langsam ist, um die Anzahl der Anfragen mit der Geschwindigkeit zu verarbeiten, mit der sie eingehen.

Dies ist leichter zu beobachten, wenn das langsame System das Lastziel ist. In einer komplexeren Konfiguration können Sie den Effekt nur beobachten, wenn sich die Auswirkungen des Lasttests ausbreiten. Eine Ablaufverfolgungslösung, die in der Lage ist, die Antwortzeiten zwischen den einzelnen Services in einem verteilten System zu visualisieren, zeigt nicht nur die Ergebnisse schneller an, sondern kann auch dazu beitragen, das System zu identifizieren, das als Engpass fungiert. Sie können das Engpasssystem identifizieren, indem Sie die Nachrichtenkorrelations-ID aus den Protokolldateien abrufen. Jede Anfrage behält auf allen Systemen, die den Auslastungstest durchlaufen, dieselbe ID bei.

Mithilfe einer Korrelations-ID können Sie den gesamten Verlauf einer einzelnen Nachricht durch all die verschiedenen Komponenten Ihrer Plattform verfolgen. Mit diesen Informationen können Sie die Verarbeitungszeit für jede einzelne Komponente berechnen, die Ihre Nachricht durchläuft (processing_time = departure_time - arrival_time) und die langsamste Komponente ermitteln. Zipkin, Jaeger, und AWS X-Ray sind herausragende Lösungen in diesem Bereich.

Um die zuverlässigsten Ergebnisse zu erzielen, wählen Sie ein Tool, das die Einstellung einer konstanten Anforderungsrate unterstützt. Das heißt, wenn das Zielsystem langsamer wird, muss die Parallelität des Test-Tools erhöht oder die Anzahl der Anforderungen konstant gehalten werden. Wenn das System langsamer reagiert, bindet es mehr Threads und senkt die Anforderungsrate Ihres Tools zur Lastgenerierung. Ein Tool mit einer konstanten Anforderungsrate muss die Parallelität erhöhen, wenn dies der Fall ist, und Sie werden Fehler schneller erkennen. Anstatt die Verschlechterung anhand der erreichten Anforderungen zu messen, messen Sie anhand der Latenz und sogar anhand fehlgeschlagener Anfragen.

Funktioniert meine Anwendung?

Normalerweise würden Sie keine hohe Auslastung erzeugen, sondern eine vernünftige Anzahl von Anfragen, die die Funktionalität überprüfen. Sie können dies auch in regelmäßigen Abständen für die Produktion tun, wenn die Kunden die getesteten Abläufe nicht besuchen, um eine weitere Überwachungsebene einzurichten.

Als Abkürzung können Szenarien, die bereits für Auslastungstests erstellt wurden, in der Produktion wiederverwendet werden, wenn eine geringere Last konfiguriert ist.