13. Ferntests

13.1 SSL einrichten ¶

Die einfachste Einrichtung besteht darin, ein Schlüssel/Zertifikat-Paar für alle JMeter-Server und -Clients zu verwenden, die Sie verbinden möchten. JMeter enthält ein Skript zum Generieren eines Schlüsselspeichers, der einen Schlüssel (und das entsprechende Zertifikat) mit dem Namen rmi enthält . Das Skript befindet sich im Verzeichnis bin und ist für Windows-Systeme (genannt bin/create-rmi-keystore.bat ) und Unix-ähnliche Systeme (genannt bin/create-rmi-keystore.sh ) verfügbar. Es generiert ein Schlüsselpaar, das sieben Tage lang gültig ist, mit einer Standard-Passphrase mit dem Wert „ changeit “. Es wird empfohlen, es aus dem bin - Verzeichnis heraus aufzurufen .

Wenn Sie das Skript ausführen, werden Ihnen einige Fragen zu Namen gestellt, die in das Zertifikat eingebettet werden. Sie können eingeben, was Sie wollen, solange das Keystore-Tool dies akzeptiert. Dieser Wert muss mit der Eigenschaft server.rmi.ssl.keystore.alias übereinstimmen , die standardmäßig rmi ist . Eine Beispielsitzung zum Erstellen des Schlüsselspeichers ist unten dargestellt.

$ cd jmeter/bin
$ ./create-rmi-keystore.sh
Wie lautet Ihr Vor- und Nachname?
  [Unbekannt]: rmi
Wie heißt Ihre Organisationseinheit?
  [Unbekannt]: Name meiner Einheit
Wie lautet der Name Ihrer Organisation?
  [Unbekannt]: Name meiner Organisation
Wie heißt Ihre Stadt oder Gemeinde?
  [Unbekannt]: Deine Stadt
Wie heißt Ihr Bundesland oder Ihre Provinz?
  [Unbekannt]: Ihr Staat
Wie lautet der aus zwei Buchstaben bestehende Ländercode für dieses Gerät?
  [Unbekannt]: XY
Ist CN=rmi, OU=Name meiner Einheit, O=Name meiner Organisation, L=Ihre Stadt, ST=Ihr Staat, C=XY richtig?
  [Nein Ja

Kopieren Sie die generierte Datei „rmi_keystore.jks“ in den Ordner „jmeter/bin“ oder referenzieren Sie sie in der Eigenschaft „server.rmi.ssl.keystore.file“.

Die Standardeinstellungen für RMI sollten mit diesem Setup funktionieren. Kopieren Sie die Datei bin/rmi_keystore.jks auf jeden JMeter-Server und -Client, den Sie für Ihr verteiltes Test-Setup verwenden möchten.

13.2 Manuell ausführen ¶

In einigen Fällen funktioniert das jmeter-server-Skript möglicherweise nicht für Sie (wenn Sie eine Betriebssystemplattform verwenden, die von den JMeter-Entwicklern nicht erwartet wurde). So starten Sie die JMeter-Server (Schritt 1 oben) mit einem manuelleren Prozess:

Schritt 1a: Starten Sie die RMI-Registrierung

Seit JMeter 2.3.1 wird die RMI-Registrierung vom JMeter-Server gestartet, daher entfällt dieser Abschnitt im Normalfall. Um zum vorherigen Verhalten zurückzukehren, definieren Sie die JMeter-Eigenschaft server.rmi.create=false auf den Serverhostsystemen und befolgen Sie die nachstehenden Anweisungen.

JMeter verwendet Remote Method Invocation (RMI) als Remote-Kommunikationsmechanismus. Daher müssen Sie die RMI-Registrierungsanwendung (mit dem Namen „ rmiregistry “) ausführen, die mit dem JDK geliefert wird und sich im Verzeichnis „ bin “ befindet. Stellen Sie vor dem Ausführen von rmiregistry sicher, dass sich die folgenden JAR-Dateien in Ihrem Systemklassenpfad befinden:

• JMETER_HOME/lib/ext/ApacheJMeter_core.jar
• JMETER_HOME/lib/jorphan.jar
• JMETER_HOME/lib/logkit-2.0.jar

Schritt 1b: Starten Sie den JMeter-Server

Sobald die RMI-Registrierungsanwendung ausgeführt wird, starten Sie den JMeter-Server. Verwenden Sie die Option " -s " mit dem jmeter-Startskript (" jmeter -s ").

Die Schritte 2 und 3 bleiben gleich.

13.3 Tipps ¶

JMeter/RMI erfordert eine Verbindung vom Client zum Server. Dies verwendet den von Ihnen gewählten Port, standardmäßig 1099 .
JMeter/RMI erfordert auch eine umgekehrte Verbindung, um Probenergebnisse vom Server an den Client zurückzugeben.
Diese verwenden hochnummerierte Ports.
Diese Ports können durch die jmeter-Eigenschaft namens client.rmi.localport in jmeter.properties gesteuert werden .
Wenn dies nicht Null ist, wird es als Basis für lokale Portnummern für die Client-Engine verwendet. Im Moment öffnet JMeter bis zu drei Ports, beginnend mit dem Port, der in client.rmi.localport definiert ist. Wenn Firewalls oder andere Netzwerkfilter zwischen JMeter-Client und -Server vorhanden sind, müssen Sie sicherstellen, dass diese so eingerichtet sind, dass sie die Verbindungen durchlassen. Verwenden Sie bei Bedarf eine Überwachungssoftware, um anzuzeigen, welcher Datenverkehr generiert wird.

Wenn Sie Suse Linux verwenden, können diese Tipps hilfreich sein. Die Standardinstallation kann die Firewall aktivieren. In diesem Fall funktioniert das Remote-Testen nicht richtig. Die folgenden Tipps wurden von Sergey Ten beigesteuert.

Wenn Verbindungen abgelehnt werden, aktivieren Sie das Debuggen, indem Sie die folgenden Optionen übergeben.

rmiregistry -J-Dsun.rmi.log.debug=true \
     -J-Dsun.rmi.server.exceptionTrace=true \
     -J-Dsun.rmi.loader.logLevel=verbose \
     -J-Dsun.rmi.dgc.logLevel=ausführlich \
     -J-Dsun.rmi.transport.logLevel=verbose \
     -J-Dsun.rmi.transport.tcp.logLevel=verbose \

Seit JMeter 2.3.1 wird die RMI-Registry vom Server gestartet; Die Optionen können jedoch weiterhin über die JMeter-Befehlszeile übergeben werden. Zum Beispiel: " jmeter -s -Dsun.rmi.loader.logLevel=verbose " (dh die Präfixe -J weglassen ). Alternativ können die Eigenschaften in der Datei system.properties definiert werden.

Die Lösung des Problems besteht darin, die Loopbacks 127.0.0.1 und 127.0.0.2 aus /etc/hosts zu entfernen . Was passiert ist, dass jmeter-server keine Verbindung zu rmiregistry herstellen kann, wenn 127.0.0.2 Loopback nicht verfügbar ist. Verwenden Sie die folgenden Einstellungen, um das Problem zu beheben.

Ersetzen

`dirname $0`/jmeter -s "$@"

Mit

HOST="-Djava.rmi.server.hostname=[Computername][Computerdomäne] \
      -Djava.security.policy=`dirname $0`/[policy_file]" \
`dirname $0`/jmeter $HOST -s "$@"

Erstellen Sie außerdem eine Richtliniendatei und fügen Sie die Zeile [computer_name][computer_domain] zu /etc/hosts hinzu .

Um das SSH-Tunneln der RMI-Kommunikationskanäle, die beim Remote-Testen verwendet werden, seit JMeter 2.6 besser zu unterstützen:

• eine neue Eigenschaft " client.rmi.localport " kann gesetzt werden, um den RMI-Port zu steuern, der von RemoteSampleListenerImpl verwendet wird
• Um das Tunneln von RMI-Datenverkehr über einen SSH-Tunnel als Remote-Endpunkt unter Verwendung eines Ports auf dem lokalen Computer zu unterstützen, darf die Loopback-Schnittstelle jetzt verwendet werden, wenn sie direkt mit dem Java- Systemeigenschaften-Parameter " java.rmi.server.hostname " angegeben wurde .

13.4 Einen anderen Port verwenden ¶

Standardmäßig verwendet JMeter den Standard-RMI-Port 1099 . Es ist möglich, dies zu ändern. Damit dies erfolgreich funktioniert, müssen alle folgenden Punkte übereinstimmen:

• Starten Sie auf dem Server rmiregistry mit der neuen Portnummer
• Starten Sie auf dem Server JMeter mit der definierten Eigenschaft server_port
• Aktualisieren Sie auf dem Client die Eigenschaft remote_hosts so, dass sie die neuen Remote- Host:Port - Einstellungen enthält

Seit JMeter 2.1.1 unterstützen die jmeter-server-Skripte das Ändern des Ports. Angenommen, Sie möchten Port 1664 verwenden (vielleicht wird 1099 bereits verwendet).

C:\JMETER> SET SERVER_PORT=1664
C:\JMETER> JMETER-SERVER [weitere Optionen]

$ SERVER_PORT=1664 jmeter-server [andere Optionen]

In beiden Fällen startet das Skript rmiregistry auf dem angegebenen Port und startet dann JMeter im Servermodus, nachdem es die Eigenschaft " server_port " definiert hat.

Der gewählte Port wird in der Datei jmeter.log des Servers protokolliert ( rmiregistry erstellt keine Protokolldatei).

13.5 Verwenden eines anderen Musterabsenders ¶

Listener im Testplan senden ihre Ergebnisse an das Client-JMeter zurück, das die Ergebnisse in die angegebenen Dateien schreibt. Standardmäßig werden Samples synchron zurückgesendet, während sie generiert werden. Dies kann sich auf den maximalen Durchsatz des Servertests auswirken; Das Probenergebnis muss zurückgesendet werden, bevor der Thread fortgesetzt werden kann. Es gibt einige JMeter-Eigenschaften, die eingestellt werden können, um dieses Verhalten zu ändern.

Modus

Beispielsendemodus - Standard ist StrippedBatch seit 2.9. Dies sollte auf dem Client-Knoten festgelegt werden.

Standard

Senden Sie Samples synchron, sobald sie generiert werden

Halt

halten Proben in einem Array bis zum Ende eines Laufs. Dies kann viel Arbeitsspeicher auf dem Server beanspruchen und wird nicht empfohlen.

DiskStore

Proben bis zum Ende eines Laufs in einer Festplattendatei (unter java.io.temp ) speichern. Die serialisierte Datendatei wird beim Beenden der JVM gelöscht.

StrippedDiskStore

ResponseData aus erfolgreichen Beispielen entfernen und DiskStore-Sender verwenden, um sie zu senden.

Charge

Gespeicherte Samples senden, wenn entweder die Anzahl ( num_sample_threshold ) oder die Zeit ( time_threshold ) einen Schwellenwert überschreitet, an welchem ​​Punkt die Samples synchron gesendet werden. Die Schwellenwerte können auf dem Server mit den folgenden Eigenschaften konfiguriert werden:

num_sample_threshold

Anzahl der zu akkumulierenden Samples, Standard 100

time_threshold

Zeitschwelle, Standard 60000 ms = 60 Sekunden

Siehe auch den unten beschriebenen Asynch-Modus.

Statistisch

Senden einer zusammenfassenden Probe, wenn entweder die Anzahl oder die Zeit einen Schwellenwert überschreitet. Die Proben werden nach Thread-Gruppenname und Probenbezeichnung zusammengefasst. Folgende Felder werden kumuliert:

• verstrichene Zeit
• Latenz
• Bytes
• Probenanzahl
• Fehler zählen

Andere Felder, die zwischen Proben variieren, gehen verloren.

Abgestreift

ResponseData aus erfolgreichen Proben entfernen

StrippedBatch

ResponseData aus erfolgreichen Beispielen entfernen und Batch-Sender verwenden, um sie zu senden.

Asynchron

Proben werden vorübergehend in einer lokalen Warteschlange gespeichert. Ein separater Worker-Thread sendet die Samples. Dadurch kann der Test-Thread fortgesetzt werden, ohne darauf zu warten, dass das Ergebnis an den Client zurückgesendet wird. Wenn Samples jedoch schneller erstellt werden, als sie gesendet werden können, füllt sich die Warteschlange schließlich und der Sampler-Thread wird blockiert, bis einige Samples aus der Warteschlange entfernt werden können. Dieser Modus ist nützlich, um Spitzen bei der Sample-Erzeugung zu glätten. Die Warteschlangengröße kann angepasst werden, indem die JMeter-Eigenschaft asynch.batch.queue.size (Standard 100 ) auf dem Serverknoten festgelegt wird.

StrippedAsynch

ResponseData aus erfolgreichen Beispielen entfernen und Async sender verwenden, um sie zu senden.

Benutzerdefinierte Implementierung

Legen Sie den mode-Parameter auf den Namen Ihrer benutzerdefinierten Beispiel-Absenderklasse fest. Diese muss die Schnittstelle SampleSender implementieren und über einen Konstruktor verfügen, der einen einzelnen Parameter vom Typ RemoteSampleListener entgegennimmt .

Die folgenden Eigenschaften gelten für den Stapelmodus und den Statistikmodus :

num_sample_threshold

Anzahl der Proben in einer Charge (Standard 100 )

time_threshold

Anzahl der zu wartenden Millisekunden (Standard 60 Sekunden)

13.6 Umgang mit Knoten, deren Start fehlgeschlagen ist ¶

Bei groß angelegten Tests besteht die Möglichkeit, dass ein Teil der Remote-Server nicht verfügbar oder ausgefallen ist. Wenn Sie beispielsweise ein Automatisierungsskript verwenden, um viele Cloud-Maschinen zuzuweisen und sie als Generatoren zu verwenden, können einige der angeforderten Maschinen aufgrund von Cloud-Problemen nicht gestartet werden. Seit JMeter 2.13 gibt es neue Eigenschaften, um dieses Verhalten zu steuern.

Zunächst möchten Sie möglicherweise Initialisierungsversuche wiederholen, in der Hoffnung, dass fehlgeschlagene Knoten ihren Start nur geringfügig verzögert haben. Um Wiederholungen zu aktivieren, sollten Sie die Eigenschaft client.tries auf die Gesamtzahl der Verbindungsversuche setzen. Standardmäßig macht es nur einen Versuch. Um die Wiederholungsverzögerung zu steuern, legen Sie die client.retries_delay- Eigenschaft auf die Anzahl der Millisekunden für den Ruhezustand zwischen den Versuchen fest.

Schließlich möchten Sie den Test möglicherweise noch mit den Generatoren ausführen, die erfolgreich initialisiert wurden, und fehlgeschlagene Knoten überspringen. Um dies zu aktivieren, legen Sie die Eigenschaft client.continue_on_fail=true fest .

13.7 Verwenden eines Sicherheitsmanagers ¶

Wenn Sie JMeter in einer verteilten Umgebung ausführen, müssen Sie sich darüber im Klaren sein, dass JMeter sowohl auf der Server- als auch auf der Client-Seite im Grunde genommen ein Remote-Execution-Agent ist. Dies könnte von einer böswilligen Partei verwendet werden, um sich weiteren Zugriff zu verschaffen, sobald sie einen der JMeter-Clients oder -Server kompromittiert hat. Um dies abzumildern, hat Java das Konzept eines Sicherheitsmanagers, der von der JVM gefragt wird, bevor potenziell gefährliche Aktionen ausgeführt werden. Diese Aktionen können das Auflösen von Hostnamen, das Erstellen oder Lesen von Dateien oder das Ausführen von Befehlen im Betriebssystem sein.

Der Sicherheitsmanager kann durch Festlegen der Java-Systemeigenschaften java.security.manager und java.security.policy aktiviert werden . Sehen Sie sich auf jeden Fall die Quick Tour of Controlling Applications an .

Mit dem neuen Mechanismus von setenv.sh (oder setenv.bat unter Windows) können Sie den Sicherheitsmanager aktivieren, indem Sie den folgenden Codeausschnitt zu ${JMETER_HOME}/bin/setenv.sh hinzufügen :

JVM_ARGS=" \
   -Djava.security.manager \
   -Djava.security.policy=${JMETER_HOME}/bin/java.policy \
   -Djmeter.home=${JMETER_HOME} \
"

Die JVM fügt nun die in der Datei ${JMETER_HOME}/bin/java.policy definierten Policies zu den möglicherweise global definierten Policies hinzu. Wenn Ihre Definition die einzige Quelle für Richtlinien sein soll, verwenden Sie beim Festlegen der Eigenschaft java.security.policy zwei Gleichheitszeichen anstelle von einem .

Die Richtlinien hängen von Ihrem Anwendungsfall ab und es kann eine Weile dauern, bis Sie die richtigen eingeschränkten und zulässigen Aktionen gefunden haben. Java kann Ihnen mit der Eigenschaft java.security.debug helfen, die benötigten Richtlinien zu finden . Setzen Sie es auf Zugriff und es wird alle Berechtigungen protokollieren, die es zulassen soll. Fügen Sie einfach die folgende Zeile zu Ihrer setenv.sh hinzu :

JVM_ARGS="${JVM_ARGS} -Djava.security.debug=access"

Es mag etwas seltsam aussehen, dass wir eine Java-Systemeigenschaft jmeter.home mit dem Wert ${JMETER_HOME} definieren . Diese Variable wird im Beispiel java.policy verwendet , um den Zugriff auf das Dateisystem zu beschränken und ihm nur das Lesen der JMeters-Konfiguration und -Bibliotheken zu erlauben und den Schreibzugriff nur auf bestimmte Speicherorte zu beschränken.

Die folgende Richtliniendefinitionsdatei wurde für einen einfachen Ferntest verwendet. Sie müssen wahrscheinlich die Richtlinien anpassen, wenn Sie komplexere Szenarien ausführen. Die Testpläne werden irgendwo im Home-Verzeichnis des Benutzers unter einem Verzeichnis namens jmeter-testplans abgelegt . Das Beispiel java.policy sieht so aus:

gewähren Sie codeBase "file:${jmeter.home}/bin/*" {
  Berechtigung java.security.AllPermission;
};

gewähren Sie codeBase "file:${jmeter.home}/lib/jorphan.jar" {
  Berechtigung java.security.AllPermission;
};

gewähren Sie codeBase "file:${jmeter.home}/lib/log4j-api-2.11.1.jar" {
  Berechtigung java.security.AllPermission;
};

gewähren Sie codeBase "file:${jmeter.home}/lib/log4j-slf4j-impl-2.11.1.jar" {
  Berechtigung java.security.AllPermission;
};

gewähren Sie codeBase "file:${jmeter.home}/lib/slf4j-api-1.7.25.jar" {
  Berechtigung java.security.AllPermission;
};

gewähren Sie codeBase "file:${jmeter.home}/lib/log4j-core-2.11.1.jar" {
  Berechtigung java.security.AllPermission;
};

gewähren Sie codeBase "file:${jmeter.home}/lib/ext/*" {
  Berechtigung java.security.AllPermission;
};

gewähren Sie codeBase "file:${jmeter.home}/lib/httpclient-4.5.6.jar" {
  Berechtigung java.net.SocketPermission "*", "connect,resolve";
};

gewähren Sie codeBase "file:${jmeter.home}/lib/darcula.jar" {
  Berechtigung java.lang.RuntimePermission "modifyThreadGroup";
};

gewähren Sie codeBase "file:${jmeter.home}/lib/xercesImpl-2.12.0.jar" {
  Berechtigung java.io.FilePermission "${java.home}/lib/xerces.properties", "read";
};

gewähren Sie codeBase "file:${jmeter.home}/lib/groovy-all-2.4.15.jar" {
  Berechtigung groovy.security.GroovyCodeSourcePermission "/groovy/script";
  Berechtigung java.lang.RuntimePermission "accessClassInPackage.sun.reflect";
  Berechtigung java.lang.RuntimePermission "getProtectionDomain";
};

gewähren {
  Berechtigung java.io.FilePermission "${jmeter.home}/backups", "lesen, schreiben";
  Berechtigung java.io.FilePermission "${jmeter.home}/backups/*", "lesen, schreiben, löschen";
  Berechtigung java.io.FilePermission "${jmeter.home}/bin/upgrade.properties", "read";
  Berechtigung java.io.FilePermission "${jmeter.home}/lib/ext/-", "read";
  Berechtigung java.io.FilePermission "${jmeter.home}/lib/ext", "read";
  Berechtigung java.io.FilePermission "${jmeter.home}/lib/-", "read";
  Berechtigung java.io.FilePermission "${user.home}/jmeter-testplans/-", "read,write";
  Berechtigung java.io.SerializablePermission "enableSubclassImplementation";
  Berechtigung java.lang.reflect.ReflectPermission "suppressAccessChecks";
  Berechtigung java.lang.RuntimePermission "accessClassInPackage.jdk.internal.dynalink.support";
  Berechtigung java.lang.RuntimePermission "accessClassInPackage.sun.awt";
  Berechtigung java.lang.RuntimePermission "accessClassInPackage.sun.misc";
  Berechtigung java.lang.RuntimePermission "accessClassInPackage.sun.swing";
  Berechtigung java.lang.RuntimePermission "accessDeclaredMembers";
  Berechtigung java.lang.RuntimePermission "createClassLoader";
  Berechtigung java.lang.RuntimePermission "createSecurityManager";
  Berechtigung java.lang.RuntimePermission "getClassLoader";
  Berechtigung java.lang.RuntimePermission "getenv.*";
  Berechtigung java.lang.RuntimePermission "nashorn.createGlobal";
  Berechtigung java.util.PropertyPermission "*", "lesen";
};