HTTP/2 & WebSocket Loadtests

Der Abschnitt beginnt mit der allgemeinen Definition von Performance als Leistungsfähigkeit. Im Kontext von Webentwicklung beschreibt Performance die Reaktionsgeschwindigkeit einer Anwendung auf Benutzeraktionen. Beispiele hierfür sind das Abschicken von Formularen (z.B. Überweisungen im Online-Banking) oder das Laden von Artikeln in einem Onlineshop. Die Reaktionszeit wird als entscheidender Faktor für die Benutzerzufriedenheit dargestellt. Während einige Sekunden bei komplexen Vorgängen wie Online-Banking akzeptabel sein können, sind für Onlineshops Ladezeiten von über zwei Sekunden kritisch und können zu Kundenverlust führen. Der Text betont, dass Performance ein relativer Begriff ist, der von den Erwartungen des Benutzers abhängt.

Laut Ian Molyneaux lassen sich verschiedene Aspekte der Performance mittels Key Performance Indicators (KPIs) messen. Diese KPIs werden in serviceorientierte und effizienzorientierte Kennzahlen unterteilt. Serviceorientierte KPIs umfassen Verfügbarkeit und Reaktionszeit, welche die Qualität des vom Nutzer erhaltenen Service bewerten. Effizienzorientierte KPIs sind Durchsatz und Kapazität, die die Effizienz der Serverauslastung beschreiben. Die Reaktionszeit wird detailliert als die Zeit definiert, die benötigt wird, um eine Anfrage zu verarbeiten (z.B. das Anzeigen einer Produktliste). Es werden verschiedene Schwellenwerte für akzeptable Reaktionszeiten genannt: dezisekundenschnelle Reaktionen für interaktive Elemente, unter zwei Sekunden für Anwendungen mit hohem Informationsgehalt (z.B. Onlineshop-Produktkataloge). Zusätzlich werden Stress-Tests (zur Überprüfung des Systemverhaltens unter Überlastung) und Soak-Tests (zur Erkennung von Speicherlecks und zur Beobachtung der Reaktionszeitentwicklung über einen langen Zeitraum unter hoher Last) vorgestellt.

Bevor mit der Durchführung von Performance-Tests begonnen werden kann, müssen zunächst die Rahmenbedingungen festgelegt werden. Dieser Schritt, als Nonfunctional Requirements Capture (NFR) bezeichnet, beinhaltet die Definition wichtiger Parameter. Ein zentraler Aspekt ist die Festlegung eines Zeitrahmens für die Durchführung der Tests. Weitere Faktoren, die in diesem Schritt berücksichtigt werden müssen, sind noch nicht explizit im Text benannt, aber implizit als Grundlage für die weiteren Schritte vorausgesetzt.

In diesem Schritt werden die notwendigen Hard- und Softwarekomponenten sowie die Netzwerkanforderungen für die Testumgebung definiert. Die Datenbank sollte mit realistischen Daten befüllt sein, und der Server sollte möglichst dem finalen System entsprechen, um aussagekräftige Testergebnisse zu gewährleisten. Der Aufbau der Testumgebung erfordert eine angemessene Zeitplanung. Es müssen verschiedene Deployment-Modelle (LAN und WAN) berücksichtigt und externe Links entweder durch reale Links oder realistische Simulationen ersetzt werden. Weitere Überlegungen betreffen die Anzahl der benötigten Load Injector, die Testdauer (festgelegt oder datenbegrenzt) und die Berücksichtigung von Nutzer-seitigen Caching-Mechanismen, die die Belastung des Systems beeinflussen können. Die optimale Auslastung von CPU und Speicher wird als Kriterium für verwertbare Testergebnisse genannt.

Nach der Planung müssen die Testskripte erstellt werden. Dabei sollten die Skripte eine detaillierte Sequenz der auszuführenden Aktionen enthalten (Steps for Scripts). Die benötigten Laufzeitdaten (z.B. Logins, Passwörter) müssen spezifiziert werden (Run-Time Data). Es ist ratsam, verschiedene Nutzergruppen zu definieren, um auch den Einfluss von Bildern auf die Performance zu testen. Die Verifizierung umfasst die Überprüfung der verteilten Testausführung auf mehreren Maschinen (falls relevant) und die Einzelprüfung der Szenarien mit jeder Nutzergruppe, bevor der Test mit mehreren virtuellen Nutzern durchgeführt wird. Dies stellt sicher, dass die Einzelergebnisse der verschiedenen Nutzergruppen den Erwartungen entsprechen, bevor sie im Gesamtszenario kombiniert werden. Die Verwendung von Recordern, um die Interaktion mit der Anwendung aufzuzeichnen und in Skripte umzuwandeln, wird als effiziente Methode erwähnt. Diese Methode ermöglicht die Simulation realer Reaktionszeiten.

Gatling zeichnet sich durch übersichtlichen Programmcode aus. Die Simulation von realistischen Nutzerprofilen mittels des mitgelieferten Recorders wird positiv bewertet. Jedes Profil erzeugt eine eigene Serververbindung. Bei hoher Last mit vielen kurzlebigen Tests besteht jedoch die Gefahr von Performance-Problemen auf der Last-erzeugenden Maschine, weshalb ein 'Scaling Out' empfohlen wird. Die Anpassung des Injection-Modells (Anzahl gleichzeitiger User) kann ebenfalls notwendig sein. Zusätzlich wird die Möglichkeit, mehrere Nutzer dieselbe HTTP-Verbindung teilen zu lassen, sowie die Datenvisualisierung, die Einbindung in Versionsverwaltung und die GUI-lose Bedienbarkeit hervorgehoben. Die Skalierbarkeit wird jedoch als mit gewissem Aufwand verbunden beschrieben.

JMeter verwendet ebenfalls einen Script Recorder zur Aufzeichnung von HTTP Requests. Im Gegensatz zu Gatling werden jedoch keine Wartezeiten zwischen den Requests aufgezeichnet und müssen manuell (z.B. mit dem Constant Timer) hinzugefügt werden. Der Recorder zeichnet keine Reaktionszeiten auf, sondern nur die HTTP Requests. Die Einstellung der Anzahl der Wiederholungen, Threads, Anlaufzeit und weiterer Parameter im Thread Groups Element wird erwähnt. Post-Processors extrahieren Informationen aus der Response, und Listener ermöglichen den Zugriff auf Assertion-Ergebnisse. Configuration Elements ermöglichen das Laden von Daten aus CSV-Dateien oder Datenbanken. JMeter kann auch ohne GUI betrieben werden, was für ressourcenintensive Tests auf Servern nützlich ist. Die Einrichtung der verteilten Ausführung erfordert die Konfiguration von JMeter-Server-Maschinen und die Anpassung der jmeter.properties Datei. Der Text stellt fest, dass JMeter aktuell keine HTTP/2 Unterstützung bietet, aber WebSocket-Verbindungen über das Blazemeter Plugin ermöglicht werden.

The Grinder (im Text kurz 'Grinder' genannt) kann teilweise über eine grafische Oberfläche bedient werden, der Start erfolgt jedoch über Shell-Skripte. Die Anwendung basiert auf Java, was die Plattformunabhängigkeit gewährleistet. Die Steuerung mehrerer Load Injector Maschinen erfolgt durch die Aufteilung in GUI und Agenten. Für die Erstellung der Use-Case-Skripte wird Jython verwendet (Clojure wird erwähnt, aber nicht detailliert behandelt). Ein Script Recorder (TCPProxy) ermöglicht die Aufzeichnung von HTTP Requests. Die Integration externer Daten aus Textdateien wird beschrieben, wobei die Limitierung von Jython/Java für Arrays (max. 64KB) als Begründung für die Verwendung von Textdateien genannt wird. Die Synchronisierung von Worker-Threads erfolgt mittels Barriers. Assertions erlauben die Überprüfung der Testergebnisse während des Testablaufs. Die Darstellung der Ergebnisse erfolgt graphisch, wobei die Höhe des Graphen den Peak TPS und die Farben die Reaktionszeit repräsentieren. Der Text merkt an, dass Grinder keine WebSocket- und HTTP/2-Unterstützung bietet.

Der Abschnitt vergleicht die Testausführung der drei Frameworks anhand eines gemeinsamen Szenarios. Dabei wird die Komplexität des Ablaufs von der Skript-Erstellung bis zur Fertigstellung des Testplans verglichen. Die Use-Case-Skripte wurden mit Hilfe der HTTP Proxy Recorder der jeweiligen Frameworks erstellt. Es wird betont, dass nicht alle Features der Frameworks in dieser Arbeit angewendet werden konnten. Bei JMeter werden Wartezeiten zwischen Requests manuell hinzugefügt, da der Recorder diese nicht aufzeichnet. Bei Grinder wird die Console und der TCPProxy über das Terminal gestartet; nach der Interaktion mit der Anwendung wird das Jython-Skript generiert.

Die Frameworks werden im Hinblick auf ihre Stärken und Schwächen bewertet. Gatling wird für seinen übersichtlichen Code und die realitätsnahe Nutzerprofilierung gelobt. Die Skalierbarkeit wird jedoch als aufwändiger implementierbar beschrieben und es wird empfohlen, das Injection Model bei hohen Lasten mit vielen kurzlebigen Tests zu überprüfen. Die Datenvisualisierung, die Versionskontrolle und die GUI-lose Bedienbarkeit werden positiv hervorgehoben. Die Bewertung von JMeter und Grinder im Vergleich zu Gatling wird angedeutet, aber konkrete detaillierte Vergleiche fehlen an dieser Stelle; diese werden erst in späteren Abschnitten erwartet.

Der Vergleich der Performance-Test-Frameworks Gatling, JMeter und Grinder zeigt, dass grundsätzlich alle drei Tools komplexe Testpläne ermöglichen. Obwohl die detaillierten Vorgehensweisen unterschiedlich sind, führen sie zum selben Ergebnis. Signifikante Unterschiede in der Ergebnisbeschreibung sind nicht vorhanden, jedoch zeigen sich Unterschiede in der Erstellung und der grafischen Darstellung der Ergebnisse. Neuere Tools bieten eine benutzerfreundlichere Diagramme-Erstellung und -Auswertung. Die Gestaltung der grafischen Benutzeroberflächen unterscheidet sich deutlich, wobei ältere Tools wie Gatling und JMeter durch stetige Weiterentwicklung ein moderneres Design aufweisen als Grinder.

Ein wichtiger Aspekt ist die unterschiedliche Unterstützung neuer Protokolle wie HTTP/2 und WebSockets. Gatling und JMeter unterstützen WebSockets, Grinder hingegen nicht. Keines der drei Frameworks unterstützt derzeit HTTP/2. Jedoch ist die Unterstützung dieser fehlenden Protokolle bei Gatling und JMeter in Planung. Die Arbeit zeigt, dass die Wahl des passenden Frameworks von den spezifischen Anforderungen des Projekts und den Präferenzen des Testers abhängt, insbesondere hinsichtlich der benötigten Protokoll-Unterstützung und der gewünschten Benutzerfreundlichkeit der Benutzeroberfläche.