Seite 2: Vorbereitung & Start

Inhaltsverzeichnis

Vorbereiten und starten

Zeitgemäße Produkte stellen IT-Administratoren und Softwareentwickler hinsichtlich der rein technischen und administrativen Aspekt kaum kaum vor Probleme. Meist lassen sich per Mausklick virtuelle User über eine gelenkte Menüführung mit Zugangsrechten und Klickpfaden definieren. Scripting ist nicht erforderlich, weshalb sich die Anwender nicht mit Codezeilen aufhalten müssen. Sollten etwa für künstlich generierte Serveranfragen – beispielsweise bei Web-2.0-Anwendungen auf Basis von Adobes Flex – andere Protokolle als HTTP benötigt werden, stehen hier seitens der Anbieter spezifische Module zur Verfügung. Wichtig sind bestimmte Vorarbeiten, die der Nutzer leisten sollte, damit die Tests ihn mit validen Daten bei Fehlerbehebung und -prävention tatsächlich unterstützen.

Vor dem Start des Lasttests sollten die Beteiligten die aufgetretenen Fehler genau beschreiben und dokumentieren. Um nicht "aufs Geratewohl" zu testen, ist es wichtig, den Befund zu analysieren, Hypothesen über denkbare Ursachen für den jeweiligen Flaschenhals zu bilden und die Hypothesen gezielt zu überprüfen. Darüber hinaus kann es hilfreich sein, den eigenen Server zunächst gründlich kennen zu lernen, zum Beispiel anhand folgender Fragestellungen:

• Wie viele der normalerweise auftretenden Nutzeranfragen kann der Server gleichzeitig weiterleiten?
• Wie lange braucht der Server, um nach Traffic-Spitzen wieder zu seiner durchschnittlichen Performance zurückzufinden? Oder wird das System derart beeinträchtigt, dass ein Neustart durchzuführen ist?
• Ab welcher Lastgrenze beginnt der Server, Fehlermeldungen oder Timeouts zu produzieren?

Zur Implementierung effektiver Testzyklen sollten vor allem die User, ihre Nutzungsgewohnheiten und
Zugriffsrechte genau bekannt sein. Website-Analysewerkzeuge helfen dabei, Auslastungsstatistiken sowie Nutzerprofile für realitätsnahe Lastsimulationen zu gewinnen und typische Klickpfade zu ermitteln. Bei Lasttests sollte man allerdings nicht nur den idealen Klickpfad, der Nutzern im Webshop nahegelegt wird, einkalkulieren, sondern auch typische Abweichungen davon.

Zwei Beispiele zeigen den Nutzen von Website-Analysen im Testvorfeld: Gibt es auf einem Webportal einen Mix aus registrierten und nicht registrierten Nutzern, ist es erforderlich, das Verhältnis mit den "künstlichen" Nutzern und ihren Serveranfragen im Rahmen der Lasttests möglichst präzise nachzubilden. Dazu muss das Verhältnis beider Nutzergruppen bekannt sein. Oder es ergibt sich für einen Webshop, dass auffällig viele Nutzer kurz vor der Konversionshandlung den Kauf- oder Bestellvorgang abbrechen, dann lässt sich mit Website-Analysen im Vorhinein klären, ob eher eine unklare Menüführung oder gar Fehler im Cookie-Management oder eine schleppende Systemantwort die Ursache ist.

Liegt der Fehler bei den Servern und Anwendungen, empfiehlt es sich, für das Testverfahren unterschiedliche Nutzer- und Nutzungsprofile zu verwenden: Beispielsweise lässt sich die Wahl des Browsers, gestufte Zugangsrechte (Gast, registrierter Nutzer oder Systemadministrator), der jeweilige Benutzerstatus (Datenbankzugang, Up- und Download-Freigaben) oder spezifische User-Gewohnheiten wie das gleichzeitige Öffnen mehrerer Applikationen als relevante Faktoren heranziehen. Lastsimulationen sollten dann die Zeit, die im Durchschnitt zwischen den einzelnen Anfragen vergeht, authentisch nachbilden. Website-Analysen geben gleichzeitig Auskunft darüber, wie lange Nutzer durchschnittlich auf Antworten zu warten bereit sind. Das ist wiederum relevant bei der Definition der Lasttestparameter.

Benchmarks und KPIs definieren

Am Anfang eines Testverfahrens sind Umfang, Zielstellung und Performance-Benchmarks sauber zu definieren, am besten auch zu quantifizieren – etwa: Welche Maximallast soll noch stabil bewältigt werden? Was bedeutet "stabile" Performance? Allein auf die Frage, was eine "gute" Reaktionszeit ist, gibt es unterschiedliche Antworten wie:

• "Bleibt bei langsam steigender Anfragelast konstant";
• "Bleibt bei plötzlichen Traffic-Peaks konstant";
• "Steigt nie über einen als geschäftskritisch angesehenen Wert";
• "Wird subjektiv von Nutzern als flüssig empfunden";
• "Wenn sie bei steigender Last langsamer wird, erholt sie sich schnell wieder beim Rückgang auf das Normalniveau".

Wichtig für den Erfolg von Lasttestzyklen sind ihre Einbindung in ökonomische Fragen und ein enger Austausch von IT und Unternehmensführung. Denn nur so lässt sich auch die wichtige Frage klären, welche Investition an Zeit und Geld welcher Steigerung der Systemleistung angemessen ist. Das setzt voraus, über eine KPI-Analyse (Key Performance Indicator) festzulegen, welche Antwortzeiten nicht zu überschreiten sind und welche Relation zwischen Geschäftserfolg und Verfügbarkeit bestimmter Applikationen besteht. Zum Beispiel ist festzulegen,

• welche durchschnittliche Antwortzeit pro Anfrage für eine bestimmte Webseite oder Anwendung als akzeptabel gilt, welche als erwünscht angestrebt wird;
• was als die maximale Antwortzeit gilt, die man nach bisherigen Statistiken Nutzern wie potenziellen Kunden noch zumuten kann, ohne ein vorzeitiges Verlassen einer Website zu provozieren;
• welche Fehlerrate für bestimmte Applikationen zu Stoßzeiten hinnehmbar, welche dagegen für den Workflow im unternehmenseigenen Intranet oder für eine angestrebte Konversionsrate im E-Commerce inakzeptabel ist.

Ob sich die Benchmarks erreichen lassen, ermitteln wechselnde Testmethoden und unterschiedlich geartete Testtiefen am besten systematisch.

Typische Testläufe und Wahl der Testtiefen zu Beginn empfehlen sich realitätsnahe Szenarien. Sie erlauben eine erste Hypothesenbildung über mögliche Schwächen und Fehler. Mit ihnen lässt sich das Verfahren in der Regel auch abschließen. Sie sind die Generalprobe vor der Liveschaltung oder der Wiederherstellung des Produktivbetriebs. Dazwischen stehen weitere Testvarianten zur Verfügung:

1. Kontinuierliche Steigerung der Last: Es lässt sich beobachten, wie die Performance sich allmählich oder ab einer bestimmten Grenze plötzlich verschlechtert. Der Testtyp eröffnet es, das System über die gesamte Lastskala hinweg zu beobachten und sein Verhalten zu ermitteln. Die Grenze, ab wann Fehler in einer bestimmten Intensität auftreten, liefert wichtige Informationen zur Fehlerdiagnose.
2. Plötzliche Steigerung der Last: Der Testansatz simuliert bei Webshops zum Beispiel den Launch eines Produkts oder den Startschuss zu einer Sonderaktion. Darüber hinaus lassen sich damit Rückschlüsse darauf ziehen, was passiert, wenn ein Server oder der Load Balancer ausfällt. In dem Fall sind Lasttests Teil der Risikoprävention.
3. Maximal- und Stresstests: Mit ihnen lässt sich das System ausmessen. Sie ermitteln aber vor allem, was im Stressbereich eines Systems passiert: Wird es nur langsamer, oder liefert es fehlerhafte Ergebnisse zurück? Normalisiert es sich beim Rückgang der Last, oder sind die Server neu zu starten? – Fragen, die vor allem die Risikobehandlung und Gefahrenminimierung betreffen.
4. Wechselnde Last: Für bestimmte Umgebungen, etwa im Unternehmensintranet, entsprechen solche Szenarien der Realität. Es gibt Zugriffs-Peaks, beispielsweise morgens, mittags und gegen Büroschluss, und Zeiten mit relativ wenig Traffic. Die Erfahrung zeigt, dass Systeme ohne effektive Speicherbereinigung hier anfällig sein können: Sie erholen sich von einer kurzzeitig erreichten hundertprozentigen Speicherauslastung nicht mehr und sind dann neu zu starten.
5. Dauertest: Der Dauertest ist ein Verfahren, um ein im Prinzip funktionierendes System auf Optimierungspotenziale abzuklopfen oder latente Schwachstellen schon im Ansatz zu erkennen. Vor allem hinsichtlich von Systemerweiterungen ist es nützlich, abschätzen zu können, welche Reserven das System hat und wie es auf Updates reagiert. Gleichzeitig profitieren Unternehmen von der detaillierten Bestandsaufnahme ihrer Systeme: Investitionsplanungen im Hinblick auf neue Services, erweiterte Zugriffsrechte oder die Integration als innovativ geltender Web-2.0-Techniken sind dadurch zielgenauer umzusetzen.

Die unterschiedlichen Testverfahren sollten vor allem drei Testtiefen umfassen. Die erste Ebene ist die der Anwendungen. Aber nicht weniger wichtig ist die Datenbankebene und ihr Zusammenspiel mit dem Applikationsserver, zumal heutige Websites so aufgebaut sind, dass die Anwendungs- und Datenbankschicht getrennt sind. Es ist eine Eigenart des in seinen Inhalten dynamischen Web 2.0, dass sich das gesamte Zusammenspiel von Client, Applikationsserver und Datenbankebene geändert hat: Die Darstellungsschicht (Single Page Interface) ist komplett auf den Client ausgelagert, sodass zum Beispiel nur Businessdaten über Webservices eingespielt werden, was zu einem signifikanten Anstieg permanenter Netzanfragen führt.

Webservices und Schnittstellen müssen bei Lasttests ebenso Gegenstand der Untersuchung sein wie auf einer dritten Ebene die spezifische Hardware-Performance: Insbesondere die CPU- und Speicherauslastung des Servers sind wichtige Indikatoren für die Stabilität eines Systems. Ebenfalls in die Analysen einzubeziehen sind Webserver, Portalserver sowie das Betriebssystem.