2 Performance
2.4 Aussagekraft von Ergebnissen
In diesem Abschnitt wird näher erläutert, welche Probleme bei der Analyse der gemessenen Daten auftreten und wie eine mögliche Vorgehensweise zur sinnvollen Interpretation der Ergebnisse aussehen kann.
In den vergangenen Abschnitten wurden die grundlegenden Daten vorgestellt, die bei Analyse eine wichtige Rolle spielen. In der folgenden Graphik ist ein Testlauf mit dem Lasttesttool Neoload dargestellt, der mit einer konstanten parallelen Nutzerzahl von 100 auf eine Webanwendung einer komplexen Multischichtarchitektur durchgeführt wurde.
Abbildung 2.4-1 - Lasttest mit 100 parallelen Nutzern
Welche Aussagen kann man aus diesen Graphen gewinnen? Diese Frage ist nicht einfach zu beantworten. Es ist eine starke Schwankung der durchgeführten Anfragen und der durchschnittlichen Antwortzeit zu erkennen.
Die Interpretation dieser Graphen lässt folgende Vermutungen zu:
i. Die verwendeten Testszenarios sind so aufgebaut, dass die Ausführung von komplexeren Anfragen, die eine stark höhere erwartete Antwortzeit erfordern, von allen Testnutzern zur gleichen Zeit ausgeführt werden und den Graphen der durchschnittlichen Antwortzeiten in dieser Art erzeugen.
ii. Unter der Annahme einer erwarteten durchschnittlichen Antwortzeit von 5 Sekunden ist die Aussage möglich, das System ist performant.
iii. Unter der Annahme einer erwarteten durchschnittlichen Antwortzeit von 1,5 Sekunden ist die Aussage zu treffen, das System erfüllt nicht die gewünschten Anforderungen.
iv. Die starken Schwankungen weisen auf einen Engpass im System hin und müssen weiter analysiert werden.
Die Vermutung unter Punkt i. kann eine Rolle spielen, da die verwendeten Testszenarios ein Mix aus einfachen und komplexen Anfragen sind, aber alle virtuellen Nutzer zur gleichen Zeit gestartet werden und somit bei ähnlichem Verlauf der Testszenarios zur gleichen Zeit auf die komplexen Anfragen treffen können. In diesem Fall sollte ein neuer Test erstellt werden, der dies unterbindet, da es nicht einem realen Nutzerverhalten entspricht. Entweder sollte der Mix der Testszenarios angepasst werden oder die Startzeit eines virtuellen Nutzers in den Testszenarios verzögert werden.
Die Vermutungen in Punkt ii. und iii. wären mögliche Aussagen, die aber in Anbetracht der starken Schwankungen, nicht mit reinem Gewissen getroffen werden sollten. Wie unter Punkt iv. richtig vermutet, können diese Schwankungen auch auf einen Engpass im System hinweisen. Es ist eine nähere Analyse der Systemkomponenten erforderlich. Eine solche Bottleneck-Analyse wird in einem späteren Kapitel behandelt.
An diesem kurzen Testbeispiel lässt sich erkennen, dass die Interpretation der Daten ein schwieriger Prozess ist und dass erst durch die Einbeziehung von Wissen über die Systemarchitektur und den Aufbau der Tests belegbare Aussagen getroffen werden können.
Natürlich gibt es auch Fälle, bei denen sich eine richtige Aussage leichter treffen lässt. Dies ist in der Abbildung 2.4-2 einer Stresstestanalyse dargestellt.
Abbildung 2.4-2 - Stresstest
Dieser Stresstest wurde wiederum mit dem Lasttesttools Neoload auf einer Webanwendung durchgeführt. In diesem Fall ist eine sinnvolle Aussage über die Performance des Systems, einfach zu treffen. Je nach Definition der erwarteten Antwortzeiten ist eine Aussage möglich, wie viele gleichzeitige Nutzer das System unter diesen Bedingungen verarbeiten kann. Man erkennt sehr schön die Korrelation der parallelen Nutzer und der durchschnittlichen Antwortzeiten. Aber ab einer parallelen Nutzerzahl von 500 ist das System allerdings überfordert - gut zu erkennen am Anstieg des Fehlergraphen. Aber auch die gleichzeitig auftretenden, sehr starken Schwankungen zeigen wiederum eine Überlastung einer Systemkomponente, die sich in diesem Fall durch einen Engpass am Webserver erklären ließ. Dieser erlaubte nur eine maximale Anzahl von 500 gleichzeitigen http-Verbindungen. Da aber 100 virtuelle Nutzer gleichzeitig ihre Anfragen stellten und eine Anfrage im Schnitt aus mehreren einzelnen http-Verbindungen bestand, führte dies zum Füllen der Warteschlange des Webservers und zum Erreichen von Timeouts, die einen Abbruch der Anfragen zu folge hatten und somit die Fehlerzahl anstiegen ließen.
Die Aussage, ob das System als performant bezeichnet werden kann, ist natürlich abhängig von den definierten Erwartungswerten. Sollen auf dieses System nicht mehr als 500 Nutzer gleichzeitig zugreifen und die erwartete Antwortzeit nicht geringer als 4 Sekunden ist, führt dies zu der Aussage, dass die Systemarchitektur ausreichend performant ist und der Test kann als bestanden gewertet werden. Wird durch andere Erwartungen - höhere parallele Nutzerzahl oder geringe Antwortzeiten, der Test als nicht bestanden gewertet, so muss auch in diesem Fall eine Bottleneck-Analyse durchgeführt werden und eventuell Hardware neu konfiguriert, ausgetauscht oder die Anwendung auf Softwareebene optimiert werden. Die Optimierung des Systems sollte aber erst nach Feststellung der Engpässe erfolgen, da ein mögliches Raten des Engpasses nur Zeit und Kosten verursachen, die eventuell nicht nötig sind.
Performancetest Bottleneck Testtool Mercury Virtuelle User Testverfahren
