Generatoren für Lasttests - Jmeter, XLT oder Gatling, welches Tool ist das Richtige?

Lasttest gehen einfach, das ist eine verbreitete Meinung unter Softwareentwicklern. Ja es ist mit den meisten Tools sehr einfach simple Lasttest zu erstellen, die einem "Hello World" Programm entsprechen. Das allein ist natürlich kein Kriterium für die Auswahl eines Lasttest Tools. Wie man sinnvolle Lasttest durchführt wird in einem anderen Artikel beschrieben.

Apache Jmeter 

Jmeter ist der Klassiker, wenn es um Lasttest geht. Jmeter ist in Java geschrieben, lässt sich durch Plugins und eigenen Code erweitern. Viele Plugins sind seit Version 4 Teil von Jmeter. Sonst lassen sich im Internet auch diverse Plugins finden oder man schreibt in Java eine eigenes Plugin, hier z.B. eins zu Testen des Overheads durch HMAC Verschlüsselung (Link). Einfacher ist es selbst Code-Fragmente zu schreiben und direkt im Test auszuführen, dafür gibt es verschiedene Plugins und Sprachen (Beanshell, Groovy). Man kann Test Parametrisieren und auf Properties und Umgebungsvariablen, sehr einfach zugreifen.

Der Test selbst wird mittels einer GUI erstellt und als XML Datei gespeichert. Wenn man will kann man natürlich auch die XML Datei später verändern.

Dei Möglichkeiten Lasttest auszuwerten sind begrenzt aber ausreichend. Für Detailanalysen sollte man der Messungen als CSV protokollieren und mit speziellen Werkzeugen oder Sprachen wie R oder Rstudio durchführen.

Jmeter ist ein ausgereiftes Lastest Tool mit dem Fokus aus Lasterzeugung. Jmeter ist nicht nur für HTTP/S geeignet ist, man kann z.B. auch JDBC oder Mongo Datenbanken testen. Eine weitere Spezialität sind verteilte Lastest um auch grosse Lasten zu erzeugen. Via Script-Sprachen lassen sich die meisten Lasttest-Anforderungen umsetzen. Die Dokumentation ist gut und die Community umfangreich.

Xceptance XLT

XLT, nicht zu verwechseln mit XSLT, ist als kommerzielle Lasttest Werkzeug durch die Firma Xceptance aus Jena entwickelt worden (Link). Seit einiger Zeit ist jedoch frei verfügbar. Diese Professionalität merkt man dem Tool durchgehend an, und es ist schwierig alle Features aufzulisten. Besonders interessant, ist hier die Möglichkeit reale Browser wie den Firefox als Testagenten einzusetzen. Auf diese Weise sind auch gleichzeitig Performance-Messungen möglich.  Im Vergleich zu Jmeter sind die sehr guten Analyse Fähigkeiten hervorzuheben. Es ist für hohe Lasten gut geeignet, fokussiert aber auf HTTP/S. Wem die normalen Fähigkeiten von XLT nicht ausreichen, kann den Lasttest auch als Java Applikation umsetzen, so kann man jede Lasttest-Anforderung umsetzen.

Gatling

Gatling (Link) ist ein relativ neues Lasttest Tool geschrieben in Scale und oft als Herausforderer für die etablierten Lasttest Tools angesehen wird. Lastest werden als Scala Code codiert, wobei für einfache Lasttest kein wirkliches Scala Know-How notwendig ist. Für erfahrene SCALA Entwickler ist es sicher auch einfach anspruchsvolle Lasttest-Anforderungen als Code umzusetzen. Die Dokumentation ist für Anfänger gut aber nicht sehr umfangreich auch die Community ist nicht mit Grösse der Community von Jmeter vergleichbar. Die Auswertungsmöglichkeiten sind eingeschränkt aber sehr bunt.

Empfehlung

Für einfache Lasttest sind alle Tools geeignet, genauso wie für anspruchsvolle Lasttest geeignet sind. Gatling würde ich ausschliessen, weil SCALA Know How erforderlich ist um komplexe Lasttest umzusetzen. SCALA ist keine populäre Programmiersprache. Im TIOBE Index  ist SCALA nicht unter den Top 20 Programmiersprachen und wird die Top 20 auch nie erreichen. Damit zählt auch SCALA zu den exotischen Programmiersprachen. Eigentlich würde man in diese Kategorie auch Beanshell (Jmeter) und Groovy (Jmeter) einsortieren aber diese Sprachen akzeptieren auch Plain Java. Damit ist es deutlich schwerer erfahrene SCALA Programmierer für Gatling zu finden als erfahrenen Java Programmierer für Jmeter oder XLT. Das merkt man auch der Community und der Dokumentation an. Ich würde Gatling nicht für Produktivumgebungen empfahlen.

Jmeter und XLT sind solide und bewährt. Jmeter hat aber Schwächen bei der Auswertung, die man bei Bedarf leicht ausgleichen kann. Jmeter hat eine umfangreiche Auswahl an Samplern (HTTPS, DB, TCP, ..), und ist dadurch nicht nur für HTTPS Lasttest einsetzbar.
Beide Werkzeuge, Jmeter und XLT sind für die meisten Fälle zu empfehlen. XLT ist das Werkzeug der Wahl wenn es um Browser-basiertes Testen geht, auch sind die XLT Reports und Auswertungsmöglichkeiten hervorragend. Jmeter ist der Allrounder und den Lasttestgeneratoren.

	Jmeter	XLT	Gatling
Geeignet für einfache Lasttest	Gut	Gut	Gut
Geeignet für komplexe Lasttests	Gut	Gut	Ok
Verhält sich wie ein Webbrowser	Bedingt	Ja	Nein
JS Ausführung	Nein	Ja	Nein
Dokumetation	Sehr gut	Sehr gut	Ok
Community	Umfangreich	Gering	Ok
Hochlast	Ja	Ja
Analyse der Ergebnisse	Ok	Sehr gut	Ok
Erweiternbar durch Programmiersprachen	Beanshell/Java/Groovy	Java	SCALA
Test Protokoll und Systeme	HTTPS/JDBC/MongoDB/JMS/AJP/LDAP/SMTP/TCP/…	HTTPS	HTTPS
RampUp Test	Ja	Ja	Ja
Konstant Test	Ja	Ja	Ja
Funtionstest	Ja	Ja	Ja
Performancemessung	Bedingt	Ja	?

Vortrag auf der Hamburger Konferenz Solutions

Ihr könnt mich und das SCALE Team von OTTO auf der 2015 Solution Hamburg erleben. Hier stehen wieder die nichtfunktionalen Anforderungen wie Robustness, Performance, Load und Security im Mittelpunkt.

Datum und Ort:
09. – 11. September 2015
auf Kampnagel in Hamburg

Welche Java GC Version wird benutzt? Oder wie identifiziere ich den Java GC?

Java bietet eine reiche Auswahl an GC Varianten:

1. SerialGC
2. ParallelGC
3. ParallelOldGC
4. CMS GC
5. G1 GC

Zusammen mit den möglichen Parametern hat man einen sehr grossen Suchbereich um den optimalen GC mit den optimalen Einstellungen zu finden. GC Optimierungen haften immer etwas mythisches an. Es gibt Supertricks, die bei genauerem Hinsehen und Testen oft überholt sind. Es hilft nur ein ebenes Testsetting aufzubauen und selbst zu messen.

Damit stellt sich die Frage welcher GC wird denn verwendet, ich gebe doch keinen an. Da hilft die Kommandozeile weiter:

java  -verbose:gc -XX:+PrintGCDetails

Das Ergebnis der Konsole ist spezifisch für die entsprechenden GCs.

SerialGC -XX:+UseSerialGC

Es ist ein genrationaler GC mit den drei Generationen: New Generation Tenured Generation und der Perm Generation. Die New Generation teilt sich in die Bereiche Eden, From und To.

ParallelGC -XX:+UseParallelGC

Es ist ein genrationaler GC mit den drei Generationen: Young Generation, Old Generationen Perm Generation. Die New Generation teilt sich in die Bereiche Eden, From und To. Es lässt sich leicht vermuten, dass der ParallelGC eine weiterentwickelte, parallele Variante des SerialGC ist. Es soll durch die Benutzung von allen Kernen die Dauer der GCs verkürzen. Er macht also nur Sinn, wenn man über mehrere CPU-Kerne verfügt.

CMS GC -XX:+UseConcMarkSweepGC

Es ist ein genrationaler GC mit den drei Generationen: Young Generation, Concurrent Mark Sweep Generationen und der Perm Generation. Die New Generation teilt sich in die Bereiche Eden, From und To. 

Der CMS GC basiert auf den Erfahrungen des ParallelGC. Hier werden möglichst viele GC Schritte (Mark, Sweep) parallel ausgeführt ohne ein Stop-The-World auszuführen. Das heisst man kann ungenutzte CPU Kerne für den GC nutzen, wenn man denn welche hat. Der Overhead des CMS GC ist grösser als des ParallelGC aber durch die Benutzung zusätzlicher CPU Kerne wird dieser negative Effekt überkompensiert, so das der CMS bei vilene normalen Anwendungen die Performance der Anwendung verbessert aber die CPU Usage erhöht. Er ist also sinnvoll, wenn ich freie CPU Ressourcen habe. Zusätzlich braucht der CMS immer freien Speicher für seine Operationen. Er kann nicht den ganzen Speicher ausnutzen.

G1 GC -XX:+UseG1GC

G1 GC Details unter Java 7

G1 oder Garbage First ist der zu letzt entstandene GC. Er setzt auf dem CMS GC auf und ändert die Speicherbenutzung für die Young Generation und die folgende Generation, mit dem Ziel die Speicheroperationen zu minimieren und damit die GC Laufzeiten zu reduzieren. Hier teil sich der Speicher in den Garbage First Heap und die bekannte Perm Generation. Der Garbage First Heap kennt da die Unterteilungen in Young und Survivors. Für den G1 GC gelten die selben Performance und Load Anmerkungen wie für den CMS GC, wobei der G1 leicht bessere Werte als der CMS erzielen sollte.

Unter Java 8 wurde der G1 überarbeitet, das hatte zur Folge, dass der Perm Generation jetzt Metaspace heisst.

Fazit

Genereller Tip, der für 80% aller Anwendungen passt. Macht keine GC Einstellungen, lasst sie weg und nutzt die gewonnene Zeit um die Software robuster zu machen. Tipp 2: Setzt die aktuellste Java Version ein. Ein aktuelles Java mit einem neuen GC schliessen viele Optimierungstricks ein, also nur die sinnvollen.

GC Optimierungen bleiben aufwendig. Nur bei High Performance oder High Load Applikationen sind GC Optimierungen sinnvoll. Aber generell gilt immer, zu erste messen, dann optimieren.

Weitere Informationen zum Java GC:

1. http://www.cubrid.org/blog/dev-platform/understanding-java-garbage-collection/
2. http://www.angelikalanger.com/Articles/EffectiveJava/27.GCTuning/27.GCTuning.html
3. http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html
4. http://www.fasterj.com/articles/oraclecollectors1.shtml

HTTP Client Performance

Für die Load- und Performance-Messungen auf dem Server gibt es eine Reihe von Werkzeugen wie XLT (Link) oder das bekanntere Apache JMeter (Link). Die einfachste Aufgabe ist es eine Reihe von HTTP Request an den zu untersuchenden Server zu senden. Dabei kann man in JMeter die Implementation für den HTTP Request auswählen. Zur Auswahl stehen in JMeter 2.9: HTTPClient3.1, HTTPClient4 und Java. Alternativ brauch man nicht auswählen, dann wir Java als Standard benutzt.

Aber welcher dieser drei HTTP Clients ist die optimale Wahl. Im Atlassian Blog gibt es einen Vergleichstest zwischen verschiedenen HTTP Clients (Link), dabei sind auch die drei JMeter Kandidaten. Eine normale JMeter Anwendung besteht in der Regel aus vielen kleinen HTTP Requests. Bei Atlassian Test für kleine Dateien (80kb) liegt CURL vor  dem HTTPClient3.1 und dem Java (hier Bee). Wie verhalten sich aber die HTTP Clients im JMeter-Test? Dazu habe ich einen kleinen Testaufbau mit einem konstanten Durchsatz von 152 Request/s auf verschiedene kleine HTML- und JSON Fragmente aufgesetzt. Dabei erreichten die Clients folgende Werte für den durchschnittliche Requestdurchsatz und den auf dem Loadwert auf dem JMeter-Client:

1. HTTPClient3.1; 164 Req/s; Load 2.0
2. HTTPClient4; 137 Req/s; Load 2.9
3. Java; 150 Req/s; Load 2.6

Damit bestätigt sich das Bild aus dem Atlassian-Test, die für die meisten Test günstigste Wahl, weil performateste und Ressourcen-schonenste Auswahl ist der alte Apache HTTPClient3.1., der leider nicht mehr weiter entwickelt wird.