1.0.4 Fangen wir an ¶

Der einfachste Weg, mit der Verwendung von JMeter zu beginnen, besteht darin, zuerst die neueste Produktionsversion herunterzuladen und zu installieren. Die Version enthält alle Dateien, die Sie zum Erstellen und Ausführen der meisten Arten von Tests benötigen, z. B. Web (HTTP/HTTPS), FTP, JDBC, LDAP, Java, JUnit und mehr.

Wenn Sie JDBC-Tests durchführen möchten, benötigen Sie natürlich den passenden JDBC-Treiber Ihres Herstellers. JMeter enthält keine JDBC-Treiber.

JMeter enthält das JMS-API-JAR, aber keine JMS-Client-Implementierung. Wenn Sie JMS-Tests ausführen möchten, müssen Sie die entsprechenden JAR-Dateien vom JMS-Anbieter herunterladen.

Starten Sie als Nächstes JMeter und gehen Sie durch den Abschnitt Erstellen eines Testplans des Benutzerhandbuchs, um sich mit den Grundlagen von JMeter vertraut zu machen (z. B. Hinzufügen und Entfernen von Elementen).

Gehen Sie abschließend den entsprechenden Abschnitt durch, um zu erfahren, wie Sie einen bestimmten Testplantyp erstellen. Wenn Sie beispielsweise daran interessiert sind, eine Webanwendung zu testen, lesen Sie den Abschnitt Erstellen eines Webtestplans . Die anderen spezifischen Testplanabschnitte sind:

• Erweiterter Webtestplan
• JDBC
• FTP
• JMS Punkt-zu-Punkt
• JMS-Thema
• LDAP
• LDAP-erweitert
• Webservices (SOAP)

Sobald Sie mit dem Erstellen und Ausführen von JMeter-Testplänen vertraut sind, können Sie sich die verschiedenen Konfigurationselemente (Timer, Listener, Behauptungen und andere) ansehen, die Ihnen mehr Kontrolle über Ihre Testpläne geben.

1.1.1 Java-Version ¶

Da JMeter nur standardmäßige Java-APIs verwendet, reichen Sie bitte keine Fehlerberichte ein, wenn Ihre JRE JMeter aufgrund von JRE-Implementierungsproblemen nicht ausführen kann.

1.1.2 Betriebssysteme ¶

JMeter ist zu 100 % eine Java-Anwendung und sollte auf jedem System mit einer kompatiblen Java-Implementierung korrekt ausgeführt werden.

Mit JMeter getestete Betriebssysteme können auf dieser Seite im JMeter-Wiki angezeigt werden.

Auch wenn Ihr Betriebssystem nicht auf der Wiki-Seite aufgeführt ist, sollte JMeter darauf laufen, vorausgesetzt, die JVM ist konform.

1.2.1 Java-Compiler ¶

Wenn Sie die JMeter-Quelle erstellen oder JMeter-Plugins entwickeln möchten, benötigen Sie ein vollständig kompatibles JDK 8 oder höher.

1.2.2 SAX-XML-Parser ¶

JMeter wird mit dem Xerces XML-Parser von Apache geliefert . Sie haben die Möglichkeit, JMeter anzuweisen, einen anderen XML-Parser zu verwenden. Fügen Sie dazu die Klassen für den Drittanbieter-Parser in den Klassenpfad von JMeter ein und aktualisieren Sie die Datei jmeter.properties mit dem vollständigen Klassennamen der Parser-Implementierung.

1.2.3 E-Mail-Support ¶

JMeter verfügt über umfangreiche E-Mail-Funktionen. Es kann E-Mails basierend auf Testergebnissen senden und verfügt über einen POP3(S)/IMAP(S)-Sampler. Es hat auch einen SMTP(S)-Sampler.

1.2.4 SSL-Verschlüsselung ¶

Um einen Webserver mit SSL-Verschlüsselung (HTTPS) zu testen, erfordert JMeter, dass eine SSL-Implementierung bereitgestellt wird, wie dies bei Sun Java 1.4 und höher der Fall ist. Wenn Ihre Java-Version keine SSL-Unterstützung enthält, ist es möglich, eine externe Implementierung hinzuzufügen. Fügen Sie die erforderlichen Verschlüsselungspakete in den Klassenpfad von JMeter ein . Aktualisieren Sie außerdem system.properties , um den SSL-Anbieter zu registrieren.

JMeter HTTP verwendet standardmäßig TLS auf Protokollebene. Dies kann durch Bearbeiten der JMeter-Eigenschaft https.default.protocol in jmeter.properties oder user.properties geändert werden .

Die JMeter-HTTP-Sampler sind so konfiguriert, dass sie alle Zertifikate akzeptieren, ob vertrauenswürdig oder nicht, unabhängig von Gültigkeitszeiträumen usw. Dies soll maximale Flexibilität beim Testen von Servern ermöglichen.

Wenn der Server ein Client-Zertifikat benötigt, kann dieses bereitgestellt werden.

Es gibt auch den SSL-Manager für eine bessere Kontrolle der Zertifikate.

Der SMTP-Sampler kann optional einen lokalen Truststore verwenden oder allen Zertifikaten vertrauen.

1.2.5 JDBC-Treiber ¶

Sie müssen den JDBC-Treiber Ihres Datenbankanbieters zum Klassenpfad hinzufügen, wenn Sie JDBC-Tests durchführen möchten. Stellen Sie sicher, dass es sich bei der Datei um eine JAR-Datei und nicht um eine ZIP-Datei handelt.

1.2.6 JMS-Client ¶

JMeter enthält jetzt die JMS-API von Apache Geronimo, sodass Sie nur die entsprechenden JMS-Client-Implementierungs-JARs vom JMS-Anbieter hinzufügen müssen. Einzelheiten entnehmen Sie bitte deren Dokumentation. Es kann auch einige Informationen im JMeter-Wiki geben .

1.2.7 Bibliotheken für ActiveMQ JMS ¶

Sie müssen die JAR -Datei activemq-all-XXXjar zu Ihrem Klassenpfad hinzufügen, zB indem Sie sie im lib/ -Verzeichnis speichern .

Einzelheiten finden Sie auf der ActiveMQ -Erstkonfigurationsseite .

1.4.1 Klassenpfad von JMeter ¶

JMeter findet automatisch Klassen aus Jars in den folgenden Verzeichnissen:

JMETER_HOME/lib

verwendet für Utility-Gläser

JMETER_HOME/lib/ext

Wird für JMeter-Komponenten und -Plugins verwendet

Wenn Sie neue JMeter-Komponenten entwickelt haben, sollten Sie diese jaren und das jar in das lib/ext - Verzeichnis von JMeter kopieren. JMeter findet automatisch JMeter-Komponenten in allen hier gefundenen JARs. Verwenden Sie lib/ext nicht für Utility-Jars oder Abhängigkeits-Jars, die von den Plug-ins verwendet werden; Es ist nur für JMeter-Komponenten und -Plugins vorgesehen.

Wenn Sie keine JMeter -Plug-in-Jars im Verzeichnis lib/ext ablegen möchten , definieren Sie die Eigenschaft search_paths in jmeter.properties .

Utility- und Abhängigkeits-Jars (Bibliotheken usw.) können im lib- Verzeichnis abgelegt werden.

Wenn Sie solche JAR-Dateien nicht in das lib - Verzeichnis stellen möchten, definieren Sie die Eigenschaft user.classpath oder plugin_dependency_paths in jmeter.properties . Nachfolgend finden Sie eine Erläuterung der Unterschiede.

Andere JAR-Dateien (wie JDBC, JMS-Implementierungen und alle anderen Unterstützungsbibliotheken, die vom JMeter-Code benötigt werden) sollten im Verzeichnis lib abgelegt werden – nicht im Verzeichnis lib/ext – oder zu user.classpath hinzugefügt werden .

Sie können auch Dienstprogramm-JAR-Dateien in $JAVA_HOME/jre/lib/ext installieren oder die Eigenschaft user.classpath in jmeter.properties festlegen

Beachten Sie, dass das Festlegen der Umgebungsvariablen CLASSPATH keine Auswirkung hat. Dies liegt daran, dass JMeter mit " java -jar " gestartet wird und der Java-Befehl stillschweigend die CLASSPATH- Variable und die -classpath / -cp- Optionen ignoriert, wenn -jar verwendet wird.

1.4.2 Testplan aus Vorlage erstellen ¶

Sie haben die Möglichkeit, einen neuen Testplan aus einer vorhandenen Vorlage zu erstellen.

Verwenden Sie dazu das Menü Datei  →  Vorlagen… oder das Symbol Vorlagen:

Ein Popup erscheint, Sie können dann eine Vorlage aus der Liste auswählen:

Einige Vorlagen erfordern möglicherweise Parametereingaben vom Benutzer. Für diese erscheint nach einem Klick auf die Schaltfläche Erstellen ein neues Fenster wie folgt:

Wenn Sie mit den Parametern fertig sind, klicken Sie auf die Schaltfläche Validieren und die Vorlage wird erstellt.

Eine Dokumentation für jede Vorlage erklärt, was zu tun ist, nachdem der Testplan aus der Vorlage erstellt wurde.

1.4.3 Verwendung von JMeter hinter einem Proxy ¶

Wenn Sie hinter einer Firewall/einem Proxyserver testen, müssen Sie JMeter möglicherweise den Hostnamen und die Portnummer der Firewall/des Proxyservers mitteilen. Führen Sie dazu die Datei jmeter[.bat] über eine Befehlszeile mit den folgenden Parametern aus:

-E

[Zu verwendendes Proxy-Schema – optional – für Nicht-http]

-H

[Hostname oder IP-Adresse des Proxy-Servers]

-P

[Proxyserver-Port]

-N

[Nicht-Proxy-Hosts] (zB *.apache.org|localhost )

-u

[Benutzername für Proxy-Authentifizierung - falls erforderlich]

-a

[Passwort für die Proxy-Authentifizierung - falls erforderlich]

jmeter -E https -H my.proxy.server -P 8000 -u Benutzername -a Passwort -N localhost

Sie können auch --proxyScheme , --proxyHost , --proxyPort , --username und --password als Parameternamen verwenden

Wenn das Proxy-Schema bereitgestellt wird, legt JMeter die folgenden Systemeigenschaften fest:

• http.proxyScheme

Wenn der Proxy-Host und -Port bereitgestellt werden, legt JMeter die folgenden Systemeigenschaften fest:

• http.proxyHost
• http.proxyPort
• https.proxyHost
• https.proxyPort

Der für einen Proxy verwendete Benutzer und das Kennwort können über die Systemeigenschaften http.proxyUser und http.proxyUser angegeben werden . Sie werden von den oben genannten Argumenten oder Werten überschrieben, die in den HTTP-Samplern festgelegt wurden.

Wenn eine Nicht-Proxy-Hostliste bereitgestellt wird, legt JMeter die folgenden Systemeigenschaften fest:

• http.nonProxyHosts
• https.nonProxyHosts

Wenn Sie also nicht sowohl HTTP- als auch HTTPS-Proxys festlegen möchten, können Sie die entsprechenden Eigenschaften in system.properties definieren, anstatt die Befehlszeilenparameter zu verwenden.

Proxy-Einstellungen können auch in einem Testplan definiert werden, indem entweder die Standardkonfiguration für HTTP-Anforderungen oder die Sampler-Elemente für HTTP -Anforderungen verwendet werden.

1.4.4 CLI-Modus (Befehlszeilenmodus wurde NON-GUI-Modus genannt) ¶

Für Lasttests müssen Sie JMeter in diesem Modus (ohne GUI) ausführen, um optimale Ergebnisse zu erzielen. Verwenden Sie dazu die folgenden Befehlsoptionen:

-n

Dies gibt an, dass JMeter im CLI-Modus ausgeführt werden soll

-t

[Name der JMX-Datei, die den Testplan enthält].

-l

[Name der JTL-Datei zum Protokollieren der Probenergebnisse].

-j

[Name der JMeter-Ausführungsprotokolldatei].

-r

Führen Sie den Test auf den Servern aus, die durch die JMeter-Eigenschaft " remote_hosts " angegeben sind.

-R

[Liste der Remote-Server] Führen Sie den Test auf den angegebenen Remote-Servern aus

-g

[Pfad zur CSV-Datei] Nur Berichts-Dashboard generieren

-e

Berichts-Dashboard nach Belastungstest generieren

-Ö

Ausgabeordner, in dem das Berichts-Dashboard nach dem Belastungstest generiert werden soll. Ordner darf nicht existieren oder leer sein

Mit dem Skript können Sie auch die optionalen Firewall-/Proxy-Serverinformationen angeben:

-H

[Hostname oder IP-Adresse des Proxy-Servers]

-P

[Proxyserver-Port]

jmeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000

Wenn die Eigenschaft jmeterengine.stopfail.system.exit auf true gesetzt ist (Standard ist false ), ruft JMeter System.exit(1) auf , wenn es nicht alle Threads stoppen kann. Normalerweise ist dies nicht erforderlich.

1.4.5 Servermodus ¶

Führen Sie für verteilte Tests JMeter im Servermodus auf dem/den Remote-Knoten aus und steuern Sie dann den/die Server über die GUI. Sie können auch den CLI-Modus verwenden, um Remote-Tests auszuführen. Um den/die Server zu starten, führen Sie jmeter-server[.bat] auf jedem Serverhost aus.

Mit dem Skript können Sie auch die optionalen Firewall-/Proxy-Serverinformationen angeben:

-H

[Hostname oder IP-Adresse des Proxy-Servers]

-P

[Proxyserver-Port]

jmeter-server -H mein.proxy.server -P 8000

Wenn Sie möchten, dass der Server beendet wird, nachdem ein einzelner Test ausgeführt wurde, definieren Sie die JMeter-Eigenschaft server.exitaftertest=true .

Verwenden Sie den folgenden Befehl, um den Test vom Client im CLI-Modus auszuführen:

jmeter -n -t testplan.jmx -r [-Gprop=val] [-Gglobal.properties] [-X]

-G

wird verwendet, um JMeter-Eigenschaften zu definieren, die in den Servern festgelegt werden sollen

-X

bedeutet, die Server am Ende des Tests zu verlassen

-Rserver1,server2

kann anstelle von -r verwendet werden , um eine Liste der zu startenden Server bereitzustellen. Überschreibt remote_hosts , definiert die Eigenschaft jedoch nicht.

Wenn die Eigenschaft jmeterengine.remote.system.exit auf true gesetzt ist (Standard ist false ), ruft JMeter System.exit(0) auf , nachdem RMI am Ende eines Tests gestoppt wurde. Normalerweise ist dies nicht erforderlich.

1.4.6 Überschreiben von Eigenschaften über die Befehlszeile ¶

Java-Systemeigenschaften und JMeter-Eigenschaften können direkt auf der Befehlszeile überschrieben werden (anstatt jmeter.properties zu ändern ). Verwenden Sie dazu die folgenden Optionen:

-D[Eigenschaftsname]=[Wert]

definiert einen Java-Systemeigenschaftswert.

-J[Eigenschaftsname]=[Wert]

definiert eine lokale JMeter-Eigenschaft.

-G[Eigenschaftsname]=[Wert]

definiert eine JMeter-Eigenschaft, die an alle Remote-Server gesendet werden soll.

-G[Eigenschaftsdatei]

definiert eine Datei mit JMeter-Eigenschaften, die an alle Remote-Server gesendet werden soll.

-L[Kategorie]=[Priorität]

setzt eine Protokollierungseinstellung außer Kraft und setzt eine bestimmte Kategorie auf die angegebene Prioritätsstufe.

Das Flag -L kann auch ohne den Kategorienamen verwendet werden, um die Root-Protokollierungsebene festzulegen.

Beispiele :

jmeter -Duser.dir=/home/mstover/jmeter_stuff \
    -Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG

jmeter-LDEBUG

1.4.7 Protokollierung und Fehlermeldungen ¶

Hier ist eine log4j2.xml -Beispieldatei , die zwei Protokoll-Appender und Protokollierer für jede Kategorie definiert.

<Konfigurationsstatus="WARN" packages="org.apache.jmeter.gui.logging">

  <Appender>

    <!-- Der Hauptprotokolldatei-Appender für jmeter.log in dem Verzeichnis, aus dem JMeter standardmäßig gestartet wurde. -->
    <Dateiname="jmeter-log" fileName="${sys:jmeter.logfile:-jmeter.log}" append="false">
      <MusterLayout>
        <Muster>%d %p %c{1.}: %m%n</Muster>
      </MusterLayout>
    </Datei>

    <!-- Log-Appender für GUI Log Viewer. Siehe unten. -->
    <GuiLogEvent-Name="gui-log-event">
      <MusterLayout>
        <Muster>%d %p %c{1.}: %m%n</Muster>
      </MusterLayout>
    </GuiLogEvent>

  </Appender>

  <Logger>

    <!-- Root-Logger -->
    <Stammebene="info">
      <AppenderRef ref="jmeter-log" />
      <AppenderRef ref="gui-log-event" />
    </Root>

    <!-- SNIP -->

    <!--
      # Apache HttpClient-Protokollierungsbeispiele
    -->
    <!-- # Header-Wire + Kontextprotokollierung aktivieren - Optimal für Debugging -->
    <!--
    <Loggername="org.apache.http" level="debug" />
    <Loggername="org.apache.http.wire" level="error" />
    -->

    <!-- SNIP -->

  </Logger>

</Konfiguration>

Wenn Sie also beispielsweise die Protokollebene für die Kategorie „ org.apache.http “ in die Debug-Ebene ändern möchten, können Sie einfach das folgende Protokollierungselement in der Datei „log4j2.xml “ hinzufügen (oder auskommentieren) , bevor Sie JMeter starten.

  <Logger>
    <!-- SNIP -->
    <Loggername="org.apache.http" level="debug" />
    <!-- SNIP -->
  </Logger>

Weitere Einzelheiten zur Konfiguration der Datei log4j2.xml finden Sie auf der Apache Log4j 2-Konfigurationsseite .

Die Protokollebene für bestimmte Kategorien oder Root-Logger kann auch direkt in der Befehlszeile überschrieben werden (anstatt log4j2.xml zu ändern ). Verwenden Sie dazu die folgenden Optionen:

-L[Kategorie]=[Priorität]

Überschreibt eine Protokollierungseinstellung und setzt eine bestimmte Kategorie auf die angegebene Prioritätsstufe. Seit 3.2 wird empfohlen, einen vollständigen Kategorienamen zu verwenden (z. B. org.apache.jmeter oder com.example.foo ), aber wenn der Kategoriename entweder mit jmeter oder jorphan beginnt , org.apache. wird intern der Eingabe des Kategorienamens vorangestellt, um aus Gründen der Abwärtskompatibilität einen vollständigen Kategorienamen (dh org.apache.jmeter oder org.apache.jorphan ) zu erstellen.

Beispiele :

jmeter -Ljmeter.engine=DEBUG

jmeter -Lorg.apache.jmeter.engine=DEBUG

jmeter -Lcom.example.foo=DEBUG

jmeter-LDEBUG

Unterschiede in der Protokollierung: Alte vs. neue Praktiken :

Da JMeter seit 3.2 SLF4J als Logging-API und Apache Log4j 2 als Logging-Framework verwendet, kann nicht jeder Log-Level, der vor 3.2 verwendet wurde, genau mit einem der neuen verfügbaren Log-Level übereinstimmen, die von SLF4J/Log4j2 bereitgestellt werden. Beachten Sie daher bitte die folgenden Unterschiede und neuen empfohlenen Vorgehensweisen, wenn Sie vorhandene Protokollierungskonfigurationen und Protokollierungscode migrieren müssen.

LoggingManager.getLoggerFor (String-Kategorie);
LoggingManager.getLoggerForClass();

LoggerFactory.getLogger (String-Kategorie);
LoggerFactory.getLogger (Foo.class);

Wenn JMeter während eines Tests einen Fehler erkennt, wird eine Meldung in die Protokolldatei geschrieben. Der Name der Protokolldatei wird in der Datei log4j2.xml definiert (oder mit der Option -j , siehe unten). Es ist standardmäßig jmeter.log und befindet sich in dem Verzeichnis, aus dem JMeter gestartet wurde.

Das Menü Options  →  Log Viewer zeigt die Protokolldatei in einem unteren Bereich des JMeter-Hauptfensters an.

Im GUI-Modus wird die Anzahl der in der Protokolldatei protokollierten Fehler/schwerwiegenden Meldungen oben rechts angezeigt.

Die Befehlszeilenoption -j jmeterlogfile ermöglicht die Verarbeitung nach dem Lesen der anfänglichen Eigenschaftendatei und vor der Verarbeitung weiterer Eigenschaften. Daher kann der Standardwert von jmeter.log überschrieben werden. Die jmeter-Skripte, die einen Testplannamen als Parameter verwenden (z. B. jmeter-n.cmd ), wurden aktualisiert, um die Protokolldatei mit dem Testplannamen zu definieren, z. B. für den Testplan Test27.jmx ist die Protokolldatei auf Test27 festgelegt. anmelden .

Unter Windows wird die Datei möglicherweise nur als jmeter angezeigt , es sei denn, Sie haben Windows so eingestellt, dass Dateierweiterungen angezeigt werden. [Was Sie sowieso tun sollten, damit Viren und andere Schädlinge, die sich als Textdateien ausgeben, leichter erkannt werden …]

Neben der Aufzeichnung von Fehlern zeichnet die Datei jmeter.log einige Informationen über den Testlauf auf. Zum Beispiel:

01.03.2017 12:19:20,314 INFO oajJMeter: Version 3.2.20170301
01.03.2017 12:19:45,314 INFO oajgaLoad: Datei wird geladen: c:\mytestfiles\BSH.jmx
01.03.2017 12:19:52,328 INFO oajeStandardJMeterEngine: Test läuft!
01.03.2017 12:19:52.384 INFO oajeStandardJMeterEngine: Starten von 1 Threads für Gruppe BSH. Rampe auf = 1.
01.03.2017 12:19:52.485 INFO oajeStandardJMeterEngine: Bei Fehler fortfahren
01.03.2017 12:19:52.589 INFO oajtJMeterThread: Thread BSH1-1 gestartet
01.03.2017 12:19:52.590 INFO oajtJMeterThread: Thread BSH1-1 ist fertig
01.03.2017 12:19:52,691 INFO oajeStandardJMeterEngine: Test ist beendet

Die Protokolldatei kann hilfreich sein, um die Ursache eines Fehlers zu ermitteln, da JMeter einen Test nicht unterbricht, um einen Fehlerdialog anzuzeigen.

1.4.8 Vollständige Liste der Befehlszeilenoptionen ¶

Der Aufruf von JMeter als „ jmeter -? “ druckt eine Liste aller Befehlszeilenoptionen. Diese sind unten dargestellt.

    --?
        Befehlszeilenoptionen drucken und beenden
    -h, --Hilfe
        Nutzungsinformationen drucken und beenden
    -v, --version
        Ausgabe der Versionsinformationen und Beenden
    -p, --profil <Argument>
        die zu verwendende jmeter-Property-Datei
    -q, --addprop <Argument>
        zusätzliche JMeter-Property-Datei(en)
    -t, --testfile <Argument>
        die jmeter test(.jmx)-Datei, die ausgeführt werden soll
    -l, --logfile <Argument>
        die Datei, in der Proben protokolliert werden sollen
    -i, --jmeterlogconf <Argument>
        jmeter-Protokollierungskonfigurationsdatei (log4j2.xml)
    -j, --jmeterlogfile <Argument>
        jmeter-Ausführungsprotokolldatei (jmeter.log)
    -n, --nongui
        Führen Sie JMeter im Nicht-GUI-Modus aus
    -s, --server
        Führen Sie den JMeter-Server aus
    -H, --proxyHost <Argument>
        Legen Sie einen Proxy-Server fest, den JMeter verwenden soll
    -P, --proxyPort <Argument>
        Legen Sie den Proxy-Server-Port fest, den JMeter verwenden soll
    -N, --nonProxyHosts <Argument>
        Liste der Nicht-Proxy-Hosts festlegen (z. B. *.apache.org|localhost)
    -u, --username <Argument>
        Legen Sie den Benutzernamen für den Proxy-Server fest, den JMeter verwenden soll
    -a, --password <Argument>
        Legen Sie das Passwort für den Proxy-Server fest, den JMeter verwenden soll
    -J, --jmeterproperty <Argument>=<Wert>
        Definieren Sie zusätzliche JMeter-Eigenschaften
    -G, --globalproperty <Argument>=<Wert>
        Globale Eigenschaften definieren (an Server gesendet)
        zB -Gport=123
         oder -Gglobal.properties
    -D, --systemproperty <Argument>=<Wert>
        Definieren Sie zusätzliche Systemeigenschaften
    -S, --systemPropertyFile <Argument>
        zusätzliche Systemeigenschaftsdatei(en)
    -f, --forceDeleteResultFile
        Erzwingen Sie das Löschen vorhandener Ergebnisdateien und des Ordners für Webberichte, falls vorhanden, bevor Sie mit dem Test beginnen
    -L, --loglevel <Argument>=<Wert>
        [category=]level zB jorphan=INFO, jmeter.util=DEBUG oder com.example.foo=WARN
    -r, --runremote
        Remote-Server starten (wie in remote_hosts definiert)
    -R, --remotestart <Argument>
        Starten Sie diese Remote-Server (überschreibt remote_hosts)
    -d, --homedir <Argument>
        das zu verwendende jmeter-Home-Verzeichnis
    -X, --remoteexit
        Beenden Sie die Remote-Server am Ende des Tests (CLI-Modus)
    -g, --reportonly <Argument>
        Generieren Sie nur das Berichts-Dashboard aus einer Testergebnisdatei
    -e, --reportatendofloadtests
        Berichts-Dashboard nach Belastungstest generieren
    -o, --reportoutputfolder <Argument>
        Ausgabeordner für das Berichts-Dashboard

Hinweis: Der Name der JMeter-Protokolldatei wird als SimpleDateFormat (auf das aktuelle Datum angewendet) formatiert, wenn er gepaarte einfache Anführungszeichen enthält, z. B. ' jmeter_'yyyyMMddHHmmss'.log '

Wenn der spezielle Name LAST für die Flags -t , -j oder -l verwendet wird, dann nimmt JMeter dies als den letzten Testplan, der im interaktiven Modus ausgeführt wurde.

1.4.9 Herunterfahren im CLI-Modus ¶

Vor Version 2.5.1 hat JMeter System.exit() aufgerufen, wenn ein CLI-Modustest abgeschlossen wurde. Dies verursachte Probleme für Anwendungen, die JMeter direkt aufrufen, sodass JMeter System.exit() für einen normalen Testabschluss nicht mehr aufruft. [Einige schwerwiegende Fehler können immer noch System.exit() aufrufen ] JMeter wird alle Nicht-Daemon-Threads beenden, die es startet, aber es ist möglich, dass einige Nicht-Daemon-Threads noch bestehen bleiben; diese verhindern, dass die JVM beendet wird. Um diese Situation zu erkennen, startet JMeter kurz vor dem Beenden einen neuen Daemon-Thread. Dieser Daemon-Thread wartet eine kurze Weile; Wenn es von der Wartezeit zurückkehrt, konnte die JVM eindeutig nicht beendet werden, und der Thread gibt eine Nachricht aus, um den Grund anzugeben.

Die Eigenschaft jmeter.exit.check.pause kann verwendet werden, um die Standardpause von 2000 ms (2 Sekunden) zu überschreiben. Wenn der Wert auf 0 gesetzt ist, startet JMeter den Daemon-Thread nicht.