16. Best Practices ¶
16.1 Verwenden Sie immer die neueste Version von JMeter ¶
Die Leistung von JMeter wird ständig verbessert, daher wird Benutzern dringend empfohlen, die aktuellste Version zu verwenden. Stellen Sie sicher, dass Sie immer die Änderungsliste
lesen , um über neue Verbesserungen und Komponenten informiert zu sein. Sie sollten unbedingt vermeiden, Versionen zu verwenden, die älter als 3 Versionen vor der letzten sind.
16.2 Verwenden Sie die richtige Anzahl von Threads ¶
Sowohl Ihre Hardwarefähigkeiten als auch das Design des Testplans wirken sich auf die Anzahl der Threads aus, die Sie effektiv mit JMeter ausführen können. Die Anzahl hängt auch davon ab, wie schnell Ihr Server ist (ein schnellerer Server führt dazu, dass JMeter härter arbeitet, da er schneller eine Antwort zurückgibt). Wenn Sie die Anzahl der Threads nicht richtig dimensionieren, werden Sie wie bei jedem Lasttest-Tool mit dem Problem der „koordinierten Auslassung“ konfrontiert, das zu falschen oder ungenauen Ergebnissen führen kann. Wenn Sie umfangreiche Lasttests benötigen, sollten Sie erwägen, mehrere CLI-JMeter-Instanzen auf mehreren Computern im verteilten Modus (oder nicht) auszuführen. Bei Verwendung des verteilten Modus wird die Ergebnisdatei auf dem Controller-Knoten kombiniert, wenn mehrere autonome Instanzen verwendet werden, können die Beispielergebnisdateien für die nachfolgende Analyse kombiniert werden. Um zu testen, wie JMeter auf einer bestimmten Plattform funktioniert, der JavaTest-Sampler kann verwendet werden. Es erfordert keinen Netzwerkzugriff und kann daher eine Vorstellung vom maximal erreichbaren Durchsatz geben.
JMeter hat eine Option zum Verzögern der Thread-Erstellung, bis der Thread mit dem Sampling beginnt, dh nach einer Verzögerung der Thread-Gruppe und der Hochlaufzeit für den Thread selbst. Dies ermöglicht eine sehr große Gesamtzahl von Threads, vorausgesetzt, dass nicht zu viele gleichzeitig aktiv sind.
16.3 Wohin mit dem Cookie-Manager ? ¶
Weitere Informationen finden Sie unter Erstellen eines Webtests .
16.4 Speicherort des Autorisierungsmanagers ¶
Weitere Informationen finden Sie unter Erstellen eines erweiterten Webtests .
16.5 Verwenden des HTTP(S)-Testskript-Rekorders ¶
Einzelheiten zum Einrichten des Rekorders finden Sie unter HTTP(S) Test Script Recorder . Das Wichtigste ist, alle Anfragen herauszufiltern, an denen Sie nicht interessiert sind. Beispielsweise macht es keinen Sinn, Bildanfragen aufzuzeichnen (JMeter kann angewiesen werden, alle Bilder auf einer Seite herunterzuladen - siehe HTTP-Anfrage ). Diese werden Ihren Testplan nur unübersichtlich machen. Höchstwahrscheinlich gibt es eine Erweiterung, die alle Ihre Dateien gemeinsam haben, wie z. B. .jsp , .asp , .php , .html oder ähnliches. Diese sollten Sie „ einschließen “, indem Sie „ .*\.jsp “ als „Include Pattern“ eingeben.
Alternativ können Sie Bilder ausschließen, indem Sie „ .*\.gif “ als „Exclude Pattern“ eingeben. Abhängig von Ihrer Anwendung kann dies ein besserer Weg sein oder auch nicht. Möglicherweise müssen Sie auch Stylesheets, Javascript-Dateien und andere enthaltene Dateien ausschließen. Testen Sie Ihre Einstellungen, um sicherzustellen, dass Sie aufnehmen, was Sie wollen, und löschen Sie sie dann und beginnen Sie neu.
Der HTTP(S)-Testskriptrekorder erwartet, ein ThreadGroup-Element mit einem darunter liegenden Aufzeichnungscontroller zu finden, an dem HTTP-Anforderungen aufgezeichnet werden. Dadurch werden alle Ihre Samples bequem unter einem Controller zusammengefasst, dem ein Name gegeben werden kann, der den Testfall beschreibt.
Gehen Sie nun die Schritte eines Testfalls durch. Wenn Sie keine vordefinierten Testfälle haben, verwenden Sie JMeter, um Ihre Aktionen aufzuzeichnen, um Ihre Testfälle zu definieren. Wenn Sie eine bestimmte Reihe von Schritten abgeschlossen haben, speichern Sie den gesamten Testfall in einer entsprechend benannten Datei. Wischen Sie dann sauber und starten Sie einen neuen Testfall. Auf diese Weise können Sie schnell eine große Anzahl von Testfall-"Grobentwürfen" erfassen.
Eine der nützlichsten Funktionen des HTTP(S) Test Script Recorders besteht darin, dass Sie bestimmte gemeinsame Elemente aus den aufgezeichneten Beispielen abstrahieren können. Indem Sie einige benutzerdefinierte Variablen auf Testplanebene oder in benutzerdefinierten Variablenelementen definieren , können Sie JMeter automatisch Werte in Ihren aufgezeichneten Proben ersetzen lassen. Wenn Sie beispielsweise eine App auf dem Server „ xxx.example.com “ testen, können Sie eine Variable namens „ server “ mit dem Wert „ xxx.example.com “ definieren, und überall dort, wo dieser Wert in Ihrer Aufzeichnung zu finden ist Proben werden durch " ${server} " ersetzt.
Wenn JMeter keine Samples aufzeichnet, überprüfen Sie, ob der Browser wirklich den Proxy verwendet. Wenn der Browser ordnungsgemäß funktioniert, auch wenn JMeter nicht ausgeführt wird, kann der Browser den Proxy nicht verwenden. Einige Browser ignorieren Proxy-Einstellungen für localhost oder 127.0.0.1 ; Versuchen Sie stattdessen, den lokalen Hostnamen oder die IP zu verwenden.
Der Fehler „ unknown_ca “ bedeutet wahrscheinlich, dass Sie versuchen, HTTPS aufzuzeichnen, und der Browser das Zertifikat des JMeter-Proxy-Servers nicht akzeptiert hat.
16.6 Benutzervariablen ¶
Einige Testpläne müssen unterschiedliche Werte für unterschiedliche Benutzer/Threads verwenden. Beispielsweise möchten Sie möglicherweise eine Sequenz testen, die eine eindeutige Anmeldung für jeden Benutzer erfordert. Dies ist mit den von JMeter bereitgestellten Einrichtungen einfach zu erreichen.
Zum Beispiel:
- Erstellen Sie eine Textdatei mit den Benutzernamen und Passwörtern, getrennt durch Kommas. Legen Sie dies im selben Verzeichnis wie Ihren Testplan ab.
- Fügen Sie dem Testplan ein CSV-DataSet-Konfigurationselement hinzu. Benennen Sie die Variablen USER und PASS .
- Ersetzen Sie auf den entsprechenden Samplern den Anmeldenamen durch ${USER} und das Passwort durch ${PASS}
Das CSV-Datensatzelement liest für jeden Thread eine neue Zeile.
16.7 Reduzierung des Ressourcenbedarfs ¶
Einige Vorschläge zur Reduzierung des Ressourcenverbrauchs.
- Verwenden Sie den CLI-Modus: jmeter -n -t test.jmx -l test.jtl
- Verwenden Sie so wenig Listener wie möglich; Wenn Sie wie oben das Flag -l verwenden, können sie alle gelöscht oder deaktiviert werden.
- Verwenden Sie während des Auslastungstests keine Listener „View Results Tree“ oder „View Results in Table“, sondern nur während der Skriptphase, um Ihre Skripts zu debuggen.
- Anstatt viele ähnliche Sampler zu verwenden, verwenden Sie denselben Sampler in einer Schleife und verwenden Sie Variablen (CSV-Datensatz), um das Sample zu variieren. [Der Include Controller hilft hier nicht weiter, da er alle Testelemente in der Datei zum Testplan hinzufügt.]
- Verwenden Sie nicht den Funktionsmodus
- Verwenden Sie die CSV-Ausgabe anstelle von XML
- Speichern Sie nur die Daten, die Sie benötigen
- Verwenden Sie so wenig Behauptungen wie möglich
- Verwenden Sie die leistungsstärkste Skriptsprache (siehe Abschnitt JSR223)
Wenn Ihr Test große Datenmengen benötigt – insbesondere wenn er randomisiert werden muss – erstellen Sie die Testdaten in einer Datei, die mit CSV Dataset gelesen werden kann. Dies vermeidet die Verschwendung von Ressourcen zur Laufzeit.
16.8 BeanShell-Server ¶
Der BeanShell-Interpreter hat eine sehr nützliche Funktion – er kann als Server fungieren, auf den über Telnet oder http zugegriffen werden kann.
Wenn Sie den Server verwenden möchten, definieren Sie Folgendes in jmeter.properties :
beanshell.server.port=9000 beanshell.server.file=../extras/startup.bsh
Im obigen Beispiel wird der Server gestartet und überwacht die Ports 9000 und 9001 . Port 9000 wird für den HTTP-Zugriff verwendet. Port 9001 wird für den Telnet-Zugriff verwendet. Die Datei startup.bsh wird vom Server verarbeitet und kann verwendet werden, um verschiedene Funktionen zu definieren und Variablen einzurichten. Die Startdatei definiert Methoden zum Festlegen und Drucken von JMeter- und Systemeigenschaften. Folgendes sollten Sie in der JMeter-Konsole sehen:
Startskript läuft Startskript abgeschlossen Httpd gestartet auf Port: 9000 Sitzung gestartet auf Port: 9001
Es gibt ein Beispielskript ( extras/remote.bsh ), mit dem Sie den Server testen können. [Schauen Sie es sich an, um zu sehen, wie es funktioniert.]
Wenn Sie es im JMeter- Bin -Verzeichnis starten (Pfade nach Bedarf anpassen, wenn Sie es von woanders ausführen), sollte die Ausgabe so aussehen:
$ java -jar ../lib/bshclient.jar localhost 9000 ../extras/remote.bsh Verbindung zum BSH-Server auf localhost:9000 Antworten vom Server lesen … BeanShell 2.0b5 - von Pat Niemeyer (pat@pat.net) bsh % remote.bsh wird gestartet user.home = C:\Dokumente und Einstellungen\Benutzer user.dir = D:\eclipseworkspaces\main\JMeter_trunk\bin Eigenschaft 'BEISPIEL' auf '0' setzen. Eigenschaft 'BEISPIEL' auf '1' setzen. Eigenschaft 'BEISPIEL' auf '2' setzen. Eigenschaft 'BEISPIEL' auf '3' setzen. Eigenschaft 'BEISPIEL' auf '4' setzen. Eigenschaft 'BEISPIEL' auf '5' setzen. Eigenschaft 'BEISPIEL' auf '6' setzen. Eigenschaft 'BEISPIEL' auf '7' setzen. Eigenschaft 'BEISPIEL' auf '8' setzen. Eigenschaft 'BEISPIEL' auf '9' setzen. BEISPIEL = 9 remote.bsh beendet bsh % … vom Server getrennt.
Nehmen wir als praktisches Beispiel an, Sie haben einen lang andauernden JMeter-Test, der im CLI-Modus ausgeführt wird, und Sie möchten den Durchsatz zu verschiedenen Zeitpunkten während des Tests variieren. Der Testplan enthält einen Constant Throughput Timer, der in Form einer Eigenschaft definiert ist, zB ${__P(throughput)} . Die folgenden BeanShell-Befehle könnten verwendet werden, um den Test zu ändern:
printprop("Durchsatz");
curr = Integer.decode (args [0]); // Startwert
inc = Integer.decode (args [1]); // Zuwachs
end = Integer.decode (args[2]); // Endgültiger Wert
secs = Integer.decode (args [3]); // Zwischen Änderungen warten
while(aktuell <= Ende) {
setprop("Durchsatz",curr.toString()); // Muss hier ein String sein
Thread.sleep (Sek.*1000);
akt. += inc;
}
printprop("Durchsatz");
Das Skript kann in einer Datei ( zB throughput.bsh ) gespeichert und mit bshclient.jar an den Server gesendet werden . Zum Beispiel:
java -jar ../lib/bshclient.jar localhost 9000 throughput.bsh 70 5 100 60
16.9 BeanShell-Skripting ¶
16.9.1 Übersicht ¶
Jedes BeanShell-Testelement hat seine eigene Kopie des Interpreters (für jeden Thread). Wird das Testelement wiederholt aufgerufen, zB innerhalb einer Schleife, dann bleibt der Interpreter zwischen den Aufrufen erhalten, es sei denn, die Option „ bsh.Interpreter vor jedem Aufruf zurücksetzen “ ist ausgewählt.
Einige lang andauernde Tests können dazu führen, dass der Interpreter viel Speicher verwendet; Wenn dies der Fall ist, versuchen Sie es mit der Reset-Option.
Sie können BeanShell-Skripte außerhalb von JMeter testen, indem Sie den Befehlszeileninterpreter verwenden:
$ java -cp bsh-xxx.jar[;weitere JAR-Dateien nach Bedarf] bsh.Interpreter file.bsh [Parameter]oder
$ java -cp bsh-xxx.jar bsh.Interpreter
bsh% source("file.bsh");
bsh% Ausfahrt(); // oder EOF-Taste verwenden (z. B. ^Z oder ^D)
16.9.2 Gemeinsame Nutzung von Variablen ¶
Variablen können in Startskripten (Initialisierungsskripten) definiert werden. Diese werden über Aufrufe des Testelements hinweg beibehalten, es sei denn, die Reset-Option wird verwendet.
Skripte können auch auf JMeter-Variablen zugreifen, indem sie die Methoden get() und put() der Variable " vars " verwenden, zum Beispiel:
vars.get("HOST");
vars.put("MSG","Erfolgreich");
Die get()- und put()- Methoden unterstützen nur Variablen mit String-Werten, aber es gibt auch getObject()- und putObject()- Methoden, die für beliebige Objekte verwendet werden können. JMeter-Variablen sind lokal für einen Thread, können aber von allen Testelementen (nicht nur Beanshell) verwendet werden.
Wenn Sie Variablen zwischen Threads teilen müssen, können JMeter-Eigenschaften verwendet werden:
import org.apache.jmeter.util.JMeterUtils;
Zeichenfolgenwert = JMeterUtils.getPropDefault("name","");
JMeterUtils.setProperty("name", "value");
Die .bshrc- Beispieldateien enthalten Beispieldefinitionen der Methoden getprop() und setprop() .
Eine andere mögliche Methode zur gemeinsamen Nutzung von Variablen ist die Verwendung des gemeinsam genutzten Namensraums „ bsh.shared “. Zum Beispiel:
if (bsh.shared.myObj == void){
// noch nicht definiert, also erstellen:
myObj = new AnyObject();
}
bsh.shared.myObj.process();
Anstatt das Objekt im Testelement zu erstellen, kann es in der Startup-Datei erstellt werden, die durch die JMeter-Eigenschaft „ beanshell.init.file “ definiert ist. Diese wird nur einmal verarbeitet.
16.10 Skriptfunktionen in Groovy oder Jexl3 etc. entwickeln ¶
Es ist ziemlich schwierig, Skripte als Funktionen zu schreiben und zu testen. JMeter verfügt jedoch über die JSR223-Sampler, die stattdessen mit jeder unterstützten Sprache verwendet werden können. Wir empfehlen die Verwendung von Apache Groovy oder einer anderen Sprache, die die Compilable- Schnittstelle von JSR223 unterstützt.
Erstellen Sie einen einfachen Testplan, der den JSR223-Sampler und den Strukturansicht-Listener enthält. Codieren Sie das Skript im Sampler-Skriptbereich und testen Sie es, indem Sie den Test ausführen. Wenn Fehler auftreten, werden diese in der Baumansicht und in der Datei jmeter.log angezeigt . Auch das Ergebnis der Ausführung des Skripts wird als Antwort angezeigt.
Sobald das Skript ordnungsgemäß funktioniert, kann es als Variable im Testplan gespeichert werden. Die Skriptvariable kann dann verwendet werden, um den Funktionsaufruf zu erstellen. Angenommen, ein Groovy-Skript ist in der Variablen RANDOM_NAME gespeichert . Der Funktionsaufruf kann dann als ${__groovy(${RANDOM_NAME})} kodiert werden . Es müssen keine Kommas im Skript maskiert werden, da der Funktionsaufruf analysiert wird, bevor der Wert der Variablen interpoliert wird.
16.11 Tests parametrieren ¶
Oft ist es hilfreich, denselben Test mit anderen Einstellungen wiederholen zu können. Beispielsweise das Ändern der Anzahl von Threads oder Schleifen oder das Ändern eines Hostnamens.
Eine Möglichkeit besteht darin, eine Reihe von Variablen im Testplan zu definieren und diese Variablen dann in den Testelementen zu verwenden. Beispielsweise könnte man die Variable LOOPS=10 definieren und diese in der Thread-Gruppe als ${LOOPS} bezeichnen . Um den Test mit 20 Schleifen auszuführen, ändern Sie einfach den Wert der LOOPS- Variablen im Testplan.
Das wird schnell mühsam, wenn man viele Tests im CLI-Modus durchführen möchte. Eine Lösung hierfür besteht darin, die Testplanvariable in Bezug auf eine Eigenschaft zu definieren, z. B. LOOPS=${__P(loops,10)} . Dies verwendet den Wert der Eigenschaft " loops " und ist standardmäßig 10 , wenn die Eigenschaft nicht gefunden wird. Die Eigenschaft " loops " kann dann auf der JMeter-Befehlszeile definiert werden:
jmeter … -Jloops=12 …Wenn viele Eigenschaften zusammen geändert werden müssen, besteht eine Möglichkeit, dies zu erreichen, darin, eine Reihe von Eigenschaftendateien zu verwenden. Die entsprechende Eigenschaftsdatei kann mit der Befehlszeilenoption -q an JMeter übergeben werden .
16.12 JSR223-Elemente ¶
Für intensive Lasttests ist die empfohlene Skriptsprache eine, deren ScriptingEngine die Compilable -Schnittstelle implementiert. Die Groovy-Skript-Engine implementiert Compilable . Zum Veröffentlichungsdatum von JMeter 3.1 tun dies jedoch weder Beanshell noch Javascript, daher wird empfohlen, sie für intensive Lasttests zu vermeiden.
vars.get("varName")
Sie können sie auch als Parameter an das Skript übergeben und auf diese Weise verwenden.
16.13 Gemeinsame Nutzung von Variablen zwischen Threads und Thread-Gruppen ¶
Variablen sind für einen Thread lokal; eine in einem Thread gesetzte Variable kann in einem anderen nicht gelesen werden. Dies ist beabsichtigt. Für Variablen, die vor Beginn eines Tests bestimmt werden können, siehe Parametrieren von Tests (oben). Ist der Wert bis zum Testbeginn nicht bekannt, gibt es verschiedene Möglichkeiten:
- Speichern Sie die Variable als Eigenschaft – Eigenschaften gelten global für die JMeter-Instanz
- Variablen in eine Datei schreiben und erneut lesen.
- Verwenden Sie den Namensraum bsh.shared - siehe oben
- Schreiben Sie Ihre eigenen Java-Klassen
16.14 Eigenschaften verwalten ¶
Wenn Sie jmeter-Eigenschaften ändern müssen, stellen Sie sicher, dass Sie die Datei
jmeter.properties nicht ändern, sondern die Eigenschaft aus jmeter.properties kopieren und ihren Wert in der Datei user.properties ändern .
Dies erleichtert Ihnen die Migration zur nächsten Version von JMeter.
Beachten Sie, dass in der Dokumentation jmeter.properties häufig erwähnt wird, dies jedoch als "Kopieren Sie die Eigenschaft, die Sie ändern möchten, von jmeter.properties nach user.properties und tun Sie dies in der letzteren Datei".
16.15 Veraltete Elemente ¶
Es wird empfohlen, veraltete Elemente (in der Änderungsliste und in der Komponentenreferenz als solche gekennzeichnet ) nicht zu verwenden und auf neue empfohlene Elemente zu migrieren, falls verfügbar, oder auf eine neue Möglichkeit, dasselbe zu tun.
Veraltete Elemente werden in Version N aus dem Menü entfernt, können aber für die Migration aktiviert werden, indem die Eigenschaft not_in_menu in der Datei user.properties geändert und der vollständige Klassenname des Elements von dort entfernt wird.