Last- und Performance-Tests mit JMeter oder Gatling

Die Performance wird bei Anwendungen zunehmend zur kritischen Anforderung. Je früher Performanceengpässe erkannt und Grenzen bekannt sind, desto so einfacher lässt sich darauf reagieren. Im Folgenden vergleicht heise Developer zwei beliebte Lasttestwerkzeuge – den Platzhirsch JMeter und seinen Herausforderer Gatling.

In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen
Last- und Performance-Tests mit JMeter oder Gatling
Lesezeit: 10 Min.
Von
  • Frank Pientka
Inhaltsverzeichnis

Die Anfänge von Apache JMeter reichen noch ins letzte Jahrtausend, als das Web und der Java-Webserver Apache Tomcat noch in den Kinderschuhen steckten, für den JMeter ursprünglich entwickelt wurde. Das Alter sieht man JMeter mit seiner Swing-basierten Oberfläche an. Ansonsten hat das Tool über die Jahrzehnte eine kontinuierliche Weiterentwicklung erfahren und seine Reife in vielen Einsätzen bewiesen. Letztlich dient die Oberfläche nur dazu, die XML-basierten Testpläne zu erstellen und testweise auszuführen. Meist wird JMeter jedoch nicht über die Oberfläche, sondern auf der Kommandozeile mit dem folgenden Aufruf gestartet:

jmeter -n -t <testplan JMX file> -l <testlog file> -e -o
<Path to resultsoutput folder>

Einfacher JMeter-Testplan (Abb. 1)

Um die Heise-Webseite zu testen, brauchen Entwickler mindestens eine Thread-Gruppe und einen HTTP Requester. Umfangreichere Testpläne lassen sich für HTTP auch mit einem Testrecorder erstellen. Wenn man hier vorher die Variablen mit Werten angelegt hat, lassen sich die Werte beim Aufnehmen durch entsprechende Variablen ersetzen. Damit der Testrecorder Anfragen und Antworten mitschreibt, wird JMeter als Proxy zwischen Browser und aufgerufenen Server gestellt. Alternativ kann man die HTTP-Anfragen und -Antworten durch entsprechende Browsererweiterungen im HAR-Format (HTTP Archive) speichern. Das HAR-Archiv lässt sich dann mit Werkzeugen, zum Beispiel online mit dem ".har to .jmx converter", in das JMX-Format eines JMeter-Testplans umwandeln.

Bei großen verteilten Tests kommt eine Master-Slave-Konfiguration zum Einsatz, bei der die Slaves (jmeter-server.[bat|sh]) vorher gestartet werden und mit dem Master (jmeter.bat Remote Start All remote_hosts) über den RMI-Port 1099 (Remote Method Invocation) kommunizieren. Der Master steuert nicht nur die Testausführung und die Verteilung des Testplans, sondern sammelt auch die Ergebnisse ein. Da jedoch viele Firewalls das RMI-Protokoll blockieren, nehmen oft eigene, über SSH angesprochene Skripte das Ausführen und Steuern vor. Hierfür gibt es im Web einige Cloud-Angebote, etwa von BlazeMeter, das letztes Jahr von CA übernommen wurde. Oder man verwendet die Cloud-Dienste von AWS wie EC2, um selbst ein JMeter-Testszenario aufzubauen. Die Cloud hat für Performancetests den Vorteil, dass Ressourcen flexibel und kostengünstig auf Bedarf zur Verfügung stehen. Ein fertiger Satz von JMeter-EC2-Skripten findet sich beispielsweise auf Oliver Lloyds GitHub-Seite.

Neben der altbackenen Oberfläche und der begrenzten Multithreading-Fähigkeit gab es an JMeter vor allem Kritik an eingeschränkten Berichtsmöglichkeiten. Doch seit der 3er-Version, die sich leider drei Jahre Zeit gelassen hat, gibt es interaktive HTML-Berichte mit erweiterten Metriken wie Apdex (Application Performance Index). Es stehen nach wie vor Möglichkeiten zur Verfügung, entweder kostenlos die Testergebnisse von BlazeMeter Sense als aussagekräftigen fertigen Online-Report erstellen zu lassen oder die Tests kostenpflichtig auf deren Infrastruktur von BlazeMeter auszuführen. Als Bonus kann man den Testbericht auch als PDF-Bericht herunterladen, um ihn zu versionieren oder an anderer Stelle zu verwenden.

Eine weitere Option, die Fähigkeiten von JMeter zu erweitern, sind Plug-ins. Hier bringt JMeter eine stetig wachsende Zahl eigener Erweiterungen mit. Es besteht zusätzlich die Option, eine Vielzahl spezialisierter Plug-ins herunterzuladen oder über den Plug-in-Manager einfach zu aktualisieren. Die damit erstellten Download-Statistiken zeigen, dass neuere JMeter-Versionen nach nur wenigen Wochen eingesetzt werden.

Verwendete JMeter-Versionen (Abb. 2)

Auch Testpläne, die mit älteren JMeter-Versionen erstellt wurden, sind ohne Probleme mit neueren Versionen einsetzbar, was den Umstieg erleichtert. Testpläne sollten unbedingt parametrisiert erstellt werden, damit sie in den Testumgebungen einfach zu nutzen sind. Um die Tests an spezielle Anforderungen anzupassen, gibt es die Möglichkeit, über Pre- und Post-Prozessoren das Verhalten zu beeinflussen. Hier ist besonders der JSON Path oder der Regular Expression PostProcessor hilfreich, um zusammen mit einfachen Groovy- oder JavaScript-Schnipseln als JSR 223 (Scripting for the Java Platform) Processor, Sampler, Assertion oder Listener das Verhalten der Tests zu beeinflussen. Dass sich JSR-223-Skripte vorkompilieren lassen, beschleunigt deren spätere Ausführung.

JMeter ist durch die breite Protokollunterstützung bekannt. So ist das Werkzeug nicht nur auf die typischen Webprotokolle (HTTP, FTP, SOAP, SMTP, POP3, IMAP, OAuth) beschränkt, sondern kann auch Java-EE-Standardprotokolle (JDBC, LDAP, JMS) verwenden, um die gesamte Systeminfrastruktur zu testen.

JMeter hat sich über die letzten Jahrzehnte zu einer verlässlichen Größe im Bereich Last- und Performancetests entwickelt. Dabei ist die Technik nicht stehen geblieben. Außerdem gibt es eine Vielzahl von Büchern, Informationen und Erweiterungen dazu, die kaum Wünsche offenlassen.