Wenn Sie eine E-Commerce-Site (oder eine andere Site) haben, ist es nicht ungewöhnlich, dass Sie an bestimmten Tagen, wie beispielsweise am Black Friday, mit einem höheren Verkehrsaufkommen rechnen. In solchen Momenten müssen wir unsere Lasttests auf die nächste Stufe heben und eine größere Anzahl gleichzeitiger Benutzer simulieren. Wenn wir unsere Lasttests lokal mit Apache JMeter ™ ausführen, gibt es bestimmte Einschränkungen für die Anzahl der Benutzer, die Sie ausführen können, selbst wenn Ihr Computer über genügend CPU und Arbeitsspeicher verfügt.
Wie können wir mit JMeter ein Szenario mit mehr als 800 gleichzeitigen Benutzern erstellen? Eine der Antworten ist das Ausführen von JMeter im verteilten Modus. Für diejenigen unter Ihnen, die noch nie davon gehört haben, hier eine kurze Erklärung.
Wenn wir über die Verteilung von JMeter sprechen, beziehen wir uns auf eine Master-Slave-Architektur, bei der JMeter Java RMI verwendet, um mit Objekten in einem verteilten Netzwerk zu interagieren. Sie können dies im Bild unten sehen.
Verteiltes Testen ermöglicht ein lokales JMeter (Master), das die Testausführung übernimmt, zusammen mit mehreren Remote-JMeter-Instanzen (Slaves), die die Anforderung an unseren Zielserver senden.
Bevor Sie JMeter jedoch verteilt ausführen können, müssen Sie einige einfache Schritte ausführen.
Zuerst müssen wir mehrere Computer haben.
Dann müssen wir den JMeter-Server auf jedem Slave-System laufen lassen, das wir haben. Dazu müssen wir den jmeter-Server ausführen.bat (jmeter-Server für Unix-Benutzer), der sich im jmeter / bin befindet. Sobald wir es ausführen, sollten wir so etwas sehen:
Suchen Sie dann über denselben Pfad, jedoch im Master-System, das Jmeter.eigenschaften fil. Bearbeiten Sie diese Datei und fügen Sie die IPs aller Slave-Systeme hinzu, die an der Eigenschaft remote_hosts beteiligt sein sollen. Stellen Sie sicher, dass sich das Master- und das Slave-System im selben Subnetz befinden.
Es ist sehr wichtig, sich daran zu erinnern, dass alle Werte durch Kommas getrennt werden müssen (in diesem Beispiel verwenden wir nur ein Slave-System, um es einfach zu halten).
Sobald alle diese Schritte abgeschlossen sind, können wir JMeter starten und die erforderlichen Tests ausführen. In diesem Fall werden wir JMeter im GUI-Modus ausführen, damit wir eine bessere Vorstellung davon haben, wie es funktioniert. Der Nicht-GUI-Modus wird jedoch zu Testzwecken dringend empfohlen.
Die Anzahl der Benutzer, Ramp Up und Iterationen sollte wie gewohnt in der Thread-Gruppe Master Systems konfiguriert werden. Beim Ausführen des Tests werden diese Bedingungen auf jedem Slave-System repliziert.
Nachdem wir JMeter gestartet und unseren Test geladen haben, haben wir zwei Möglichkeiten. Eine, die über das Master-System konfiguriert wird, erfolgt über Run->Remote Start und wählt dann das Slave-System aus, auf dem wir ausführen möchten. Der zweite, ebenfalls über das Master-System konfigurierte, ist Run->Remote Start All, um den Test auf allen verfügbaren Slave-Systemen zu starten.
( Da wir nur ein Slave-System eingestellt, gibt es keinen Unterschied zwischen den beiden Optionen in diesem Beispiel).
Hier haben wir ein einfaches Szenario, in dem wir einen Artikel auf einer E-Commerce-Website suchen und anzeigen können:
Wie Sie sehen, haben wir einen Listener für den View Results Tree hinzugefügt, damit wir überprüfen können, ob der Test korrekt ausgeführt wurde oder nicht. Wenn wir einen Test remote ausführen, können wir das Testergebnis lokal im View Results Tree Listener sehen, wie ich bereits erwähnt habe, aber in den Slave-Systemen können wir nur die Startzeit und die Endzeit des Tests beobachten.
Lokal:
Aus der Ferne:
Hinter den Kulissen führt jedes Slave-System die Lasttests mit den Bedingungen aus, die wir im Master-System festgelegt haben. Auf diese Weise erreichen wir eine höhere Anzahl gleichzeitiger Benutzer und damit eine höhere Auslastung unseres Zielservers.
Wenn wir die Last wirklich verteilen möchten, müssen wir dies manuell tun. Beispiel: Wenn wir 10.000 gleichzeitige Benutzer erreichen möchten und 10 Slave-Systeme haben, muss unser Testplan 1000 Benutzer haben, sodass wir insgesamt 10.000 haben.
Eine weitere interessante Sache, die wir tun können, ist, unserem Test Logik hinzuzufügen, indem wir einen If-Controller hinzufügen. Mit dem If-Controller können wir einen bestimmten Flow auswählen, den wir ausführen möchten, abhängig vom System, das den Test ausführt. Daher würden verschiedene Slave-Systeme verschiedene Teile des Tests ausführen.
Zum Beispiel, wenn wir einen Parameter hinzufügen, wenn der jmeter-Server auf den Slave-Systemen ausgeführt wird (./ jmeter-server -Jparam=1) Wir können eine Bedingung wie ${__JavaScript(${param}==1)} innerhalb des If-Controllers platzieren, damit wir je nach Slave-System bestimmte Anforderungen ausführen können.
Das war’s! Wir haben erfolgreich einen Test über ein verteiltes JMeter-System durchgeführt. Dies mag nicht sehr komplex aussehen, da wir uns für nur ein Slave-System entschieden haben. Wenn Sie jedoch 25.000 gleichzeitige Benutzer simulieren müssen, sind die Kosten für die Wartung all dieser Systeme enorm. Möglicherweise gibt es eine mögliche Problemumgehung für die Wartungsprobleme, nämlich das Mounten der gesamten Architektur, die wir über Docker-Container gesehen haben (Sie können hier ein Beispiel sehen).
Dies wird jedoch immer noch nicht gut genug sein, wenn wir regelmäßig Lasttests durchführen möchten. Wir haben die gesamte verteilte Architektur auf einem Computer installiert, sodass wir eine beträchtliche Menge an Ressourcen verbrauchen. Das Konzept, JMeter über Docker zu verteilen, ist sinnvoller, wenn wir die Möglichkeit haben, die Anzahl der Container bei Bedarf zu erhöhen, wie in einem Cloud-Computing-Dienst.
Eine weitere Schwierigkeit beim Ausführen von JMeter im verteilten Modus ist der Umgang mit CSV-Dateien, wenn Sie Daten in Ihren Tests parametrisiert haben. Dies liegt daran, dass wir getrennte Dateien haben müssen, und wenn wir sie aktualisieren müssen, müssen wir zu jedem Slave-System gehen und die Änderungen vornehmen.
Um all diese Einschränkungen und Unannehmlichkeiten zu beheben, können wir BlazeMeter verwenden, das uns eine einfache Möglichkeit bietet, unsere Lasttests durchzuführen. Alles, was wir tun müssen, ist, unsere JMX-Datei in BlazeMeter hochzuladen. Wir können auch eine konsolidierte CSV-Datei mit allen erforderlichen Daten hochladen, und BlazeMeter kümmert sich um die Aufteilung, abhängig von der Anzahl der von uns festgelegten Engines.
Auf BlazeMeter können wir die Anzahl der Benutzer oder die Kombination von Engines (Slave-Systemen) und Threads festlegen, die wir auf unsere Tests anwenden möchten. Wir können auch zusätzliche Werte wie mehrere Standorte konfigurieren.
Testergebnisse:
Das war’s! Nachdem Sie einige Lösungen für die Durchführung von Lasttests in großem Maßstab gesehen haben, empfehle ich Ihnen, Ihre eigenen Erfahrungen zu sammeln und zu entscheiden, welche Option Ihnen größere Vorteile bietet.
Erfahren Sie mehr über die Verwendung von JMeter in unserer kostenlosen JMeter Academy.
