JMeter Tutorial – Teil 1

Download JMeter

Start JMeter:
C:<path>\apache-jmeter-5.1.1\bin\ApacheJMeter.jar

HTTP(S) Test Script Recorder
Um mit JMeter eine Webseite auf Performance zu testen, müssen wir den Workflow (request/response) zunächst einmal aufnehmen. Die Aufnahme des Workflows bei einer HTTPS Verbindung wird wie folgt vorgenommen:

JMeter stelle ein Proxy Server zur Verfügung, der in der Standardeinstellung auf den Port 8888 hört.

Da wir uns nicht für die Grafiken, CSS Datein etc. interessieren, schließen wir diese aus:

Da JMeter auf den Port 8888 hört, müssen wir die Kommunikation mit dem Internet an den lokalen Proxy Server weiterleiten:

Der Aufruf von Webseiten wird jetzt nicht mehr funktionieren. Wir könne erst eine Webseite besuchen, indem wir den Recorder starten:

Beim Start wird ein JMeter root Zertifikat erstellt, der eine Gültigkeit von Tagen hat. Das Zertifikat wird in dem bin Ordner von JMeter abgelegt und muss als nächstes innerhalb der Browsers importiert werden:

Der Import erfolgt bei Firefox unter „Zertifikat anzeigen -> Zertifizierungsstellen -> Importieren“:

Der Recorder läuft und wir können mit der ersten Aufnahme beginnen. Ich möchte an dieser Stelle das Login auf einer Webseite aufnehmen:

Wir man in der Abbildung sehen kann, öffnet JMeter nach dem Start den obigen Transactions Control Popup, den wir zunächst einmal ignorieren können. Die Aufnahme wird abgeschlossen, sobald wir auf den Stop Knopf klicken.

Nach dem erfolgreichen Login wird die Welcome Page angezeigt:

Die Aufnahme wird anschließend innerhalb von JMeter angezeigt:

BlazeMeter
Es besteht auch die Möglichkeit, mit BlazeMeter die Aufnahme vorzunehmen und diese anschließend innerhalb von JMeter zu importieren (drag&drop). Hat den Vorteil, dass man die Proxy Einstellung nicht mehr vornehmen muss. Zusätzlich sind die BlazeMeter Records schlanker, da unnötige Kommunikation ausgefiltert wird. BlazeMeter bietet auch Browser Plugins an.

Auf http://blazedemo.com kann BlazeMeter getestet werden bzw. hier kann eine Flug-Buchung simuliert werden.

Thread-Group
Der Record von BlazeMeter beinhalten einen Thread-Group. Ein Thread dient dazu, eine Aufnahme x mal zu wiederholen, um eine echte Belastung zu simulieren. Wenn wir ohne ein Thread group auf play klicken, führen wir den Record nur einmal aus.

Manuell wird ein Thread-Group wie folgt hinzugefügt:

Anzahl Threads is gleich zu setzen mit Anzahl Benutzer. In diesem Fall möchte den Zugriff von 100 Benutzer simulieren d.h. 100 Benutzer sollen den aufgezeichneten Workflow (Record) ausführen.
Die 100 Personen sollen den Record innerhalb einer Zeitperiode von 2 Sekunden ausführen d.h. innerhalb von Sekunden werden 100 Personen den Worflow ausführen. Die 1 bedeutet, dass der Thread nur einmal laufen soll. Bei Auswahl von ‚endlos Wiederholung‘ werden die 100 Personen innerhalb von 2 Sek. den Worflow ausführen und danach wieder von neuem beginnen und danach wieder und wieder. Ist ‚endlos Wiederholung‘ ausgewählt, so kann man unter ‚Dauer (Sekunden)‘ angeben, dass z.B. bei 120 die Ausführung so lange wiederholt wird, bis die 120 Sekunden erreicht wurden.

Unter ‚Aktionen bei einem Sample-Fehler….‘ kann festgelegt werden, was in einem Fehlerfall passieren soll z.B. einfach mit dem nächsten Loop (Durchlauf) beginnen.

Reporting
Bevor wir mit der Ausführung der Records beginnen müssen wir ein oder mehrere Lister in das Projekt einbinden. Ein Listener hat die Aufgabe ein Report zu generieren z.B. Reponse Time Graph.

Ich werde die folgenden Listener einbinden:
– View Result Tree
– Report
– Generate Summary Results
– Graph

View Result Tree Ergebnis zeigt, dass keine Fehlerhafte Kommunikation vorlag (grüne Markierung). Zuzsätzlich bekommen wir die Request/Response Informationen angezeigt:

Report zeigt folgende Informationen an:

Sample: Anzahl der Aufrufe von reserve.php (req/resp). In diesem Beispiel wurde reserve.php 10x bzw. von 10 Benutzer aufgerufen.
Average: Die 10 Aufrufe haben im Durchschnitt 212 Millisekunden benötigt. Bei einem Benutzer hat z.B. die Verarbeitung länger gedauert als bei einem anderen Benutzer.
Median: Der Median bzw. die Person, der ein Median repräsentiert hat von 150 Millisekunden ein Response erhalten.
90% Line: 90% der Benutzer d.h. 90% von 10 = 9 haben im Durchschnitt innerhalb von 322 Millisekunden ein Response erhalten. Die gleiche Information auch für 95% und 99%.
Min: Die schnellste Antwort hat ein Benutzer nach 131 MS erhalten.
Maximum: Am Längsten musste ein Benutzer mit 359 MS auf eine Antwort warten.
Error %: Fehlerrate in %.
Throughput: Anzahl Requests die ein Server pro Sekunde verarbeiten kann d.h. der Server kann 1.3 req pro Sekunde verarbeiten.

Das Plugin „View Result Tree“ zeigt zwei unterschiedliche Samples an:
1. Main Samples: ist in diesem Fall reserver.php und purchase.php.
2. Sub-Sample: sind die darunter liegenden calls z.B. purchase.php-0.

HTTP Cookie
Wer die Cookies z.B. Login Cookie speichern möchte, kann den hierfür benötigten Cookie Manager unter „Add -> Config Element -> HTTP Cookie Manager“ einbinden. Die Einbindung erfolgt unter dem entsprechenden Thread-Group.

JMeter Plugins Manager
JMeter kann mit Hilfe von Plugins erweitert werden. Diese kann man unter anderem hier downloaden: https://jmeter-plugins.org

Es besteht auch die Möglichkeit den JMeter Plugin Manager zu installieren, der einem erlaubt, die Plugins aus JMeter zu installieren, statt diese einzeln zu importieren.

Ein paar der beliebtesten Plugins sind:
– Custom Thread Groups
– Ultimate Thread Group
– Throughput Shaping Timer
– PerfMon Servers Performance Monitoring
– 3 Basic Graphs

Assertion
Anhand von Assertions könne wir angebeten, welche Resultate wir eigentlich erwarten z.B. Bei einer Flugbuchung unter http://blazedemo.com erwarte ich nachdem ich den passenden Flug gebucht habe eine Reponse Meldung mit dem Hinweis, dass mein Flug von Paris nach Rome reserviert wurde:

Assertions könne unter „Add -> Assortions -> Response Assertion“ ausgewählt werden. Ich habe in diesem Fall ein Response Assertion hinzugefügt.

….