Die Vorbereitung von Performancetests für eine komplexe Webanwendung kann knifflig sein und manchmal stößt man auf Hindernisse, die man nicht vorhersehen kann. Wir fassen hier unsere Erfahrungen aus dem Performancetest einer Webanwendung für einen unserer Kunden zusammen.
Als Teil eines unserer Projekte mussten wir Leistungs-/Belastungstests einführen. Diese Art von Tests kann auf viele verschiedene Arten initialisiert werden und hängt hauptsächlich von den Anforderungen und Zielen des Kunden ab. Das Ziel, das wir in unserem Projekt definiert haben, war die Durchführung von API-Aufrufen in einem gegebenen Szenario auf einem Backend-Server (HTTP-Anfragen) und die Messung von Antwortzeiten. Das Szenario der HTTP-Anfragen wurde zuvor mit dem Kunden besprochen und deckte viele verschiedene, reale Benutzerverhaltensweisen in der Webanwendung ab.
Bei der Entwicklung dieser Leistungstests haben wir drei verschiedene Lösungen getestet, um zuverlässige Ergebnisse zur Zufriedenheit des Kunden zu erhalten, zu speichern und zu visualisieren. Im Folgenden werde ich diese drei Ansätze beschreiben:
Die erste erstellte Lösung nutzte die Benutzerfreundlichkeit der Jmeter-Software zur Erstellung der Anforderungsszenarien, die wir dann für eine bessere Integration in unsere Pipeline in einen Taurus-Test (JMX-Datei in eine YAML-Datei) umgewandelt haben.
Danach mussten die Tests ein wenig manuell modifiziert werden, da der integrierte Konverter nicht immer präzise ist und manchmal nicht alle Testelemente enthält. Und nicht zuletzt mussten wir die Taurus-Elemente einrichten (z.B. Anzahl der Benutzer, Laufzeit etc.)
In unserer ersten Lösung wählten wir Taurus als Ausführungssoftware, anstelle von Jmeter, weil Taurus sehr viel einfacher über das Docker-Image auf dem Server integriert werden konnte. Diese Lösung war jedoch nicht perfekt, da wir die Daten der Testergebnisse über lange Zeiträume hinweg speichern müssen (um Berichte zu erstellen und die Daten später bei Bedarf zu analysieren). Während Blazemeter eine sehr schöne Visualisierungen der Testergebnisse ermöglicht, beträgt die Datenspeicherung in der kostenlosen Version nur 7 Tage. Außerdem kann der Benutzer nicht definieren, welche Daten visualisiert werden.
K6.io ist eine moderne Javascript-basierte Software zum Erstellen und Ausführen von Performancetests. Es bietet eine sehr gute Dokumentation und eine einfache Integration (via Docker-Image), und da unsere Standard-UI-Tests in Cypress (ebenfalls Javascript/Typescript) geschrieben wurden, war die Testvorbereitung wirklich einfach.
Die Local InfluxDB-Datenbank ermöglichte uns, Testergebnis-Daten ohne Datenspeicherung auf unseren eigenen Servern zu speichern. Diese Rohdaten können später in jeder von uns gewählten Art und Weise verwendet, analysiert und gefiltert werden, ohne dass sie von anderen Tools modifiziert werden müssen.
Für die Datenvisualisierung haben wir Grafana verwendet, da die Integration mit InfluxDB perfekt vorbereitet ist und wir bereits einige Erfahrungen damit gesammelt haben. Die Daten der Testergebnisse wurden in Echtzeit an die InfluxDB-Datenbank gesendet, so dass wir die Ergebnisse auch in Grafana fast in Echtzeit sehen konnten, da es mit einer minimalen automatischen Aktualisierungsrate von 5 Sekunden arbeitet.
Das Grafana-Dashboard für K6.io-Tests ist im Grafana Plugin-Store zu finden. Natürlich mussten wir einige kleine Modifikationen am Dashboard vornehmen, um die Visualisierungen wie gewünscht darzustellen. In unserem Fall zeigte das K6.io-Testtool einige kleinere Probleme, bei denen wir vermuteten, dass einige der Testergebnisse durch das Testtool leicht verändert wurden und wir nicht genügend Informationen über jede gesendete HTTP-Anfrage erhielten (z. B. Fehlerdetails). Daher gingen wir zu Lösung Nummer 3 über
Als dritte und finale Lösung behielten wir die Integration von InfluxDB und Grafana bei, als Testdurchführungssoftware wählten wir jedoch Jmeter. Wir haben einen Weg gefunden, Jmeter mit den richtigen Plugins als Docker-Image auf unseren Servern zu integrieren. Und wir haben festgestellt, dass Jmeter sehr zuverlässig zu verwenden ist.
Wir mussten nur ein kleines Problem mit der Standard-Speicherzuweisung lösen, da diese nur 256 MB beträgt - zu wenig für unsere Leistungs-/Lasttests.
Diese geringe Speicherzuweisung führte zu Unterbrechungen bei den Testausführungen. Aber zur Verwendung des Docker-Images von Jmeter brauchte es nur eine kleine Modifikation. Wir erhöhten die Zuteilung auf minimal 2 GB und maximal 4 GB. Dies hat alle Probleme schnell gelöst.
Der Grafana Plugin-Store enthält auch ein Dashboard für Jmeter-Tests, und eines davon wurde speziell für die Jmeter/InfluxDB-Integration vorbereitet un d hat unsere alle unsere Anforderungen voll erfüllte und war gut für die Messungen eingerichtet, die wir in der Visualisierung darstellen wollten.
Zusammenfassend kann man sagen, dass die Kombination von Jmeter/InfluxDB/Grafana die zuverlässigste der drei Lösungen mit der höchsten Anpassbarkeit war. Es bot uns die besten Möglichkeiten, Tests durchzuführen, Rohergebnisse auf einer lokalen Umgebung (unseren Servern) zu speichern und diese Ergebnisse in einer Zeitachse mit Grafiken und mit Listen zu visualisieren, in denen Werte als Schwellenwerte mit Farben markiert werden können.
Diese Visualisierung der Testergebnisse hat uns geholfen, einige problematische Bereiche der getesteten Anwendung aufzuzeigen. Wir hoffen, dass unsere Erfahrungen anderen Entwicklern helfen können, die Ursache für Leistungsprobleme ihrer Anwendungen zu identifizieren.
