StormForger ist eine Load Testing as a Service platform, die auf HTTP-APIs abzielt (HTTP API Performance). Über eine verständliche und ausdrucksstarke JavaScript DSL (Domain Specific Language = Modellierungssprache für Softwaresysteme, domänenspezifische Sprache) zum spezifizieren von Testfällen und einen hohen Grad an Automatisierung ermöglicht StormForger kontinuierliche Lasttests.
HTTP-basierte APIs (Application Programming Interface = Programmierschnittstellen) findet man z.B. bei
- APIs von Web Applikationen (api load testing)
- Backend von Mobilen Anwendungen (Smartphone Apps) und Online Spielen
- Tracking & Monitoring Systemen
- Online Shops und E-Commerce Plattformen (Ecommerce Load Testing)
Applikationen mit Programmierschnittstellen können bisweilen sehr komplexe Systeme mit umfangreichen Software Stapeln sein, deren Verhalten und Performance im Dauerbetrieb oder unter Last schwer vorhersagbar ist, insbesondere bei Cloud-basierten Systemen, für die StromForger Cloud Load Testing bietet.
Während es für die Programmierer meist gute Test Suiten gibt um funktionale Anforderungen schon während der Entwicklung zu prüfen und Fehler zu eliminieren, bleiben doch einige grundsätzliche Fragen offen und zeigen sich sonst erst im realen Betrieb:
- Wie schnell ist das Gesamtsystem?
- Wie viele Anfragen kann die Architektur bewältigen?
- Skaliert die Anwendung?
- Ab welcher Last ist eine zufriedenstellende Funktionalität nicht mehr zu gewährleisten, bzw. bricht das System gar zusammen?
Lasttests (load testing) sind eine Methode, schon vor dem Live Betrieb Antworten auf solche Fragen zu geben, bzw. bei Problemen im Live Betrieb Schwachpunkte in der Performance der Gesamtarchitektur aufzuzeigen.
Stark vereinfacht ausgedrückt bietet StormForger die Möglichkeit, eine wohldefinierte und doch beliebig Große) Last in Form von Anfragen oder Traffic auf das Zielsystem auszuüben, während das Verhalten des Zielsystems überwacht und analysiert werden kann.
Mögliche zu messende Werte beinhalten etwa die Antwortzeit eines Software Systems, der Ressourcenverbrauch (CPU, RAM, HD) oder die Fehlerraten eines Systems unter Last. Dies kann im Vorfeld Aufschlüsse darüber geben, wie ein Gesamtsystem zu dimensionieren oder anzupassen ist.
Ein Lasttest (Load Test) oder Stresstest eines Zielsystems erfordert eine gewisse Vorbereitung und Planung.
- Ziele des Tests müssen definiert werden und die Lasttests selber geplant werden
- Die Ressourcen für den Lasttest müssen bereitgestellt (provisioniert) werden
- Die Testfälle müssen aufgesetzt, ggf. installiert und ausgeführt werden
- Die Load Tests müssen durchgeführt und überwacht werden
- Das Test Szenario muss wieder rückgebaut werden
- Die im Lasttest erfassten Daten (Logs und sonstige Sensor Daten) müssen gesammelt und analysiert werden
- Vergleichen der Testergebnisse mit vorherigen Lasttests und ggf. Evaluieren und erneutes Überprüfen geeigneter Verbesserungen.
Lasttests können somit eine zeitaufwändige und anspruchsvolle Teilaufgabe beim Aufsetzen eines Software Systems sein. Da die Performance eines Gesamtsystems aber geschäftskritisch sein kann, sollten Lasttests eigentlich ein fester Bestandteil während der Gesamtlaufzeit eines Systems sein und einen gleichen Stellenwert wie etwa Continuous Integration haben (continuous load testing).
Zu diesem Zweck bietet StormForger:
Expressive Javascript DSL
Mit der JavaScript DSL Modellierungssprache können wiederholbare performance & load tests erstellt werden.
StormForger ist Cloud-basiert & Skalierbar
StormForger nutzt die größten Cloud Anbieter um die erforderliche Last für die Stresstests zu erzeugen (Cloud Load Testing) in nahezu beliebiger Größenordnung von bis zu hunderttausenden Requests pro Sekunde (distributed load testing)
Ausführliches Reporting & Analyse
Jede noch so kleine Information wird während der Lasttests gesammelt und in einem ausführlichen Bericht aufbereitet.
StormForger Dokumentation
Die StormForger Dokumentation bietet ausführliche Beschreibung verschiedener Test Szenarien und Use Cases. Unter anderem zu:
Stress Testing
Auch bekannt als capacity testing. Wird üblicherweise eingesetzt um die Grenzen und Gesamtkapazität eines Systems unter schwerer Last zu ermitteln. Typischerweise wird ein worst case scenario aufgesetzt und die Last soweit erhöht, bis das System zusammenbricht, oder elementare Grundanforderungen an das System nicht mehr gewährleistet werden können.
Spike Testing
wird eingesetzt um Lastspitzen zu simulieren. Etwa ein Ereignis mit hohem Traffic wie etwa die Reaktion auf einen Newsletter. In diesem Szenario wird die Last für eine kurze Zeit stark erhöht und überprüft, wie das Gesamtsystem darauf reagiert.
Soak Testing
wird eingesetzt um die Systemstabilität und Performance über einen langen Zeitraum zu testen.
Ziel ist es, die System Performance über einen langen Zeitraum bei kontinuierlicher Last zu gewährleisten und Langzeitfehler wie etwa Datenlecks (Memory Leaks) zu finden oder den Ressourcenverbrauch zu überprüfen (insbesondere database resource utilisation)
OAauth Testing
zum Testen von Services, die OAuth 2 Authorisierung und Authentifizierung einsetzen
CSRF Tokens
Viele Seiten setzen CSRF tokens zur Authorisierung ein um cross-site request forgery (kurz CSRF oder XSRF, etwa Website-übergreifende Anfragenfälschung) vorzubeugen.
Kostenlos Ausprobieren
Interessiert Anwender können die StormForger Load Testing as a Service Platform kostenlos ausprobieren unter
https://app.stormforger.com/users/sign_up
Informationen zu professionellen Subscription Plans bis hin zu großen Teams in agilen und CI/CD Umgebungen findet man unter:
https://stormforger.com/pricing/
Beispiele für Lasttests
Eine gewisse Berühmtheit erlangte StormForger durch einen Lasttest nach Pannen bei der Sendung „Quizduell im Ersten“ wo die eingesetzte App während des Live Betriebs der Erstausstrahlung zusammengebrochen war.
Das Quizduell (eine Adaption von der Quizduell App) mit Jörg Pilawa startete mit technischen Pannen und es folgte stundenlange Häme auf Twitter und Facebook. Die Online-Ausgaben diverser Medien berichteten teilweise noch während des Geschehens.
WAS WAR GESCHEHEN?
Jörg Pilawa sagte während der Sendung, dass die Server überlastet seien und später, dass ein einzelner User über 15.000 Server blockieren würde. Andere Medien (Welt, Focus, Süddeutsche, Süddeutsche, Spiegel) berichteten sofort über einen Hackerangriff, wovon allerdings in der Pressemeldung vom NDR später am gleichen Abend nichts mehr zu lesen ist. Auch auf Twitter wurde schlicht ein Softwarefehler und/oder der Benutzeransturm als Vermutung propagiert.
Das am Premierenabend aufgetretenen Problem, verursachte bereits ca. fünf Minuten nach Sendungsbeginn eine automatische Skalierung auf 15.000 Instanzen und zum Sendungsende hin sogar auf 25.000 Instanzen.
Es handelte sich also nicht um 15.000 physikalische Server, sondern um Runtime Hosts innerhalb virtueller Maschinen.
Durch den Einsatz von StormForger load testing as a service konnten die Schwachstellen schon bis zur nächsten Sendung behoben und ein stabiler Betrieb des Gesamtsystems gewährleistet werden.
Kontakt
STORMFORGER GMBH
Hochstadenstr. 1-3
50674 Cologne
Germany
Phone: +49 221 64 30 51 28
E-mail: support@stormforger.com
Web: https://stormforger.com
FOLLOW:
https://twitter.com/StormForgerApp
https://github.com/stormforger
https://www.facebook.com/stormforgerapp
https://www.google.com/+stormforger
https://www.linkedin.com/company/stormforger-gmbh