JMeter Tests mit Maven und Jenkins automatisieren

Mein letzter Post war ein Appell an Entwickler, öfter auf Lasttests zurückzugreifen , um bereits während der Entwicklung mögliche (Performance-)Probleme in der Anwendung zu identifizieren. Die Hürde dabei ist oft nicht so sehr das mangelnde Interesse, sondern der Aufwand, den man betreiben muss, um einen Lasttest durchzuführen. In meinem letzten Projekt lagen zum Beispiel zwei sehr ausführliche JMeter Tests im Source-Code-Repository. Daneben lag eine etwas längliche README-Datei, in der beschrieben wurde, was alles nötig ist, um den Test durchzuführen. Von der Installation von JMeter (ok, das muss sein) über nötige Plugins und zusätzliche JARs (für den JUnit-Sampler) bis hin zu den nötigen Anpassungen der Konfiguration war ich eine gute Stunde beschäftigt. Von Versionsproblemen und dem Setup der Testdatenbank ganz zu schweigen.

Als Entwickler ist man es gewohnt, zu automatisieren, wo es nur geht. Das Lasttest-Tool JMeter ist hierbei keine Ausnahme. Idealerweise sollten JMeter Tests auf Knopfdruck ausgeführt werden können. Und das in jeder Umgebung: Lokal auf dem Entwickler-Laptop, vom Jenkins gegen ein Testsystem oder als ausgewachsener Lasttest mit verteilten Agenten gegen ein produktionsähnliches Staging-System. Am einfachsten lässt sich das erreichen, wenn man JMeter in den Maven-Build integriert. Wie das aussehen kann, werde ich in den nächsten Abschnitten zeigen.

Integration von JMeter in den Maven-Build

Für die Integration von JMeter in den Maven-Build gibt es zwei Plugins (zumindest habe ich nur diese beiden Plugins gefunden): jmeter-maven-plugin und chronos-maven-plugin. Bei der Wahl des Plugins waren mir die folgenden Anforderungen wichtig (das kann natürlich von Projekt zu Projekt unterschiedlich sein):

1. Das Plugin soll nicht von einer lokalen JMeter-Installation abhängig sein. Wenn nötig muss JMeter automatisch heruntergeladen werden (woher auch immer).
2. Es muss möglich sein, Tests von der Kommandozeile ohne GUI zu starten und die Testergebnisse an einem vordefinierten Ort abzulegen.
3. Es muss ebenfalls möglich sein, die JMeter-GUI aus Maven heraus zu starten.
4. Die Verwendung von JMeter-Plugins sollte einfach sein.
5. Es muss eine Möglichkeit geben, sinnvolle Reports zu generieren.

Die ersten drei Punkte werden von beiden Maven-Plugins erfüllt. Beim Reporting kommt es immer auf die konkreten Anforderungen an. Für das Chronos Plugin gibt es ein zusätzliches Reporting-Plugin, das die Ergebnisse des Tests in einen Maven-Report einbettet. Ich war vor allem auf der Suche nach aussagekräftigen Graphen, weshalb ich den Benefit des chronos-reporting-plugins nicht so hoch einschätzte. Der vierte Punkt war letztendlich ausschlaggebend dafür, dass meine meine Wahl auf das jmeter-maven-plugin fiel. Durch einfaches Hinzufügen einer Abhängigkeit zu kg.apc:jmeter-plugins waren die JMeter-Plugins sowohl im GUI wie auch im Headless Modus verfügbar. Diese Möglichkeit habe ich für das Chronos-Plugin nicht gefunden.

Die folgenden Code- und Konfigurationsschnipsel sind dem Beispiel-Projekt jmeter-maven-example entnommen. Für das Projekt existiert auch ein öffentlicher Jenkins, auf dem exemplarisch ein Job konfiguriert ist. Der Job erlaubt es, auf Knopfdruck JMeter Tests gegen eine echte (auf CloudBees gehostete) Anwendung durchzuführen. Die Konfiguration des Jenkins-Jobs wird weiter unten noch im Detail erklärt.

1<plugin>
2  <groupId>com.lazerycode.jmeter</groupId>
3  <artifactId>jmeter-maven-plugin</artifactId>
4  <version>1.8.1</version>
5  <configuration>
6    <!--
7       Die Ergebnisse werden normalerweise in einer Datei 
8       /target/jmeter/results/<TestName>-<TimeStamp>.jtl abgelegt. 
9       Für die Weiterverarbeitung ist der Timestamp nur hinderlich.
10    -->
11    <testResultsTimestamp>false</testResultsTimestamp>
12 
13    <!--
14       Für die Fehlersuche bewährt es sich anfangs das LogLevel hochzuschrauben.
15       Die JMeter-Logs werden in die Datei jmeter.log geschrieben.
16    -->
17    <overrideRootLogLevel>DEBUG</overrideRootLogLevel>
18 
19    <!--
20       Konsolen-Ausgaben des JMeter-Prozesses werden standardmäßig unterdrückt (warum auch 
21       immer). Es wird aber explizit der Listener "Create Summary Results" verwendet, damit
22       auf der Konsole der aktuelle Testfortschritt mitverfolgt werden kann.
23    -->
24    <suppressJMeterOutput>false</suppressJMeterOutput>
25 
26    <!--
27       Wenn Tests fehlschlagen (z.B. HTTP-Requests in einen Timeout laufen), wird normalerweise
28       auch das entsprechende Maven-Goal als fehlerhaft markiert (und nachfolgende Schritte nicht
29       mehr ausgeführt). Im Beispiel sollen aber trotz Fehler Graphen erzeugt werden.
30    -->
31    <ignoreResultFailures>true</ignoreResultFailures>
32  </configuration>
33  <dependencies>
34    <dependency>
35      <groupId>kg.apc</groupId>
36      <artifactId>jmeter-plugins</artifactId>
37      <version>1.0.0</version>
38      <exclusions>
39         <!--
40            Leider sind einige Abhängigkeiten nicht in mvncentral zu finden,
41            deshalb müssen sie hier explizit ausgeschlossen werden.
42            Für eine vollständge Liste, siehe https://github.com/mlex/jmeter-maven-example/
43        -->
44        <exclusion>
45            <groupId>kg.apc</groupId>
46            <artifactId>perfmon</artifactId>
47        </exclusion>
48        <!-- ... -->
49 
50        <!--
51            Aufgrund eines Bugs im jmeter-maven-plugin (siehe 
52            https://github.com/Ronnie76er/jmeter-maven-plugin/issues/77) müssen 
53            JMeter-Abhängigkeiten auch ausgeschlossen werden.
54        -->
55        <exclusion>
56            <groupId>org.apache.jmeter</groupId>
57            <artifactId>jorphan</artifactId>
58        </exclusion>
59        <!-- ... -->
60      </exclusions>
61    </dependency>
62  </dependencies>
63</plugin>

Die JMeter Tests werden einfach im Verzeichnis /src/test/jmeter abgelegt. Durch mvn jmeter:gui kann man die JMeter GUI starten. Dort kann man die Tests bearbeiten oder direkt aus der GUI heraus ausführen. Durch mvn jmeter:jmeter werden die Tests ohne GUI ausgeführt. Für diese Art der Ausführung eignet sich übrigens der JMeter Listener Create Summary Results um kontinuierlich (durch einfache Konsolenausgaben) über den Fortschritt des Tests informiert zu werden.

Damit die Tests problemlos auf unterschiedlichen Umgebungen ausgeführt werden können, ist es sinnvoll, die Konfiguration für diese Umgebungen irgendwo zentral abzulegen, zum Beispiel in einem Maven-Profil. Im Beispiel-Projekt sind auf diese Weise zwei Konfigurationen (für lokale Ausführung, sowie für Ausführung auf dem Jenkins) hinterlegt. Die Maven-Properties können über die userProperties Option des JMeter Maven Plugins an JMeter übergeben werden. Im JMeter Test kann man auf die Einstellungen dann mit Hilfe der Funktion ${__P(propertyName)} zugreifen.

1<profiles>
2  <profile>
3    <id>local</id>
4    <properties>
5      <performancetest.webservice.host>localhost</performancetest.webservice.host>
6      <performancetest.webservice.port>8080</performancetest.webservice.port>
7    </properties>
8  </profile>
9  <profile>
10    <id>jenkins</id>
11    <properties>
12      <performancetest.webservice.host>my.test.system</performancetest.webservice.host>
13      <performancetest.webservice.port>80</performancetest.webservice.port>
14    </properties>
15  </profile>
16  <build>
17    <plugins>
18      <plugin>
19        <groupId>com.lazerycode.jmeter</groupId>
20        <artifactId>jmeter-maven-plugin</artifactId>
21        <version>1.8.1</version>
22        <configuration>
23          <propertiesUser>
24            <webservice.host>${performancetest.webservice.host}</webservice.host>
25            <webservice.port>${performancetest.webservice.port}</webservice.port>
26          </propertiesUser>
27        </configuration>
28      </plugin>
29    </plugins>
30  </build>
31</plugin>

JMeter Tests aus Jenkins heraus starten

Nachdem man bereits unterschiedliche Maven-Profile angelegt hat, ist die Konfiguration eines entsprechenden Jenkins-Jobs nicht mehr schwer. Interessant ist noch die Möglichkeit, auch den Umfang der Lasttests (d.h. die Anzahl der Threads und der Iterationen) über Maven-Properties festzulegen. Kombiniert mit einem parametrisierbaren Jenkins-Job erhält man so die Möglichkeit auf Knopfdruck unterschiedliche dimensionierte Lasttests zu starten.

Reporting

Wie bereits erwähnt, kann man sich darüber streiten, wie „sinnvolles“ Reporting aussieht. Wie der Berater so schön sagt: „It depends“. Für regelmäßig durchgeführte, immer gleich dimensionierte Performance-Tests eignet sich das Performance Plugin für Jenkins . In meinem Fall war ich hauptsächlich an Graphen interessiert, die das Systemverhalten im zeitlichen Verlauf des Tests wiederspiegeln. Diese Graphen können auch ohne GUI mit dem CMDRunner der JMeter-Plugins erstellt werden. Mit einigem Verbiegen und dem exec-maven-plugin war es auch möglich, die Erstellung der Graphen in den Maven-Build zu integrieren. Die nötige Konfiguration sieht nicht sehr schön aus, deshalb beschränke ich mich an dieser Stelle auf einen Link zum Beispielprojekt . Ein Maven-Plugin, das die Erstellung der Graphen für JMeter Tests wesentlich vereinfacht, ist bereits in Arbeit: jmeter-graph-maven-plugin .

Ergebnis

Am besten lässt man Bilder sprechen. Vom Start …

… über die Dimensionierung …

… und den Testdurchlauf …

… bis zum übersichtlichen und leicht verständlichen Ergebnis …

… sind es nur wenige Schritte. So einfach können Lasttests sein.