2 Performance
2.3 Vorgehensweise zur Bestimmung von Performance
2.3.5 Performancemessungen von Mehrschichtarchitekturen
2.3.5.4 Durchführung der Tests
Die Durchführung der Tests teilt sich in drei Testarten auf. Zuerst erfolgen die Tests zur Rauschwertermittlung und zur Bestimmung der Referenzwerte. Anschließend werden die Last- und Stresstests durchgeführt.
2.3.5.4.1 Rauschwertermittlung
Für die erfolgreiche Interpretation der Testdaten ist es vor den geplanten Last- und Stresstests notwendig, eine Analyse der externen Einflüsse auf das System durchzuführen. Zu diesen Einflüssen zählen Prozesse oder Aktionen die auf den Servern des Testsystems laufen oder auch Komponenten, wie Netzwerkleitungen oder Firewalls, die auch von anderen Systemen genutzt werden. Beispiele wären regelmäßige Backups, regelmäßige komplexe Berechnungen oder Wartungsprozesse. All dies kann zu Verfälschung der Performanceanalyse führen. Daher ist es notwendig dieses "Rauschen" im Vorhinein zu erkennen und in die Analyse der Daten einfließen zu lassen.
Um dieses Netzwerkrauschen zu ermitteln, werden Referenzmessungen durchgeführt, die über einen langen Zeitraum, zum Beispiel 1 Woche, regelmäßig mit geringer Last auf das Testsystem zu greifen. Diese so ermittelten Daten zeigen regelmäßige Belastungen des Netzwerkes auf.
Abbildung 2.3-1 - Referenzwertermittlung, Test über 72 Stunden
Als Beispiel ist hier die Analyse eines Tests zur Ermittlung des Netzwerkrauschens über 72 Stunden mit 10 parallelen Nutzern, die alle 10 Minuten für zwei Minuten auf das System zu greifen, dargestellt. In Abbildung 2.3-1 sind tägliche Ausschläge zu sehen, die nach näherer Analyse, manuell gestartete Backups als Ursache ergaben.
Diese Erkenntnis ermöglicht es, die folgenden Last- und Performancetests zu unbelasteten oder zu belasteten Zeiten durchzuführen. Je nach erwarteter Last im realen Betrieb, sollten die zusätzlichen Belastungen des Systems minimiert oder zu weniger belastenden Zeiten durchgeführt werden. Sind diese belastenden Einflüsse auch während erwarteter Spitzenlasten der Anwendung nicht auszuschließen, so muss die Performance des Systems auch in diesen Zeiträumen getestet werden.
Sind bei dem Vergleich von Tests zu belasteten und unbelasteten Zeiten, große Differenzen zu erkennen, muss darüber nachgedacht werden, ob die äußeren Einflüsse minimiert oder verlagert werden können.
2.3.5.4.2 Last- und Stresstests
Nach der Ausführung der Referenzmessungen und der Entscheidung und Planung, wann welche Tests durchgeführt werden sollen, starten die Last- und Stresstests. Abhängig von den vorgegebenen Zielen der Performanceanalyse ist die Reihenfolge der Durchführung der Last- und Stresstests beeinflusst.
2.3.5.4.2.1 Stresstests
Für eine Ist-Analyse des zu testenden Systems bietet sich die Durchführung von Stresstests an. Hierdurch ist es möglich, die maximale parallele Nutzerzahl zu bestimmen, bei denen das System in den vorgegebenen Parametern arbeitet. Hierzu sollten ein erwarteter realistischer Mix als Testszenario gewählt und die Abbruchbedingungen für den Stresstest definiert werden. Als Abbruchbedingungen für den Stresstest können Antwortzeiten, Fehler oder verschiedene andere Parameter, wie Timeouts von Servern, Auslastung von Firewalls oder der Netzwerkbandbreite, festgesetzt werden.
In den folgenden Beispielen wird das Erkennen der Abbruchbedingung für die Fälle erläutert, dass einmal für die durchschnittlichen Antwortzeiten und einmal für die Anzahl der Fehler eine definierte Abbruchbedingung erreicht wird.
Abbildung 2.3-2 - Stresstestauswertung - durchschnittliche Antwortzeiten
Die Abbildung 2.3-2 zeigt die treppenartig ansteigende parallele Nutzerzahl und die durchschnittlichen Antwortzeiten der Anfragen. Es ist deutlich ein Anstieg der durchschnittlichen Antwortzeiten bei Erhöhung der Nutzerzahlen zu erkennen. Eine vorher definierte maximale durchschnittliche Antwortzeit aller Anfragen kann als Anhaltspunkt für den Abbruch der Tests genommen werden. Wie aber in der Abbildung zu erkennen ist, schwanken die Antwortzeiten sehr stark. Dieses muss auch bei der Festlegung der Abbruchbedingung beachtet werden.
Für den Fall, dass die geforderten durchschnittlichen Antwortzeiten auf maximal 200ms definiert worden sind, kann noch sehr eindeutig festgelegt werden, dass bis zu einer parallelen Nutzerzahl von 200 diese Anforderung erfüllt wird. Nach dem die parallele Nutzerzahl auf 300 erhöht wurde ist diese Anforderung nicht mehr zu halten. Spätestens nach der nächsten Erhöhung kann der Stresstest abgebrochen werden, da das Einhalten der definierten Grenze für die durchschnittlichen Antwortzeiten nicht mehr möglich ist.
Ist keine Grenze definiert und der Stresstest darauf ausgelegt, das Verhalten des Systems zu messen, kann anhand dieses Beispiels keine Abbruchbedingung erkannt werden. Mögliche Probleme können durch die großen Schwankungen der Antwortzeiten bei höheren parallelen Nutzerzahlen vermutet werden. Es ist aber nicht eindeutig ein Punkt zu definieren, an dem zu erkennen ist, ob das System korrekt arbeitet. Dazu müssen weitere Parameter des Tests betrachtet werden.
Ein solcher Parameter kann die Anzahl der Anfragen, die nicht mehr fehlerfrei ausgeführt werden können, sein. Nicht erfolgreiche Anfragen können durch Überlastung von Servern oder des Netzwerkes oder durch die Überschreitung von Serverparametern eintreten.
Abbildung 2.3-3 - Stresstestauswertung - Anzahl fehlgeschlagener Anfragen
In der Abbildung 2.3-3 ist wieder die treppenartig ansteigende parallele Nutzerzahl zu erkennen. Der rote Graph stellt die Anzahl der Fehler dar. Der sprunghafte Anstieg der nicht erfolgreich durchgeführten Anfragen ist eine gut erkennbare Abbruchbedingung. Das Erreichen und Überschreiten der maximalen Verbindungen des Webservers führte in diesem Fall zu diesem Graphen.
Nach der Definition der Abbruchbedingungen für die Stresstests bleibt noch die Art und Weise festzulegen, wie die Last über den geplanten Testzeitraum verteilt werden soll.
In den letzten Abbildungen wurde der treppenartige Anstieg der parallelen Nutzerzahl gewählt. Dies ist unter Umständen zu vermeiden, wenn das Testszenario aus wenigen verschiedenen Anfragen aufgebaut ist. Dies würde dazu führen, dass alle Anfragen in einer sehr kurzen Zeitspanne ausgeführt würden und danach ein Zeitraum entstünde, der das System mit einer sehr geringen Last versorgen würde. Für solch einen Fall ist ein weicher treppenartiger Anstieg, durch Verzögerung des Startzeitpunktes jedes parallelen Testnutzers, eine günstigere Lösung. Eine gleichmäßig ansteigende parallele Nutzerzahl ist ebenfalls möglich - erschwert allerdings die Analyse, da keine deutlichen Abgrenzungen zu erkennen sind.
2.3.5.4.2.2 Lasttests
Die Durchführung der Lasttests dient in der Performanceanalyse zur Darstellung des Systemverhaltens bei unterschiedlich hoher Last. Während bei den Stresstests die parallele Nutzerzahl stetig erhöht wird, bis die Grenzen der Belastbarkeit erreicht bzw. festgelegte Performancegrenzen überschritten werden, arbeitet man bei Lasttests mit einer konstanten parallelen Nutzerzahl für jeden Testdurchlauf.
Durch die Verwendung von verschiedenen Testszenarios können die Performancemessungen gezielt auf verschiedene Aspekte des Systems ausgerichtet werden und ermöglichen somit eine detaillierte Darstellung der Performance. Zudem ist bei Verwendung der gleichen Testszenarios für Lasttests in verschiedenen Phasen der Entwicklung einer Anwendung eine gute Möglichkeit gegeben, den Gewinn oder Verlust an Performance durch Änderungen am System zu erkennen.
Die Durchführung der geplanten Tests, bestehend aus den verschiedensten Testszenarios sollte auf das ermittelte Netzwerkrauschen abgestimmt werden. So sollten die Tests sowohl zwischen als auch während der Spitzenlastzeiten ausgeführt werden.
Weiterhin ist eine genaue Dokumentation der durchgeführten Tests unumgänglich, damit in der späteren Analyse die Testparameter verwendet werden können, um die Ergebnisdaten sinnvoll interpretieren zu können. Zu den wichtigsten Testparametern, die für jeden Test dokumentiert werden sollten, gehören:
- eine eindeutige Kennzeichnung für jeden durchgeführten Test
- System, auf dem die Tests durchgeführt wurden
- die Startzeit und Dauer der Tests, damit ein Abgleich mit den ermittelten Daten über das Netzwerkrauschens möglich ist
- die verwendeten Testszenarios
- die Anzahl der parallelen Nutzer
- die Verteilung der parallelen Nutzer auf die verschiedenen Testszenarios
- Systemeinstellungen, wenn diese nur für die Tests angepasst wurden
Bei der Durchführung der Lasttests sollte gemäß der Anzahl und Dauer der durchzuführenden Tests ein entsprechender Zeitrahmen eingeplant werden. Jeder Lasttest auf einem System läuft über einen längeren Zeitraum - nicht unter 5 Stunden pro Test, um Verfälschungen der Ergebnisse zu vermeiden oder Engpässe aufzudecken, die erst nach gewisser Zeit auftreten. Zu ersterem gehören zum Beispiel Anlaufzeiten, das heißt, dass Serverprozesse erst Unterprozesse erzeugen müssen, um die gewünschte Last zu erzeugen. Ein anderes Beispiel wäre das Arbeiten von Caches, die erst nach gewisser Zeit ihre Vorteile ausspielen können. Zweitens können erst zu späteren Zeitpunkten Leistungseinbußen eintreten, die durch Volllaufen von Warteschlangen oder Speicherlecks in der Anwendung oder anderen unvorhersehbaren Korrelationen hervorgerufen werden.
Ein Beispiel für die Durchführungsplanung von Lasttests wird in einem späteren Kapitel am Beispiel des Campus Management Projektes dargestellt.
2.3.5.5 Auswertung und Analyse der Ergebnisse
Die Auswertung und Analyse, der während der Durchführung von Tests gewonnenen Daten, ist ein komplexer, aufwendiger aber in höchstem Maße wichtiger Prozess. Er setzt grundlegendes Wissen über die Architektur des Systems und die Art und Weise der Durchführung der Tests voraus. Nur durch dieses Wissen ist es möglich, die in den Tests gesammelten Daten sinnvoll zu korrelieren, dass eine sinnvolle Auswertung und Interpretation der gemessenen Daten erfolgen kann. Daher ist schon in der Planungsphase genau darauf zu achten, welche Daten erfasst werden müssen.
Nach der Durchführung der Tests erhält man eine große Datenmenge, die unter Umständen in verschiedenen Formaten vorliegen. Der erste Schritt ist die Aufbereitung der Daten, so dass alle ermittelten Werte miteinander verknüpft werden können. Ein Beispiel hierfür wäre das Importieren aller Daten in eine vorbereitete Datenbank. Die so aufbereiteten Daten können über Abfragen analysiert und in gewünschter Form dargestellt werden. Es bieten sich Abfragen über einzelne oder die Gesamtheit, aber auch über eine Teilmenge von Tests an, die spezifische Systemkomponenten belastet haben. Die Ergebnisse dieser Abfragen können in Tabellen oder Berichten dargestellt werden und zeigen zum Beispiel die Testszenarios mit den schlechtesten Performancewerten oder die Anfragen mit den häufigsten Fehlern oder vieles mehr.
Eine weiterhin oft genutzte Darstellungsform sind Graphen, die Abhängigkeiten einzelner Parameter visualisieren.
Abbildung 2.3-4 - Standardgraphen von Neoload
In der Abbildung 2.3-4 sind die generierten Standardgraphen des Lasttesttools Neoload von der Firma Neotys dargestellt. Für die Performanceanalyse einer Webanwendung werden hier die entscheidenden Daten anhand des Zeitstempels visualisiert. Die farbigen Graphen stehen für:
- blau: parallele Nutzerzahl, die gleichzeitig ihre Testszenarios ausführen
- grün: die ausgeführten Anfragen pro Sekunde aller virtuellen Nutzer
- braun: die durchschnittliche Antwortzeit, aller in diesem Moment gestellten Anfragen
- rot: die Anzahl der nicht erfolgreich ausgeführten Anfragen
Sind genauere Informationen erforderlich, lassen sich ebenfalls Performancezähler der Systemkomponenten in dieser Weise korrelieren.
Diese Graphen geben einen Überblick über die Gesamtperformance des getesteten Systems. Allerdings können sie nur aufzeigen, ob die Systemperformance in den gewünschten Grenzen liegt oder nicht. Die Analyse, welche Ursachen für eine nicht ausreichende Performance vorliegen, muss durch weitergehende Methoden durchgeführt werden. Dies wird im Kapitel Bottleneck-Analyse in Mehrschichtarchitekturen näher erläutert.
Performancetest Bottleneck Testtool Mercury Virtuelle User Testverfahren
