2 Performance
2.3 Vorgehensweise zur Bestimmung von Performance
2.3.5 Performancemessungen von Mehrschichtarchitekturen
2.3.5.3 Vorbereitung
Performancetests erfordern eine genaue und möglichst frühe Planung. Sie sollten schon während der Planungsphase des gewünschten Systems oder der zu erstellenden Software beachtet werden. Zur Vorbereitung der Performancetests gehören neben technischen Vorbereitungen und der Planung und Erstellung von Testszenarios auch organisatorische Arbeiten.
2.3.5.3.1 Anforderungsdefinition
Bevor über die Durchführung der Performancetests nachgedacht werden kann, ist zuerst festzulegen, was getestet und welche Aussagen am Ende getroffen werden sollen. Es kann unterschieden werden, ob nur bestimmte Parameter in einem System gemessen werden sollen, deren Aussagekraft dann aber nur auf der subjektiven Interpretation der Daten basiert oder ob das System auf Performance getestet werden soll, was eine genaue Anforderungsdefinition voraussetzt. Für aussagekräftige Ergebnisse, die eventuell auch als Nachweis der Erfüllung nichtfunktionaler Anforderungen genügen sollen, ist der letztere Fall zu empfehlen.
Bestandteile einer Anforderungsdefinition sollten sein:
- eine Analyse der erwarteten Nutzerzahlen die auf das System zu greifen
- eine Analyse wie und von welchen Netzwerkeinstiegspunkten auf das System zugegriffen wird (intern/extern, Clients/Webschnittstelle/direkt auf Datenbanken oder Server usw.)
- eine Analyse der Parameter, die sich auf die Performance des Systems auswirken können und die Entscheidung welche Parameter bei der Durchführung der Tests berücksichtigt werden sollen
- Festlegung der Erwartungsdefinitionen, zum Beispiel die Teilakzeptanzfaktoren für die ausgewählten Parameter
Je genauer die Anforderungsdefinition formuliert wird, je aussagekräftiger werden nach der Durchführung der Performancetests die erhaltenen Ergebnisse sein.
2.3.5.3.2 Organisatorische Aufgaben
Die Durchführung von Performancetests in Multischichtarchitekturen ist ein nicht zu unterschätzender zeitlicher und arbeitstechnischer Aufwand, der wohl durchdacht und geplant werden muss. Da ein System so gut wie nie einen Punkt erreicht, an dem es nicht weiterentwickelt wird, Performancetests aber eine stabiles und gleichbleibendes System voraussetzen, um aus den gesammelten Daten, Aussagen über die Performance des Systems zu treffen, können Konflikte zwischen der Weiterentwicklung und den Performancetests auftreten.
Schon früh muss über die Bereitstellung eines Testsystems nachgedacht werden, das dem späteren Produktivsystem zumindest ähnelt, obwohl dies schon ein Kompromiss der Performancetests an wirtschaftliche Aspekte eines Unternehmens ist. Normalerweise sollten Performancetests auf dem Produktivsystem ausgeführt werden, da auch ähnliche Systemkomponenten verschiedene Verhaltensweisen in Korrelation mit anderen Komponenten aufweisen können, die das Ergebnis der Performancemessungen sinnlos machen können. Man kann keine sicheren Aussagen über ein System treffen, wenn man ein anderes getestet hat.
Steht kein eigenes Testsystem zur Verfügung, müssen Live-Betrieb, Entwicklung und Performancetests koordiniert werden. Unter Beachtung, dass für Performancetests nicht nur technischen Voraussetzungen, wie Hardware, sondern auch spezielle Testdaten und Berechtigungen zur Verfügung stehen müssen, erfordert dies eine genaue Planung.
2.3.5.3.3 Technische Vorbereitungen
Zu den technischen Vorbereitungen gehören der Aufbau und die Einrichtung des gesamten Testsystems. Je nach zur Verfügung stehenden Möglichkeiten kann ein eigenes Testsystem aufgebaut oder ein verfügbares System als Testsystem eingerichtet werden. Wie schon in vergangenen Abschnitten erläutert, sollten die finalen Tests im Produktivsystem durchgeführt werden. Da dies aber nicht immer möglich ist, da zum Beispiel der aktive Betrieb nicht unterbrochen werden kann, ist zu empfehlen ein eigenes Testsystem aufzubauen. Somit wird der Live-Betrieb und auch die Weiterentwicklung der Anwendung nicht eingeschränkt.
Des weiteren müssen Testmaschinen ausgewählt werden, die zur Durchführung der Last- und Stresstests die entsprechende Last erzeugen. Je nach geforderter Anzahl der parallelen Nutzer, die auf das System zu greifen sollen, ist ein Pool von Testmaschinen notwendig. Diese müssen bereitgestellt und auf ihnen die benötigten Tools installiert werden. Wurde für die geplanten Tests eine lokale Hierarchie erstellt, müssen eventuell mehrere Pools von Testmaschinen bereitgestellt werden, damit die Performancetests von den verschiedenen Netzwerkeinstiegspunkten durchgeführt werden können.
Die Begriffe Testsystem und Testumgebung werden im weiteren Verlauf folgendermaßen verwendet - als Testsystem wird die zu testende Architektur bezeichnet und als Testumgebungen die verschiedenen Pools von Testmaschinen.
Für den Zugriff auf das Testsystem ist weiterhin zu beachten, dass die gewählten Testmaschinen alle Berechtigungen erhalten, damit sie auch über interne oder externe Firewalls auf das System zu greifen können. Je nach den vorgenommenen Sicherheitsmechanismen ist das Zuweisen der Berechtigungen nicht nur auf die Testmaschinen, sondern sogar auf der Ebene der Testnutzer nötig.
Bei der Durchführung von White-Box- oder Grey-Box-Tests bzw. der Planung von Messungen von Performancezählern auf Servern oder anderen Netzwerkkomponenten müssen die entsprechenden Dienste oder Tools installiert und eingerichtet werden.
2.3.5.3.4 Vorbereitungen der Testdaten
Nachdem die gewünschte Hardware für die Testumgebung eingerichtet ist, erfolgen weitere Vorbereitungen, die für die Durchführung der Performancetests zwingend notwendig sind.
Um das System unter Last zu setzen, werden eine Vielzahl von Testnutzern benötigt. Diese sollten so realistisch wie möglich angelegt werden und in der Art und Weise auch ein Mix darstellen, der im späteren Betrieb der Anwendung zu erwarten ist. In einer bereits aktiven Anwendung kann man die vorliegende Nutzerstruktur als Basis benutzen, sind aber noch keine vorliegenden Daten nutzbar, erfordert dies eine theoretische Analyse, um ein möglichst realistisches Nutzerprofil zu erstellen.
Die Anzahl der zu erzeugenden Testnutzer ist abhängig von verschiedenen Faktoren. Der Haupteinfluss auf die Testnutzerzahl ist die geforderte Anzahl der Nutzer, die später parallel auf das Testsystem zu greifen. Weiterhin nehmen die Art und Weise der Testszenarios und auch der Zeitplan der Performancetests Einfluss auf die zu erstellende Testnutzerzahl. Abhängig ob die Testdaten der Testnutzer während der Tests wieder in den Anfangszustand gesetzt werden können oder nicht, ist es notwendig für jeden Test neue Testnutzer zu verwenden. Dies erhöht die Anzahl der zu erstellenden Nutzer deutlich. Werden die Testdaten der Testnutzer während der Tests, zum Beispiel durch nur lesende Zugriffe auf der Datenbank, nicht verändert oder können am Ende wiederhergestellt werden, zum Beispiel durch entgegengesetzte Aktionen, wie Hinzufügen eines Nutzers in eine Gruppe und anschließendes Entfernen aus dieser Gruppe, so ist es möglich, diese Testnutzer mehrmals in einem Test oder für verschiedene Tests zu verwenden.
Alle erstellten Nutzer müssen so angelegt werden, dass sie die anwendungsspezifischen Voraussetzungen erfüllen, um die geplanten Testszenarios durchzuführen. Dazu gehört eventuell auch die Zuweisung von Berechtigungen für externe Authentifizierungsmechanismen.
Um die Ergebnisse, die bei der Performanceanalyse ermittelt werden, auf den späteren Betrieb zu übertragen, ist es weiterhin notwendig, dass anwendungsspezifische Daten in dem Maße vorhanden sind, wie sie später im Betrieb verwendet sind. Es ist nicht ausreichend, nur ein paar Testdaten in der Datenbank zu halten, wenn später im laufenden Betrieb, die Datenmenge, um ein Vielfaches größer ist. Dies führt zu einer nicht akzeptablen Verfälschung der Performanceanalyse und macht die Ergebnisse nutzlos.
2.3.5.3.5 Erstellung der Testszenarios
Vorausgesetzt, dass Testsystem und Testumgebung eingerichtet sind, alle erforderlichen Nutzer und anwendungsspezifischen Daten erfolgreich erstellt wurden und die Anwendung einen funktional fehlerfreien und für die Testdurchführung eingefrorenen Zustand besitzt, kann die konkrete Erstellung der Testszenarios beginnen. Die Voraussetzung, dass die Anwendung funktional fehlerfrei und für die Tests nicht veränderbar sein soll, ergibt sich aus der Betrachtung, dass Testszenarios sehr anwendungsspezifisch sind und durch Änderungen in funktionalen Komponenten der Anwendung, eine Anpassung der Testszenarios erforderlich machen. Dies kann je nach verwendetem Tool oder Eigenprogrammierung ein aufwendiger Schritt sein. Funktionale Fehler in einer Anwendung führen zu verfälschten Daten, da eventuelle Fehlermeldungen wesentlich kürzere Antwortzeiten liefern und auch folgende abhängige Anfragen somit nicht korrekt ausgeübt werden können, was zu einer Verkettung von fehlerhaften Ergebnissen führt.
Davon ausgehend, dass alle Voraussetzungen erfüllt sind, kann mit der Erstellung der Testszenarios begonnen werden. Hierbei ist auf die definierten Hierarchien zu achten - qualitativ, quantitativ und lokal. Alle geplanten Testszenarios werden erstellt und übersichtlich gekennzeichnet.
Nur durch eine sorgfältige Dokumentation der angelegten Testszenarios können die später gesammelten Daten zu einer genauen und aussagekräftigen Interpretation der Daten führen.
2.3.5.3.6 Methoden zur Erstellung realistischer Testszenarios
Wie in den letzten Abschnitten erläutert, ist die Auswahl der zu erstellenden Testszenarios ein wichtiger und komplexer Arbeitsschritt, um die Aussagekraft der Performancetests zu garantieren.
Hierzu gibt es verschiedene Ansätze, die sich mit diesem Thema auf theoretischer oder praktischer Weise beschäftigen.
2.3.5.3.6.1 Praktische Ansätze
Sind Anwendungen schon eine gewisse Zeit in Betrieb, bietet sich die Möglichkeit an, die protokollierten Abläufe der Nutzer auszuwerten und anhand dieser Daten, die Testszenarios zu erstellen. Hierbei sind nicht nur die wichtigsten Abläufe zu erkennen, welche die Nutzer durchführen, sondern auch die Verteilung der Testfälle. Daraus lassen sich entsprechende Testszenarios ableiten und bieten einen sehr realistischen Workload, der für die Performancetests genutzt werden kann. Sind keine bisherigen Protokolle mit Historien des Nutzerverhaltens vorhanden, müssen Annahmen darüber getroffen werden.
Geschäftsprozesse und Use-Cases, die während früherer Softwareentwicklungsphasen erstellt wurden, sind eine gute Ausgangsbasis. Aus ihnen lassen sich entweder intuitiv, durch Vorgabe anwendungsspezifischer Abläufe oder durch Analyse ähnlicher Systeme Abläufe definieren, die dann als Testfälle definiert werden können.
Methoden, die aus Use-Cases durch eine Reihe von Transformationen Testskripte generieren können, sind zum Beispiel finden unter [14][15][16].
Viele der Lasttesttools unterstützen ein Aufzeichnen von Abläufen. Dies kann dazu genutzt werden, verschiedene Abläufe als Testfälle zu generieren. Diese Abläufe sind sehr anwendungsspezifisch und können daher nicht pauschal definiert werden. Es ist wichtig, dass eine nicht zu kleine Anzahl an Testfällen erzeugt wird, die das Spektrum der später gebräuchlichsten Abläufe abdecken.
Über die Verteilung der Testfälle in einem Testszenario können nun Annahmen gemacht werden. Am Beispiel eines Internetshops sind die Abläufe Produkte suchen und Produkte ansehen am wahrscheinlichsten, Einloggen in seinen Nutzerbereich und Produkte kaufen folgen in der Hierarchie. Diese Überlegungen müssen bei der Erstellung der Testfälle und deren Verteilung in den Testszenarios beachtet werden. Umso genauer die Annahmen gemacht werden, desto realistischer wird der Workload sein und die Aussagekraft der späteren Tests steigt.
2.3.5.3.6.2 Theoretische Ansätze
Da das Vorhersagen von Nutzerverhalten eine wichtige Rolle spielt, gibt es auch einige theoretischen Ansätze, die sich mit der Analyse des Nutzerverhaltens beschäftigen. So verfolgen Dirk Draheim, John Grundy, John Hosking, Christof Lutteroth, Gerald Weber in dem Paper "Realistic Load Testing of Web Applications" [17] einen mathematischen Ansatz zur Bestimmung des Nutzerverhaltens. Basierend auf der Arbeit "Form-Oriented Analysis - A New Methodology to Model Form-Based Applications" [18] in der die möglichen Abläufe einer Webanwendung als Form-Chart definiert werden, ordnen sie jeder möglichen Aktion des Nutzers eine Wahrscheinlichkeit zu. Ein Programm erzeugt aus diesen Wahrscheinlichkeiten Testszenarios, die sowohl mit einer bestehenden Historie des Nutzerverhaltens oder auch ohne realisiert werden können.
Weitere Arbeiten zur Bestimmung des Nutzerverhaltens zur Erstellung von Testszenarios für Performancetests wurden von L. Xu und B. Xu [19] [20] verfasst.
Performancetest Bottleneck Testtool Mercury Virtuelle User Testverfahren
