Wie wir Performancetests vorbereiten

Wie wir Performancetests vorbereiten
18/6/2020

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:

Lösung 1

Test-Tools:
  • Jmeter ( https://jmeter.apache.org/ )
  • Taurus ( https://gettaurus.org/ )
Ergebnisse:
  • BlazeMeter ( https://www.blazemeter.com/ )

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.)

Image 1 - https://gettaurus.org/dat/kb/img/console5.png

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.

Image 2 - https://cdn2.hubspot.net/hubfs/208250/Blog_Images/champion3.png

Lösung 2

Test-Tools:
Datenspeicherung:
Ergebnisse:

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.

Image 3 - https://k6.io/static/198f28898e75a3b3ebba152425cc3dda/7c893/poster-open-source.png

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

Image 4 - https://cdn2.hubspot.net/hubfs/208250/Blog_Images/grafana13.png

(Finale) Lösung 3

Test-Tools:
Datenspeicherung:
Ergebnisse:

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.

Image 5 - https://miro.medium.com/max/1145/1*C1Y5fLDpayFYyxTa3yPedA.png

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.

Teilen:
Martin ist ein fähiger Tester, schnell lernender DevOps und ein zuverlässiger Teamkollege mit HTML und CSS, JavaScript, Cypress und Robot Framework Kenntnissen. Erfahrung mit automatisierten Tests und seit kurzem unser Guru für Performance Tests. Großartiger Rock'n'Roll-Tänzer und Liebhaber von Energy Drinks.

Weitere Artikel dieses Autors

Article collaborators

SABO Mobile IT

Für unsere Kunden aus der Industrie entwickeln wir spezialisierte Software zur Umsetzung von Industry 4.0. IoT, Machine Learning und Künstliche Intelligenz ermöglichen uns, signifikante Effizienzsteigerungen bei unseren Kunden zu erzielen.
Über uns