Portfolio |

Lasttestauswertung – HTML Report und Custom Graphs in JMeter

HTML-Reports und Custom Graphs bieten die Möglichkeit, die Auswertungen in JMeter auf seine eigenen Bedürfnisse anzupassen. Ich erkläre, wie das funktioniert und was es zu beachten gilt.

Auswertungen eines Lasttests

Die Vorbereitung und Ausführung eines Lasttests sind nur Teile des Lasttest-Prozesses. Danach erfolgten die Analyse und Interpretation der Testergebnisse. Ziel eines Lasttests ist es, wahrscheinliche Risikoquellen zu identifizieren und notwendige Erkenntnisse zu liefern, um Schwachstellen aufzudecken. Diese Schwachstellen können ansonsten zu Anwendungsausfällen und -störungen führen.

Zur Auswertung eines Lasttests stehen meist gewisse Kennzahlen (z. B. Antwortzeit vs. Zeit, Timeouts vs. Userzahl etc.) zur Verfügung. Einige Lasttest-Metriken wurden bereits in einem vorherigen Artikel beleuchtet. Die Ergebnisse eines Lasttests können nur dann ausreichend bewertet werden, wenn vorher die Anforderungen an die Performanz definiert wurden. Es sollten Anforderungen bezüglich der Antwortzeit, des Systemdurchsatzes oder der Ressourcennutzung, der erwarteten Last und Nutzung des Systems erfasst werden. Sind diese gar nicht oder unvollständig vorhanden, können die Testergebnisse nicht eindeutig interpretiert werden. Es kann nicht festgestellt werden, ob der Test bestanden wurde oder nicht.

Die Analyseergebnisse bilden oft die Grundlage für taktische und strategische Entscheidungen, die das Produkt betreffen. Eine verfrühte Inbetriebnahme einer risikobehafteten Website oder Anwendung kann tiefgreifende und unerwünschte Folgen haben, die sich auf den Umsatz, die Marke, die Marktwahrnehmung und das Usererlebnis auswirken. Ist ein Service nicht erreichbar, kann auch kein Umsatz generiert werden. Die genauen Verluste sind abhängig von vielen Faktoren. Laut der Gartner-Studie „The Cost of Downtime“ handelt es sich durchschnittlich um 5.600 Dollar pro Minute, was sich bei einer Stunde auf weit über 300.000 Dollar hochrechnet.

Beispielhafte Auswertung

Jede Auswertung eines Lasttests ist individuell und hängt von verschiedenen Faktoren ab (Anwendungsanforderungen, verwendete Technologie, …). Um trotzdem einen Einblick in die Auswertung gewähren zu können, werden in diesem Abschnitt Beispiel-Metriken aus einem Lasttest für eine Webanwendung erklärt und interpretiert.

Last-Szenario mit Betrachtung von virtuellen Usern und der zugehörigen Antwortzeit

Im oben dargestellten Graphen erkennt man ein Last-Szenario mit insgesamt 70 virtuellen Usern. Die Last steigt linear von 00:00 bis 01:10 an, die volle Last wird von 01:10 bis 01:20 gehalten und baut sich bis 01:40 wieder ab.

Parallel dazu wird die Antwortzeit betrachtet. Von 00:00 bis 00:30 erhöht sich die Antwortzeit kaum. Das bedeutet, dass die getestete Website etwa 30 User ohne Probleme bewältigen kann. Danach beginnt die Antwortzeit auf inakzeptable Werte abrupt anzusteigen. User erleben in dieser Phase eine lange Wartezeit, bis die Website geladen wird. Dies führt oft zu einer erhöhten Unzufriedenheit der User bis hin zum Verlust des Kunden, indem er die Seite verlässt.

Last-Szenario mit Betrachtung von virtuellen Usern und der zugehörigen Fehleranzahl

In dem oberen Graph wird wieder der Verlauf der virtuellen User dargestellt, diesmal jedoch in Bezug auf die Anzahl der Fehler. Von 00:00 bis 00:50 treten keine Fehler auf. Danach bei über 50 virtuellen Usern gleichzeitig auf der Website steigt die Fehlerrate enorm an. Es werden also viele Anfragen mit einem Fehlercode beantwortet und der User ist nicht mehr in der Lage die Website zu erreichen.

Zusammengefasst:

  • Von 00:00 – 00:30 mit bis zu 30 parallelen Usern sind alle Systeme in Betrieb und das System ist unempfindlich gegenüber der Anzahl der aktiven User.
  • Von 00:30 – 00:50 mit bis zu 50 parallelen Usern wird das Verhalten des Netzes langsam instabil. Die Antwortzeiten werden immer länger. Während dieses Zeitraums gibt es noch keine Fehler in den Antworten.
  • Ab 00:50 und über 50 parallelen Usern beginnen die ersten Fehler und erreichen in der Zeit der höchsten Last (01:10 – 01:20, 70 User) ihren Höhepunkt.

Mögliche Ursachen für dieses Verhalten können zum Beispiel eine geringe Netzkapazität, ein volllaufender Speicher oder eine zu geringe Hardwareausstattung sein.

HTML Report in JMeter

JMeter bietet die Möglichkeit einen HTML Report mit verschiedenen Graphen und Statistiken zu erstellen. Der Report kann direkt am Ende eines Lasttests oder mit einer vorhandenen CSV- oder JTL-Datei erzeugt werden.

JMeter lässt sich über GUI und CLI Modus bedienen. Der GUI Modus sollte durch den hohen Ressourcenverbrauch nicht für die Lasttest Ausführung verwendet werden, sondern nur für die Testerstellung.

Per CLI kann der HTML Report direkt nach einem Lasttest mit folgendem Befehl generiert werden:
jmeter -n -t [jmx file] -l [results file] -e -o [Path to report folder]

In dem Report Folder wird die Datei index.html erzeugt. Mit dieser kann der HTML-Report geöffnet werden. Dabei ist er wie folgt aufgebaut:

Beispiel eines HTML-Reports

Die Übersichtsseite zeigt generelle Testinformationen, erfolgreiche und fehlerhafte Requests, Statistiken und Error. Die APDEX-Tabelle gibt für jede Transaktion den Application Performance Index auf Grundlage von konfigurierbaren Schwellenwerten an. Darüber hinaus werden verschiedene Graphen generiert, die auf der linken Menüleiste ausgewählt werden können. Die von JMeter generierten Graphen werden bezüglich des Zeitverlaufs, des Durchsatz und der Antwortzeit dargestellt.

Custom Graphs in JMeter

Seit der Version 5.0 bietet JMeter die Möglichkeit, zusätzliche Graphen als Teil des HTML-Reports zu erstellen. Dabei wird eine Variable im Graphen ausgegeben, die über den Zeitraum des Tests dargestellt werden kann. Solche Variablen können unter anderem sein:

  • eine eigene Metrik, die während des Tests berechnet wird
  • eine Metrik, die vom Server zurückgegeben wird
  • Wert einer Counter-Variable

Um einen eigenen Graphen definieren zu können, muss die user.properties Datei im bin-Ordner von JMeter abgeändert werden. Dabei muss er folgende Informationen enthalten:

  • Name des Graphen
  • Titel des Graphen
  • Beschreibung der X- und Y-Achse
  • Granularität
  • Namen der Variable, die ausgegeben werden soll

Ein Graph kann wie folgt definiert werden:

## Custom graph definition
jmeter.reportgenerator.graph.custom_mm_hit.classname=org.apache.jmeter.report.processor.graph.impl.CustomGraphConsumer
jmeter.reportgenerator.graph.custom_mm_hit.title= Test Graph
jmeter.reportgenerator.graph.custom_mm_hit.property.set_Y_Axis= Elapsed
jmeter.reportgenerator.graph.custom_mm_hit.property.set_X_Axis=Over Time
jmeter.reportgenerator.graph.custom_mm_hit.property.set_granularity=${jmeter.reportgenerator.overall_granularity}
jmeter.reportgenerator.graph.custom_mm_hit.property.setSampleVariableName= elapsed
jmeter.reportgenerator.graph.custom_mm_hit.property.setContentMessage=Message for graph point label 

Unter .setSampleVariableName können verschiedene Standard-Variablen genutzt werden, wie bspw.: elapsed, timeStamp, responseCode, success. Hier können auch die selbst definierten Variablen angegeben werden, die während der Testausführung generiert wurden.

Der daraufhin erzeugte Custom Graph sieht im HTML-Report wie folgt aus:

Ein Custom Graph innerhalb des HTML-Reports

Abschließend ist zu sagen, dass der HTML-Report zwar durch Custom Graphs angepasst werden kann, es sich allerdings immer noch um einen statischen Report handelt. Der Bericht kann nicht vollständig durch Hinzufügen von Text, Bildern und anderen Elementen angepasst werden.

Ausblick

Eine weitere Möglichkeit zur Auswertung von JMeter Tests bietet das Performance Plugin für Jenkins. Wie die Testdurchführung und -auswertung von JMeter in dem CI/CD Tool aussehen kann, beleuchten wir in einem zukünftigen Artikel.

Werfen Sie gern auch einen Blick auf unser Trainingsangebot zum Thema JMeter.