kontakt

+49 421 20696 - 0
info@team-neusta.de

Ein Portal, ein Tor zum personalisierten Content – Teil 11

Performance Testing versus Stress Testing

Wenn man seine Portalanwendungen Performancetests unterwirft, bevor
diese in den produktiven Einsatz gehen, erfährt man an welcher Stelle man,
in der Zukunft mit Verbesserungen an Hard- und/oder Software rechnen
muss, beziehungsweise wo eventuell kritische Fehler verborgen liegen, die
man unbedingt vor dem Go-Live bereinigen sollte.

Bei Systemen, die bereits im produktiven Einsatz sind, gibt der
Performancetest zuverlässige Antworten auf Fragen zur Skalierbarkeit
unter Beibehaltung der aktuellen Infrastruktur. Er ermöglicht Überprüfungen
der Netzwerkkonfiguration und die Identifizierung von kleineren
Tuningmaßnahmen am Portal-Frontend oder dem Datenbankserver. Mit zum
Teil sehr positiven Effekten bei geringem Aufwand.

Um nochmal den Hauptunterschied zwischen Performancetests und Stresstests in Erinnerung zu rufen:

  • Performancetest – Simuliert die Verwendung der Portalanwendung unter Echtbedingungen. Er wird ausgeführt, um festzustellen, wie gut und reibungslos die unterschiedlichen Portalkomponenten unter den aktuellen Bedingungen zusammenarbeiten.
  • Stresstest – Wird ausgeführt, um festzustellen, wo genau der Punkt liegt, an dem das Portal in seiner aktuellen Konfiguration unbenutzbar wird. Eine hohe Last wird erzeugt, um alle Portalkomponenten bis ans Limit zu bringen.

Performancetest-­‐Methodologie

Diese beiden Testarten, Performancetest und Stresstest, sind die am
meisten verbreiteten Szenarien in Bezug auf Portaltechnologien, abgesehen
von speziellen Tests, die meistens als Konsequenz vorheriger Testreihen
separat gestartet werden.

Sollte zum Beispiel während eines Performancetests erkenntlich werden,
dass die Anzahl der Sessions abrupt einbricht, weil sich die CPU und RAM des
Datenbankservers auf 100% einpegeln, ist es dringend zu empfehlen,
weitere Performancetests im Hinblick auf den Datenbankserver zu planen.

Solche Tests lassen dann in der Regel das Portal-Frontend und die
Konnektoren komplett außer Acht und geben Aufschluss über den
Datendurchsatz bei repräsentativen Datenbanktasks.

Definition repräsentativer Businessprozesse

Die wesentlichen, zu erfassenden Werte und Variablen im Rahmen der Tests
haben wir gerade angerissen; die technischen Rahmenbedingungen wären
soweit klar. Um jedoch ein Portal auf Herz und Nieren überprüfen zu
können, sollte man sich mit dem Business zusammensetzen und für die
einzelnen Benutzerrollen repräsentative Business-Cases identifizieren und
schriftlich als Testszenario fixieren. Dabei sollte jeder Schritt fixiert und die
jeweils letzte manuelle Benutzerinteraktion vermerkt sein.

Ein solcher Business-Case sollte eine komplette, einfache Benutzersitzung
am Portal beinhalten und könnte in etwa so aussehen:

  • Anmeldung am Portal mit UserX / Passwort Y in der Rolle HR > klick auf LOGIN
  • Navigation in die HR Community > klick auf Button MyHR in der Menüleiste
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # im Portlet MyData
  • Im Feld „Persönliche Daten“, eigene Adresse ändern und Speichern > klick auf SAVE
  • Kontrolle ob Übernahme der Daten erfolgt ist > Klick auf „Profil“ links oben
  • Validierung, ob neue Daten in der Ansicht übernommen wurden, Logout > klick LOGOUT

Hier ein kleines Beispiel eines solchen Use-Cases:

Blog #1.4

Tipp: Unter Windows 7 und neuer bietet sich für die Dokumentation der
gesamten Schritte der Problem Screen Recorder (PSR.EXE) als nativer
Bestandteil jeder Windows-Installation an.

Er macht automatisch von  jeder Benutzerinteraktion eine Notiz und speichert diese zusammen mit einem Screenshot ab. Diese Datei kann später einfach in Word geöffnet und weiter bearbeitet werden.

Festlegung der maximalen Antwortzeiten

Der nächste Punkt, der unbedingt in Kooperation mit dem Business
angegangen werden sollte, nachdem die einzelnen repräsentativen
Testszenarien festgelegt und dokumentiert wurden, ist die Festlegung der
für die jeweilige Benutzerinteraktion maximal vertretbaren Antwortzeit des
Portals in Sekunden.

Naturgemäß wird dieser Punkt sehr schwierig zu erörtern sein, denn
meistens existieren durchaus auseinandergehende Meinungen über die
maximal vom Benutzer vertretbare Antwortzeit. Im Allgemeinen kann man
in Portalen aber relativ einfach zwischen diesen verschiedenen Ansichten
vermitteln und zu einem gemeinsamen Nenner kommen. Denn im Gegensatz
zur klassischen Webapplikation ist ja gerade der Vorteil eines Portals, dass
Inhalte selbst dann auf einer Portalseite dargestellt werden, auch wenn das
zugrundeliegende Quellsystem offline oder überlastet sein sollte. Portale
reagieren hier auf zwei verschiedene Arten und Weisen:

  • Möglichkeit A: Die im Portlet A integrierte Anwendung ist nicht erreichbar (Serverausfall). Die Portalengine erkennt den Fehler sofort, da der Konnektor einen entsprechenden Fehler zurückmeldet. Fast ohne merklichen Zeitverzug werden die letzten im Cache liegenden Werte im Portlet angezeigt, zusammen mit einer Fehlermeldung via Icon, dass die Daten aufgrund eines technischen Problems veraltet sind. Portlet A wird aber zusammen mit den anderen 5 Portlets korrekt auf der Startseite des Portals angezeigt.
  • Möglichkeit B: Die in Portlet A integrierte Anwendung ist unerreichbar (Serverausfall). Da es sich hier aber um Realtime-Aktienkurse handelt, erzeugt der Konnektor nach 3.000ms einen Timeout-Fehler. Die Portalengine schreibt daraufhin eine Fehlermeldung ins Portlet. Diese Meldung wird zusammen mit den anderen 5 Portlets auf der Startseite des Portals angezeigt.

Wie man erkennen kann, tritt bei der Möglichkeit B eine Verzögerung der
Antwort von mindestens 3 Sekunden, plus der benötigten Zeit für die
Übertragung der Inhalte, auf. Dieses Beispiel zeigt auch, dass die Verhandlung
über das Thema „vertretbare Antwortzeit in Sekunden“ durchaus auch von
der Art des anzuzeigenden Inhaltes, bzw. der Natur des Portals und der
Situation des Nutzers abhängig sein kann.

Vorhin haben wir bereits über die Studien berichtet, wonach die
überwiegende Mehrheit der Nutzer bei Antwortzeiten größer als 8
Sekunden den Fokus auf die Anwendung verlieren. Also sollte man
sinnigerweise die maximal vertretbare Antwortzeit im Idealfall irgendwo
zwischen 3 Sekunden und 8 Sekunden im denkbar schlechtesten Szenario
aushandeln und festschreiben.

In der Realität sieht das Ganze dann so aus, dass man für „einfache“ Tasks,
wie z.B. der Authentifizierung, in der Regel weniger Zeit einräumt als zum
Beispiel für den Aufruf von Portalseiten mit Daten aus verschiedenen
Quellen in einem Formular im Bearbeitungsmodus. Wer schon mal mit
mächtigen Anwendungen wie SAP gearbeitet hat – sogar in einer schnellen
WAN-Umgebung – hat sicherlich schon ein Gefühl dafür entwickelt.

Natürlich sollten die maximalen Antwortzeiten (Tmax) im Portalkontext für
jede einzelne Aktion auch nicht viel kürzer sein, als die durchschnittlichen
Antwortzeiten für die identische Aktion in der originären Anwendung ohne
Verwendung der Portalintegration.

Wir erhalten also nun in etwa folgendes Beispiel:

  • Anmeldung am Portal mit UserX / Passwort … > klick auf LOGIN > (Tmax=5 Sekunden)
  • Navigation in die HR Community > klick auf Button … > (Tmax =5 Sekunden)
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … > (Tmax =8 Sekunden)
  • Im Feld „Persönliche Daten“ eigene Adresse ändern und Speichern > klick auf SAVE… > (Tmax =3 Sekunden)
  • Kontrolle, ob Übernahme der Daten erfolgt ist > Klick auf „Profil“ … > (Tmax =3 Sekunden)
  • Validierung, ob neue Daten in der Ansicht übernommen wurden, Logout > klick LOGOUT… > (Tmax =5 Sekunden)

Dies bedeutet also, dass man als erstes Arbeitsergebnis mit den Business-
oder den Applikationsverantwortlichen, von der in das Portal eingebundenen
Anwendung, ein detailliertes Skript über einen repräsentativen Business-
Case mit den verschiedenen Benutzeraktionen und den jeweiligen maximal
akzeptablen Antwortzeiten erhält.

Fortsetzung in Teil 12:

Im nächsten Teil geht es um APDEX – Der Application Performance Index.

Lesen Sie hier ab dem 06.11 den Teil 12

Share

Kommentare