Aus dem Blickwinkel eines Mathematikers: JMeter – Geliebtes Dreckstool

Bei der codecentric AG setzen wir schon immer bevorzugt auf Open-Source-Werkzeuge und –Lösungen. Folgerichtig ist für mich als Java-Performance-Spezialist JMeter von Apache das Lasttest-Werkzeug der Wahl.

Eine kurze Bemerkung zu Beginn: Dieser Blog-Artikel ist kein umfassender Überblick über JMeter, seine Möglichkeiten und Beschränkungen, sondern stattdessen ein sehr persönlicher Blick auf dieses Werkzeug. Man könnte auch sagen: eine längst überfällige Abrechnung.

Nach einigen Jahren, in denen ich im Wesentlichen in den Bereichen Performance-Optimierung und –Monitoring beschäftigt war, arbeitete ich im letzten Projekt wieder mit JMeter. Während ich früher hauptsächlich den HTTP-Sampler von JMeter benutzt habe, war diesmal der JUnit-Sampler das wichtigste Interface zur Last-Erzeugung.

Mit JMeter Lasttests zu schreiben und durchzuführen ist eigentlich ganz einfach. Im bereits erwähnten Projekt sollten die reichlich vorhandenen funktionalen JUnit-Tests zur Lasterzeugung genutzt werden. Dazu müssen diese Tests lediglich JMeter in Form einer jar-Datei zur Verfügung gestellt werden. Im JUnit-Sampler von JMeter werden anschließend die gewünschte Test-Klasse und die darin enthaltene, auszuführende Test-Methode ausgewählt. Als Klammer um einen oder mehrere JUnit-Sampler fungiert bei JMeter eine sog. Thread-Gruppe, in der die Last (die Anzahl der parallelen Threads) eingestellt wird und die Dauer des Tests. Im Großen und Ganzen war’s das, der Lasttest (oder „Testplan“ im JMeter-Jargon) ist definiert. Man muss nur noch auf den Start-Knopf drücken und der Test wird ausgeführt. Wer weitere Details wünscht, findet diese im in leicht verständlicher Form. Man würde sich etwas mehr explizite Beispiele wünschen, insb. zum Thema Regex, aber insgesamt gesehen handelt es sich um eine exzellente Doku.

Irgendwie ist es mir gelungen, das Gefühl zu verdrängen, das sich bei der Arbeit mit JMeter typischerweise einstellt. Allerdings hat JMeter dieses Gefühl sehr, sehr schnell wieder zurückgebracht. Ich hatte vergessen, dass JMeter – wie jeder von seiner Tagesform abhängige andere Mensch auch – sich richtig launisch aufführen kann, manchmal sogar zickig.

Beispiele gefällig?

• Die Fehlermeldungen des JUnit-Samplers sind recht aussagekräftig – normalerweise. Aber man hüte sich vor auch nur den geringsten Abweichungen zu dem, was JMeter von den Konstruktoren der JUnit-Test-Klasse erwartet. Man kriegt ein knappes „failed to create an instance of the class” an den Kopf geworfen und wird ansonsten von JMeter in seinem Elend alleine gelassen. Auch Google hilft einem in diesem Fall nicht weiter. Vielleicht helfen ja unsere Erfahrungen: JMeter scheint sowohl den Standard-Konstruktor als auch den Konstruktor mit einem einzelnen String-Parameter zu erwarten. Und falls in den Konstruktoren bereits irgendwelche Libraries zum Einsatz kommen (z.B. log4j), benötigt JMeter auch diese.
• Völlig rätselhaft war mir das Verhalten des „Regular Expression Extractor“-Controllers, mit dem man Variablen mittels Regex aus dem Ergebnis des letzten Samplers definieren kann. Der Inhalt dieser Variablen war flüchtig wie eine Seifenblase. Im direkt folgenden Sampler konnte man ihn noch verwenden, danach war er wie vom Winde verweht. Es ist mir nicht gelungen, den Variableninhalt in andere Variablen oder Strukturen zu transferieren und auch kein anderer der vielen denkbaren Workarounds funktionierte.
• Besondere Spannung kommt auf, wenn ein JMeter-Testplan mehrere JUnit-Sampler enthält. Manchmal ändert JMeter die Test-Klassen und Test-Methoden aller Sampler auf die entsprechende Klasse und Methode des aktuellen Samplers ab. Bisher habe ich den Auslöser für diesen Bug noch nicht gefunden.

Nette Features wie diese helfen dabei, die Aufmerksamkeit bei der Arbeit mit JMeter hoch zu halten. Anders ausgedrückt: Ich entwickelte eine handfeste Paranoia gegenüber JMeter, da ich nie sicher war, dass es wirklich das tut, was es soll. Außerdem hat dieses Verhalten den Effekt, den Fehler immer zuerst bei JMeter zu suchen, sobald irgendwo etwas schief geht.

Einige andere Dinge sind lediglich unpraktisch, z.B. die Verzeichnis-Pfade. JMeter liest und schreibt viele Dateien: Testpläne, Testparameter, Ergebnis-Dateien. Die Default-Verzeichnisse für diese Dateien sind aber unterschiedlich: Manchmal ist es das Verzeichnis, in dem der Testplan liegt; ein anderes Mal das JMeter-bin-Verzeichnis. Eine Logik habe ich dabei noch nicht entdeckt.

Führt man Tests über die JMeter-GUI durch und nicht über die Kommandozeile oder ein Skript, so spürt man schnell das dringende Verlangen, nach jedem Testlauf die GUI durchzustarten. Oftmals kann man nur dadurch sicherstellen, dass nicht irgendwelche Artefakte des letzten Tests noch in JMeter aktiv sind. Außerdem ist dies notwendig, um eine frische JVM zu kreieren, wenn – wie z.B. in einem typischen JUnit-Test-Szenario – alles in einer einzelnen JMeter-JVM läuft: JMeter, die JUnit-Test-Klassen und manchmal sogar auch noch das zu testende Java-System selbst.

So weit, so schlecht. JMeter ist also ein Dreckstool. Warum liebe ich es dennoch? Nun – JMeter hat praktisch keine Abhängigkeiten, ist schnell installiert, Open Source und kostenlos. Und zu all dem bietet es eine erstaunliche Flexibilität. Am häufigsten findet wahrscheinlich der HTTP-Sampler Verwendung, da er die ideale Schnittstelle ist, um Web-Anwendungen aus Anwendersicht zu testen. Andere Sampler, wie z.B. der hier beschriebene JUnit-Sampler, setzen auf einer tieferen, technischen Ebene an. Zur Zeit bietet JMeter ca. 20 verschiedene Sampler, die auf vielen unterschiedlichen Protokollen operieren.

Eine weitere nützliche Zugabe ist das sogenannte Performance-Plugin für Jenkins, das de facto ein JMeter-Plugin ist. Bei codecentric möchten wir so viel automatisieren wie nur irgend möglich und mit dem Performance-Plugin gelingt dies sogar mit JMeter-Performance-Tests.

Und wem das noch nicht reicht, der kann direkt den JMeter-Testplan hacken (der nur eine XML-Datei ist) – aber auch dabei muss man sich vor den Launen JMeters hüten, da nicht alle Modifikationen funktionieren, die logisch betrachtet möglich sein sollten – oder auch seinen eigenen Zusatz-Code schreiben.

JMeter erinnert mich an den Spruch eines alten Freundes, der mir über sein erstes Auto – einen kleinen Franzosen – Folgendes erzählt hat: „Ich wollte immer ein Auto mit Charakter. Und dieses Auto hat einen Charakter: Einen miesen zwar, aber es hat Charakter.“ Er liebte sein Auto.

Insgesamt gesehen: Werde ich JMeter wieder benutzen? Ganz gewiss. JMeter hilft einem, den Job zu erledigen, trainiert die Stressresistenz und nicht zu vergessen: Man lernt Demut.