kontakt

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

Ein Portal, ein Tor zum personalisierten Content – Teil 10

Performanceüberwachung

Während der Testausführung sollten stets die wichtigsten Parameter der
involvierten Systeme überwacht und in Logfiles geschrieben werden. Dazu
gehören z.B. die Speicherauslastung, Schreibzugriffe und die prozentuale
CPU-Last jedes beteiligten Systems, im Besonderen auch der
Datenbankserver.

Diese Logdateien enthalten wichtige Informationen zur Beurteilung der
Performancetests. Jedes Mal wenn ein Benutzer sich an der Portalengine
authentifiziert werden so Events und Details dieses Besuchs in die
Systemlogs geschrieben, sofern die Logging-Option serverseitig aktiv ist.

Ergebnisanalyse

Der letzte und sicherlich wichtigste Schritt bei Performancetests ist das
Sammeln und die Bearbeitung der Informationen um Leistungslöcher zu
identifizieren. Reports können zum Beispiel die Anzahl von Hits pro
Sekunde, die Anzahl der virtuellen Nutzersitzungen, die Anzahl der
Requests pro Sekunde, Socket Errors und vieles weitere mehr enthalten.

Die genaue Analyse dieser Ergebnisse wird die Bottlenecks zeigen und erste
Rückschlüsse auf die durchzuführenden korrektiven Aktionen erlauben, um
die Performance des Portalsystems zu verbessern.

Clienteinstellungen

Verschiedene clientseitige Plattformen wie zum Beispiel PCs, Mobilgeräte
und verschiedene Browsertypen erzeugen immer auch verschiedenen
HTTP-Verkehr. Ein älterer Browser, der beispielsweise aus Sicherheitsgründen
Cookies strikt ablehnt kann auf dem Portal-Backend deutlich mehr
Last verursachen, da die Portalengine zu einem Session-Management ohne
Cookies gezwungen wird.

Wenn zum Beispiel Verschlüsselung von sicherem Content erzwungen wird,
wie bei der Login-Seite, erzeugt dies deutlich mehr Netzwerk-Traffic, CPU
last und kostet mehr Bandbreite.

Zugriffsgeschwindigkeit

Die Übertragungsgeschwindigkeit in Richtung Client kann ebenfalls einen
gewissen Effekt auf die Gesamtleistung des Portalsystems haben.

Zwar kann mittlerweile dieser Punkt zunehmend in Zeiten von mobilen 3G
und 4G/LTE-Verbindungen vernachlässigt werden, gänzlich ignorieren sollte
man diesen Punkt allerdings nicht.

Hintergrundrauschen

Der nett umschreibende Begriff „Hintergrundrauschen“ bezieht sich nicht,
wie man etwa annehmen könnte, auf die Leitungsqualität sondern auf
parallel im Hintergrund ausgeführte Systemtasks des Portal-Backends.
Dies können zum Beispiel automatisch durch Scheduler gestartete Content-
Indizierungen der Suchmaschine, Datensicherungen oder durch Trigger
automatisch durchgeführte Datenbankoptimierungen sein.

Geographische Benutzerverteilung

Gerade bei zum Internet hin geöffneten Portalen ist dieser Punkt sehr ernst
zu nehmen. Portale sind zwar zumeist dynamisch erzeugte Websites mit
einem hohen Anteil an statischen, bzw. Informationen aus dem Cache. Bei
weltweit verfügbaren Portalen spielt die geographische Verteilung aller
statischen, nicht-sensiblen Portalinhalte eine sehr wichtige Rolle. Latenzen
können sich bei mehreren Objekten auf der Portalseite zu wertvollen
Sekunden summieren und das Nutzererlebnis beeinträchtigen. Statische,
öffentliche Inhalte eines Portals sollten deshalb auf ein weltweit
verfügbares Content-Delivery-Network (CDN), wie z.B. Akamai ausgelagert
sein.

Anzahl der Test-­‐Sessions kalkulieren

Um einen zuverlässigen Performancetest mit für die Realität ableitbaren
und belastbaren Ergebnissen zu entwickeln bedarf es einer genauen
Planung der zu testenden Anzahl der Benutzersessions und deren
Verteilung. Das Web-Frontend des Portals, bzw. die Logfiles können
Auskunft darüber geben, welche Portlets wie oft von welchen Nutzern
konsultiert werden.

Hinzu kommen weitere Punkte, die Beachtung finden sollten:

  • Erwarteter Zuwachs der gesamten Traffics der Portals
  • Der maximale Peak-Load, basierend auf Anzahl der registrierten Nutzer
  • Die Geschwindigkeit mit der die maximale Useranzahl graduell erreicht wird
  • Wie lange die maximale Useranzahl im Schnitt anhält

 

Den erwarteten Zuwachs berechnen

Vorhersagen zur Entwicklung der Nutzerzahlen zu treffen ist nicht immer
leicht, aber sehr wichtig. Wenn ein Portal z.B. 100.000 Benutzersessions pro
Woche aufweist, entspräche dies ca. 150 Sessions pro Stunde bei einem
Betrieb von 24h/Tag. Wenn man nun einen Zuwachs von 100% annimmt,
entspräche dies also 300 Sessions pro Stunde.

Der Zuwachs an Traffic wird von zwei Größen bestimmt: Dem historischen
Zuwachs und Annahmen bezüglich der geplanten Geschäftsentwicklung. Um
diese Werte zu bestimmen nimmt man den aktuellen Traffic und errechnet
den prozentualen Zuwachs binnen eines Monats.

Besondere Berücksichtigung sollten spezielle Events oder Aktionen
erfahren, die zeitweise kleinere Peaks verursachen – auch diese Werte
sollten in die Kalkulation miteinfließen.

Die maximale Last berechnen

Gerade bei Portalen ist es wichtig zu wissen, wo in etwa die Lastgrenze der
aktuellen Installation liegt. Gerade weil man bei webbasierten Applikationen
oftmals eher keine uniforme Verteilung der Zugriffe pro Zeiteinheit und
Nutzer erkennen kann.

In jedem Unternehmen kann man ein oder zwei Tage pro Woche erkennen,
an denen die Grundlast auf die IT-Infrastruktur am höchsten ist und genau
wie man die höchsten Belastungen herausfiltert, sollte man sich auch den
Zeitpunkten der niedrigsten Grundlast zuwenden.

Wenn man also Lasttests auf dem produktiven Echtsystem plant, sollte man
möglichst deren Ausführung zu Zeiten planen an denen die Grundlast am
geringsten ist um Verfälschungen zu vermeiden.

Den Ramp-­‐Up und die Peak-­‐Zeit berechnen

Zuverlässige Berechnungen für das graduelle Benutzer Ramp-Up und die
Zeitspanne für die höchste Systemlast anzustellen ist ein sehr wichtiger
Punkt bei der zuverlässigen Beurteilung der Skalierbarkeit der zu testenden
Portalinstallation.

Zum Beispiel würde ein Aktienportal im Internet regelmäßig zur
Börsenöffnung mit vielen konkurrierenden Nutzersitzungen überflutet
werden. Die Anzahl der aktiven Benutzer könnte von wenigen Sessions auf
einige tausend binnen weniger Minuten anschwellen.

Wenn man also einen Performancetest für ein solches Portal plant, sollte
man diesen Umstand ebenfalls in den Testskripten durch einen rasanten
Anstieg der virtuellen User innerhalb der ersten Testminuten abbilden.

Ein langsamerer Anstieg der Usersessions würde die Testergebnisse
dahingehend verfälschen, dass man die tatsächlichen Kapazitäten des
Portals eher überschätzen würde. Ebenfalls ist die Dauer der maximalen
Belastung ein wichtiger Punkt – insbesondere für Portaltechnologien mit
extensiver Nutzung von Java-Komponenten.

Unsere Erfahrung zeigt, das es bei unsauberer Programmierung, gerade bei
in Java realisierten Portalkomponenten zu Problemen im Speichermanagement
(Virtueller Speicher, Threading, Garbage Collection, …) kommen kann.

Die verschiedenen Arten von Performance-­‐Tests

Es existiert eine weit verbreitete Fehlannahme, das ein Performance-Test
von webbasierten Applikationen und Portalen immer den sogenannten
Breakpoint, also das ausreizen des Backends bis hin zur Unbenutzbarkeit zur
Folge hat oder haben sollte.

Dies stimmt so nicht, denn das geschilderte Szenario ist nur eines von vielen
Testszenarien, die je nach dem mehr oder weniger für den jeweiligen
Testcase geeignet sein.

Im Wesentlichen kann man Performance-Tests in fünf verschiedene Test-
Typologien unterteilen, die jeder für sich eine andere Zielsetzung verfolgen:

  • Smoke Test – Ein kleiner, schnell durchzuführender Test um zu testen ob die Portalanwendung bereit ist für tiefgreifende Tests. Zum Beispiel macht die Ausführung komplexer Tests wenig Sinn, wenn der Aufbau der Loginseite des Portals bereits 5 Minuten in Anspruch nimmt.
  • Performance Test – Der Performance Test testet die Portalinstanz gegen eine fest vorher bestimmte Last von X Benutzern. Das Hauptziel dieser Art von Test ist herauszufinden, wie das Portal mit anteigenden Benutzerzahlen umgeht und ob größere Benutzerzahlen immer noch zu befriedigenden Antwortzeiten führen.
  • Stress Test – Dieser Test verifiziert die vertretbare Portalperformance unter abnormalen Bedingungen bis hin zu unverhältnismäßig hohen Benutzerzahlen, die in der Realität nur selten erreicht werden. Das Ziel des Stress Tests kann ferner sein, weitere Last auf das System zu legen bis der sogenannte Break Point – der Totalzusammenbruch – erreicht wird.
  • Capacity Test – Hier wird eher die Anzahl der zeitgleichen konkurrierenden Nutzersessions getestet, gerade im Hinblick auf Portallösungen eine sehr wichtige Test-Art. Als Resultat lässt sich ableiten, wie viele parallele Nutzer ein und dieselbe Portalfunktionalität nutzen können, ohne das es zu unverhältnismäßig hohen Antwortzeiten kommt.
  • Endurance Test – Diese Test-Art generiert eine relativ hohe Grundlast über eine lange Zeitdauer um die Verlässlichkeit und Stabilität aller beteiligten Systeme zu testen.

 

Fortsetzung in Teil 11:

Im nächsten Teil geht es um Performance Testing und Stress Testing. 

Lesen Sie hier ab dem 30.10. den Teil 11

Share