Qualitätssicherung

Doppelter Zieleinlauf

So sieht unsere Testrunde im Dresdner Großen Garten aus.

Warum wir den Lasttest der racemap-App zweimal starten mussten und was wir daraus gelernt haben.

In unseren ersten beiden Beiträgen haben wir euch ausführlich über die Vorbereitungen zum Lasttest der Tracking-App von racemap berichtet und beleuchtet, warum die Wahl auf das Open Source-Tool Apache JMeter fiel. In unserem vorerst letzten Erfahrungsbericht schauen wir uns die Ergebnisse des Performancetest an und erklären, warum auch bei Software der "Mann mit dem Hammer" kommt.

Testrealisierung in JMeter
Unser Test nimmt langsam Form an. Kleine Erinnerung: Es sollen drei Events stattfinden. Ein Event läuft 24 Stunden, die beiden anderen Events laufen je 6 Stunden. Sie starten ca. 8 Stunden nachdem der 24-Stunden-Event angefangen hat, so dass für die folgenden 6 Stunden alle 3 Events parallel laufen. Dann ist die maximale Last zu erwarten.

Zur Ausgabe von Ergebnissen existieren sogenannte Listener, die die Ergebnisse, die beim Testen ermittelt werden, verarbeiten und visualisieren. Darüber hinaus existiert eine Vielzahl von Plugins, mit denen sich die Standardfunktionalitäten von JMeter erheblich erweitern lassen.

Wie kann nun der Use Case als Testszenario in JMeter abgebildet werden? Racemap arbeitet mit einer REST API, welche HTTP(S)-Requests mit JSON-Body entgegennimmt. Für jeden Event lassen sich drei Thread-Gruppen erstellen:

  • Die Registrierung der Sportler zu einem Event erfolgt über zwei POST-Requests, die pro Sportler jeweils nur einmal ausgeführt werden.
  • Das Senden der aktuellen Positionsdaten erfolgt in Abständen weniger Sekunden über einen einzelnen POST-Request.
  • Der Zuschauer wiederum ruft einmal die Racemap-Webseite, eine weitere Unterseite und den Player auf (drei GET-Requests). Der Player selbst wird ca. alle 5 Sekunden über einen weiteren GET-Request aktualisiert.

Da die Funktionsweise der API, die Requests und der Inhalt des JSON-Bodys bekannt sind, lassen sich alle Thread-Gruppen "from scratch" erstellen. Daneben werden Listener hinzugefügt, welche die Antwortzeit, die Transaktionen bzw. Hits pro Sekunde sowie die aktiven simulierten Benutzer protokollieren.

Testdurchführung
Zur Vorbereitung des Lasttests werden noch die Test-Events manuell auf der racemap-Webseite erstellt. Ebenso wird die Überwachung des Racemap-Servers mit HP SiteScope eingerichtet, um an weitere Performance-Kennziffern zu gelangen. Ein kurzer Testlauf mit nur einem Event mit je 100 Sportlern und Zuschauern auf der Entwicklungsumgebung ist erfolgreich. Da wir den "richtigen" Lasttest auf der Produktivumgebung fahren müssen (das versucht man eigentlich zu vermeiden, aber wir haben keine andere Wahl), wählen wir eine Zeitspanne, in der wenig "Publikumsverkehr" auf dem racemap-System herrscht.

Der Lasttest kann starten. Allerdings wird JMeter bereits nach einer Stunde träge und reagiert kaum noch auf Benutzerinteraktionen. Was ist da los? Die Heap-Size war in der Standardeinstellung mit 512 MB für einen solch umfangreichen Lasttest viel zu knapp bemessen. Also schrauben wir sie auf 8 GB hoch. Außerdem sagt die Dokumentation, dass JMeter besser "headless" also ohne GUI ausgeführt werden soll. Auch dies passen wir an und starten erneut. Am nächsten Morgen stellen wir fest, dass wir den Racemap-Server aufgrund der Vielzahl der Transaktionen mit Log-Dateien geflutet haben bis die Festplatte überquoll. Ab dann reagierte das System extrem träge. Die Ergebnisse sind nicht verwertbar. Daher bereinigen wir die Festplatten und wiederholen den Test, der diesmal erfolgreich durchläuft.

Testabschluss und Ergebnisse
Die Ergebnisse des Lasttests werden von JMeter in CSV-Dateien geschrieben. Man erhält ca. 60 GB an Daten. JMeter besitzt die Funktion, diese Daten vs. dem Zeitverlauf graphisch darzustellen. Allerdings lassen sich dabei nicht mehrere Daten, z.B. wie Antwortzeit und Hits pro Sekunde, zusammen in einem Plot darstellen. Aufgrund der Größe der CSV-Dateien (mehrere GB) gestaltet sich die Auswertung mit anderen Plot-Programmen schwierig. Eine Alternative haben wir bisher noch nicht gefunden. Eine Zusammenfassung der Ergebnisse zeigt das racemap-Team auf seinem Blog. Hier finden sich auch die Graphen zum Antwortzeitverhalten für die drei oben genannten Thread-Gruppen.

Was habe ich bzw. was hat die profi.com aus den Testaktivitäten gelernt?
Ich hatte die Chance mich intensiver mit Apache JMeter und HPE Loadrunner auseinanderzusetzen und in die Details des Tools einzusteigen. So konnte ich die Vor- und Nachteile beider Tools kennenlernen. Abhängig vom Einsatzzweck und den Testzielen ist JMeter durchaus eine Alternative zu HP Loadrunner. Die Einsparungen bei den Lizenzkosten erkauft man sich jedoch durch geringeren Komfort und eine schlechtere Wartbarkeit der Testskripte. Im Enterprise-Umfeld bleibt HP Loadrunner die erste Wahl. Für Startups oder kleinere bis mittlere Unternehmen, die den Wunsch nach einmaligen, einfach strukturierten Lasttests haben und hohe Lizenzkosten scheuen, stellt JMeter sicherlich eine interessante Alternative dar.

Autor

Jan Sickmann IT-Consultant
Dr. Jan Sickmann