Last- und Stresstests: grundsätzliche Erwägungen und Tipps für den Einsatz

Inhaltsverzeichnis

Was der Automobilentwickler an seinen Dummies testet, würde er sicherlich keiner lebenden Personen zumuten. Ähnliches gilt für die Entwicklung und Implementierung von Webanwendungen: Bevor echte Nutzer mit ihnen hantieren, testen virtuelle User die Applikationen mit künstlichen Anfragen auf ihr Verhalten. Im Rahmen solcher Last- und Stresstests führt man das System an seine Grenzen – und darüber hinaus.

Wenn Denial-of-Service-Meldungen sich häufen oder Applikationen lange Antwortzeiten haben, sind die Ursachen oft schnell, manchmal zu schnell identifiziert: Entweder liegt es am WAN – beispielsweise an zu geringer Bandbreite –, an unzureichenden Hardwarekapazitäten oder daran, dass das System an irgendeiner Stelle nicht richtig aufgesetzt ist. Die Reaktion ist zumeist, neue Hardware anzuschaffen, mehr Bandbreite einzukaufen oder Software-Funktionstests zu beginnen. Ob das den Erfolg bringt, ist nicht sicher. Sicher ist, es kostet Geld und Zeit.

Mehr Klarheit schaffen an der Stelle Last- und Stresstests: Von vielen großen Unternehmen bereits eingesetzt, aber teilweise noch unterschätzt, erweisen sie sich als ein wertvolles Diagnosewerkzeug: Simulierte Zugriffe auf Anwendungen und Datenbankserver sowie skalierbare Traffic-Szenarien geben Auskunft darüber, was bei der Verarbeitung von Client-Anfragen genau auf den Servern passiert – oder nicht. Künstlich erstellte ("virtuelle") User prüfen das System auf Herz und Nieren, damit realen Nutzern alle Applikationen zur Verfügung stehen. Ein Verzicht auf solche Testläufe kann sich für Unternehmen in ihren Beziehungen zu Kunden und zur Öffentlichkeit oder auch auf interne Wertschöpfungsprozesse nachteilig auswirken.

Eine einfache Rechnung mag das verdeutlichen: Im Unternehmens-Intranet können Anwendungen mit unzureichender Performance Workflow und Produktionsabläufe empfindlich behindern. Wenn in einem Bürokomplex mit 150 Mitarbeitern Personalkosten von 600.000 Euro im Monat auflaufen, sind das bei 37,5 Stunden Wochenarbeitszeit 4000 Euro in der Stunde oder 66,67 Euro in der Minute. Selbst wenn das Unternehmen pro Tag nur sieben Minuten durch Wartezeit und instabile Anwendungen verliert, ergibt sich ein täglicher Verlust von 466,69 Euro. Das sind 2333,45 Euro pro Woche, schon 9333,80 Euro im Monat und im Jahr über 112.000 Euro.

Drohen Produktionsausfälle, stornierte Bestellungen im E-Shop oder sind terminkritische Informationstransfers in Gefahr, liegt der punktuell oder auch schleichend eintretende Schaden deutlich höher und ist häufig kaum zu beziffern. Zumal es bei einem System, das seine Lastgrenze viel schneller erreicht als angenommen, nicht nur zu langsamen Reaktionszeiten kommen kann, sondern auch zu falschen Antworten vom Datenbankserver, sodass die Integrität der Daten auf dem Spiel steht.

In Load- und Stresstestzyklen lassen sich solche Friktionen rechtzeitig entdecken und vermeiden. Damit tragen sie wesentlich zur Sicherung von Wertschöpfungs- und Prozessketten bei. Hinzu kommt: Für die in die Anwendungsabwicklung Beteiligten sind die Verfügbarkeitsprobleme gerade bei neu implementierten Applikationen unangenehm. Sie bedeuten nachträgliche Mehrarbeit und Ansehensverlust, da sie sich durch vorgelagerte Testläufe hätten vermeiden lassen. Der Verzicht auf Lasttests führt dann häufig dazu, dass Unternehmen Hardware, die bei lastoptimierter IT überflüssig wäre, teuer anmieten oder anschaffen und kostenintensiv klimatisieren, mit Strom versorgen sowie warten müssen.

Der richtige Moment

Nicht selten werden Last- und Stresstests erst durchgeführt, wenn Probleme entstehen und sich etwa durch eine Bandbreitenerhöhung und andere Netzoptimierungen nicht beheben lassen. Lastsimulationen sind sicherlich als Notfall-Instrumente geeignet, da sich mit ihnen der Alltagsbetrieb nachstellen und die Abläufe auf den verschiedenen Serverebenen darstellen lassen. Unter "klinischen", also unverfälschten Bedingungen kann man wie in einem Experiment potenzielle Fehlerquellen nach und nach finden, eingrenzen und ausschließen.

Besser ist es allerdings, solche Testszenarien gleich in der Entwicklungs- und Implementierungsphase direkt nach den Funktionstests aufzusetzen. Idealerweise sollte man jeden einzelnen Entwicklungsschritt auf sein Verhalten im simulierten Betrieb analysieren. Es handelt sich um ein Testen vom Einfachen zum Zusammengesetzten, was immer praktikabler ist, als über die Jahre zumeist kompliziert gewordene Systeme mühevoll auseinanderzunehmen, um sie schließlich systematisch testen zu können. Ein kontinuierliches Testen parallel zum Echtbetrieb ist ein probates Mittel der Gefahrenprävention, zumal wenn zu erwarten ist, dass neue Funktionen und Techniken eingeführt oder steigende Zugriffszahlen erwartet werden.

Die hohe Schule

Der geeignete Weg ist in dem Zusammenhang das sogenannte Sandboxing, das aus der IT-Sicherheit bekannt ist und bei dem ein System im Produktivbetrieb im kleineren Maßstab eins zu eins nachgestellt wird. Die vom Lasttesttool künstlich generierten Anwender treffen mit ihren Profilen (zum Beispiel Klickverhalten oder Zugangsberechtigung) auf eine reine Laborumgebung, in der sich ohne Störung des parallelen Echtbetriebs Systemerweiterungen, Worst-Case-Szenarien oder die Notfallbehandlung durchspielen lassen. Für kleine und mittelgroße Unternehmen reicht es aber auch, das System zu testen, wenn sie es nicht benötigen, also ein Intranet etwa an Brückentagen, Wochenenden, in den Werksferien oder Abendstunden. In jedem Fall sind beim Lasttest Interferenzen mit dem Echtbetrieb zu vermeiden, einerseits, um Ergebnisse nicht zu verfälschen, andererseits, um die Verfügbarkeit der Anwendungen oder Datenbanken für die echten Nutzer nicht zu verringern. Ein System, das Anwender ohnehin mit Timeouts auf die Geduldsprobe stellt, sollte man nicht durch künstlich generierte Anfragen weiter verlangsamen.