computerwoche.de

Software-Infrastruktur

Rich Internet Applications (RIA)

Tipps für Last- und Stresstests von Web-2.0-Anwendungen

15.06.2009
Von Stéphane Jammet
Stéphane Jammet von Neotys hat uns ein paar Tipps zum Testen von Web-Applikationen zukommen lassen. "Last- und Stresstests stellen sicher, dass das große wirtschaftliche Potenzial des Web 2.0 auch wirklich ausgeschöpft wird", sagt der VP Sales and Marketing.

1. Nutzen und Bedeutung moderner Web 2.0 -Technologien

Rich Internet Applikationen (RIAs), vor allem AMF-Protokolle sowie Java-, Ajax- und XML-basierende Anwendungen, prägen das heutige Inter- wie Intranet. Web-2.0-Technologien wie Flash-Animationen und Video-Streams sind unternehmenskritische Erfolgsfaktoren bei Marketing, Kommunikation und Imagepflege.

Auf technologischer Ebene zeichnen sich RIAs durch die Verlagerung von Datenverarbeitungsprozessen vom Server auf den Client aus. Vor allem Browser-Applikationen (AJAX, Google GWT) und Plug-in-Anwendungen (Adobe Flex, Oracle Forms, Microsoft Silverlight) ermöglichen eine zügige Reaktion auf Benutzereingaben und machen weniger HTTP-Anfragen an den Server erforderlich.

2. Probleme mit den modernen Web 2.0-Technologien

Die innovative RIA-Technologie hat die gesamte Architektur von Webserver, CGI, Programmen und persistenten Daten beziehungsweise RDBMS (Datenbank) grundlegend verändert und damit für den Software-Entwickler problematisch werden lassen. Häufig fehlt die Erfahrung, AJAX- oder X(A)ML-Applikationen so in eine Website oder IT-Umgebung zu integrieren, dass Hochverfügbarkeit auch bei starkem Traffic oder erhöhten Zugriffsraten sichergestellt ist.

Weitere Probleme ergeben sich aus dem Mashup-Verfahren: Die kreativen Potenziale der RIAs führen meist zu unübersichtlichen IT-Landschaften und beeinträchtigen die Performance, wenn das Verhalten der Web-Applikationen in Echteinsatz und Produktivbetrieb nicht eingehend überprüft wird.

Um die Vorteile von Ajax, Silverlight und X(A)ML-Technologien tatsächlich nutzen zu können, sollten RIAs methodisch getestet werden, ob sie unter unterschiedlichen Last-Bedingungen stabil funktionieren. Vor dem Hintergrund, dass 40 Prozent der Unternehmensapplikationen gegenwärtig bereits browserbasierend arbeiten, ist es unerlässlich, neben funktional orientierten Integrations- auch Lasttests mit simuliertem Traffic durchzuführen.

3. Ökonomische Entscheidungsgründe für die Wahl einer Lasttest-Lösung

Ein Verzicht auf solche Testläufe kann sich für Unternehmen in ihren Beziehungen zu Kunden und Öffentlichkeit oder auch auf interne Wertschöpfungsprozesse nachteilig auswirken. Eine einfache Rechnung: Im Unternehmens-Intranet können Anwendungen mit unzureichender Performance Workflow und Produktionsabläufe empfindlich behindern.

Wenn ein Büro mit 150 Mitarbeitern und Personalkosten von 600.000 Euro im Monat, also 3.750 Euro in der Stunde, pro Tag nur zwölf Minuten durch instabile Anwendungen verliert, dann ergibt sich eine Negativbilanz von 180.000 Euro im Jahr. Drohen Produktionsausfälle oder sind terminkritische Informationstransfers in Gefahr, liegt der punktuell oder auch schleichend eintretende Schaden deutlich höher und ist häufig kaum zu beziffern.

In Load- und Stress-Testzyklen lassen sich solche Friktionen rechtzeitig entdecken und vermeiden. Damit tragen sie wesentlich zu umfassendem BPO-Management bei.Für den Projektmanager oder IT-Administrator bis hin zum CIO sind auftretende Verfügbarkeitsprobleme bei Applikationen unangenehm. Sie bedeuten nachträgliche Mehrarbeit und Ansehensverlust. Der Verzicht auf Lasttests führt zudem dazu, dass Hardware, die bei lastoptimierter IT überflüssig wäre, teuer angemietet oder angeschafft und kostenintensiv klimatisiert, stromversorgt sowie gewartet wird.

4. Load- und Stress-Testings - aber wie?

Am Anfang eines Testverfahrens sollten Umfang, Zielstellung und Performance-Benchmarks klar definiert werden - etwa: Welche Maximallast ist zu erwarten? Soll lediglich eine Applikation oder die gesamte Infrastruktur getestet werden? Stehen Stabilität des Systems oder die Antwortzeit einer Applikation im Mittelpunkt des Interesses? Was bedeutet "gute" Performance? Welche Investition an Zeit und Geld ist welcher Steigerung der Systemleistung angemessen? Im Vorhinein ist insbesondere zu definieren,

  • welche durchschnittliche Antwortzeit pro Anfrage für eine bestimmte Webpage oder Anwendung als akzeptabel, 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, und

  • welche Fehlerrate für bestimmte Applikationen und zu bestimmten Stoßzeiten hinnehmbar, welche dagegen für den Workflow im unternehmenseigenen Intranet oder für eine bestimmte Konversionsrate im E-Commerce inakzeptabel ist.

Ein typisches Testszenario könnte dann so aussehen: Zunächst werden die erwartete Normal-, Spitzen- und Überlast festgelegt, dann die Dauer der jeweiligen Testzyklen. Ebenfalls wichtig: Der "ideale Klickpfad" eines Users und mögliche Abweichungen davon. Fragen, die der Test dann zu klären hat, sind:

  • Wie viele Nutzeranfragen kann der Server gleichzeitig weiterleiten?

  • Ist das Verhältnis Reaktionszeit-Serverlast den Anforderungen angemessen?

  • 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 erforderlich wird?

  • Ab welcher Lastgrenze beginnt der Server, Fehlermeldungen oder Timeouts zu produzieren?

Für ein aussagekräftiges Testverfahren sollte nicht nur die Zahl der virtuellen Nutzer dem erwarteten Aufkommen entsprechen, sondern auch das wahrscheinliche User-Verhalten berücksichtigt werden. Wichtig ist auch die Zeit, die im Durchschnitt zwischen den einzelnen Anfragen vergeht.

Darüber hinaus empfiehlt es sich, für das Testverfahren verschiedene Nutzer- und Nutzungsprofile zu verwenden: Hierbei werden zum Beispiel die Wahl des Browsers, die unterschiedlichen 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 herangezogen. Bei der Testauswertung ist neben den Antwortzeiten auch die CPU- und Speicher-Auslastung des Servers wichtiges Indiz für die Stabilität eines Systems.

Entscheidend ist es, eine Test-Sequenz nicht unmittelbar im Kaltstart von "null auf hundert" zu beginnen. Ein solches Szenario ist nicht nur unrealistisch, es kann auch zu Crashes führen, die nichts über die tatsächliche Anfälligkeit der IT-Infrastruktur aussagen. Im Rahmen einer ""Start-up Policy" sollten Server und System aufgewärmt werden, damit die zur Verfügung stehenden Verbindungen und Ausführungsstränge durch korrekt aufgebaute Zuteilungen in ihren vollen Potenzialen zur Verfügung stehen. Testläufe sollten generell über eine längere Zeitspanne hinweg vorgenommen werden, damit "Ausreißer" und zufällige Abweichungen nicht als Regel fehlinterpretiert werden.