Tools für Performance- und Lasttests
- Instanzen-Anzahl
Die Instanzen Anzahl definiert, wie viele Instanzen gleichzeitig auf das zu testende Objekt zugreifen.
- Anlauf-Zeit
Eine Anlauf-Zeit gibt an, wie lange JMeter benötigen soll, um die volle Instanzen-Anzahl auf das Testobjekt zu leiten. Wenn 10 Instanzen genutzt werden und eine Anlaufzeit von 100 Sekunden angegeben ist, so startet JMeter innerhalb dieses Zeitraums alle 10 Sekunden eine weitere Instanz.
- Wiederholungszahl des Tests
Standardmäßig läuft eine Testgruppe unbegrenzt oft durch Ihre Elemente. Alternativ dazu kann die Anzahl der Durchläufe festgelegt werden. Wird 1 angegeben, so wird JMeter die Testgruppe nur einmal durchlaufen.
- ein frei wählbarer Name
- der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
- die Portnummer, auf welcher der Server getestet werden soll.
- der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.
- Instanzen-Anzahl
Die Instanzen Anzahl definiert, wie viele Instanzen gleichzeitig auf das zu testende Objekt zugreifen.
- Anlauf-Zeit
Eine Anlauf-Zeit gibt an, wie lange JMeter benötigen soll, um die volle Instanzen-Anzahl auf das Testobjekt zu leiten. Wenn 10 Instanzen genutzt werden und eine Anlaufzeit von 100 Sekunden angegeben ist, so startet JMeter innerhalb dieses Zeitraums alle 10 Sekunden eine weitere Instanz.
- Wiederholungszahl des Tests
Standardmäßig läuft eine Testgruppe unbegrenzt oft durch Ihre Elemente. Alternativ dazu kann die Anzahl der Durchläufe festgelegt werden. Wird 1 angegeben, so wird JMeter die Testgruppe nur einmal durchlaufen.
- ein frei wählbarer Name
- der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
- die Portnummer, auf welcher der Server getestet werden soll.
- der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.
- Instanzen-Anzahl
Die Instanzen Anzahl definiert, wie viele Instanzen gleichzeitig auf das zu testende Objekt zugreifen.
- Anlauf-Zeit
Eine Anlauf-Zeit gibt an, wie lange JMeter benötigen soll, um die volle Instanzen-Anzahl auf das Testobjekt zu leiten. Wenn 10 Instanzen genutzt werden und eine Anlaufzeit von 100 Sekunden angegeben ist, so startet JMeter innerhalb dieses Zeitraums alle 10 Sekunden eine weitere Instanz.
- Wiederholungszahl des Tests
Standardmäßig läuft eine Testgruppe unbegrenzt oft durch Ihre Elemente. Alternativ dazu kann die Anzahl der Durchläufe festgelegt werden. Wird 1 angegeben, so wird JMeter die Testgruppe nur einmal durchlaufen.
- ein frei wählbarer Name
- der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
- die Portnummer, auf welcher der Server getestet werden soll.
- der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.
- Instanzen-Anzahl
Die Instanzen Anzahl definiert, wie viele Instanzen gleichzeitig auf das zu testende Objekt zugreifen.
- Anlauf-Zeit
Eine Anlauf-Zeit gibt an, wie lange JMeter benötigen soll, um die volle Instanzen-Anzahl auf das Testobjekt zu leiten. Wenn 10 Instanzen genutzt werden und eine Anlaufzeit von 100 Sekunden angegeben ist, so startet JMeter innerhalb dieses Zeitraums alle 10 Sekunden eine weitere Instanz.
- Wiederholungszahl des Tests
Standardmäßig läuft eine Testgruppe unbegrenzt oft durch Ihre Elemente. Alternativ dazu kann die Anzahl der Durchläufe festgelegt werden. Wird 1 angegeben, so wird JMeter die Testgruppe nur einmal durchlaufen.
- ein frei wählbarer Name
- der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
- die Portnummer, auf welcher der Server getestet werden soll.
- der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.
- Instanzen-Anzahl
Die Instanzen Anzahl definiert, wie viele Instanzen gleichzeitig auf das zu testende Objekt zugreifen.
- Anlauf-Zeit
Eine Anlauf-Zeit gibt an, wie lange JMeter benötigen soll, um die volle Instanzen-Anzahl auf das Testobjekt zu leiten. Wenn 10 Instanzen genutzt werden und eine Anlaufzeit von 100 Sekunden angegeben ist, so startet JMeter innerhalb dieses Zeitraums alle 10 Sekunden eine weitere Instanz.
- Wiederholungszahl des Tests
Standardmäßig läuft eine Testgruppe unbegrenzt oft durch Ihre Elemente. Alternativ dazu kann die Anzahl der Durchläufe festgelegt werden. Wird 1 angegeben, so wird JMeter die Testgruppe nur einmal durchlaufen.
- ein frei wählbarer Name
- der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
- die Portnummer, auf welcher der Server getestet werden soll.
- der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.
- Instanzen-Anzahl
Die Instanzen Anzahl definiert, wie viele Instanzen gleichzeitig auf das zu testende Objekt zugreifen.
- Anlauf-Zeit
Eine Anlauf-Zeit gibt an, wie lange JMeter benötigen soll, um die volle Instanzen-Anzahl auf das Testobjekt zu leiten. Wenn 10 Instanzen genutzt werden und eine Anlaufzeit von 100 Sekunden angegeben ist, so startet JMeter innerhalb dieses Zeitraums alle 10 Sekunden eine weitere Instanz.
- Wiederholungszahl des Tests
Standardmäßig läuft eine Testgruppe unbegrenzt oft durch Ihre Elemente. Alternativ dazu kann die Anzahl der Durchläufe festgelegt werden. Wird 1 angegeben, so wird JMeter die Testgruppe nur einmal durchlaufen.
- ein frei wählbarer Name
- der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
- die Portnummer, auf welcher der Server getestet werden soll.
- der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.
- Instanzen-Anzahl
Die Instanzen Anzahl definiert, wie viele Instanzen gleichzeitig auf das zu testende Objekt zugreifen.
- Anlauf-Zeit
Eine Anlauf-Zeit gibt an, wie lange JMeter benötigen soll, um die volle Instanzen-Anzahl auf das Testobjekt zu leiten. Wenn 10 Instanzen genutzt werden und eine Anlaufzeit von 100 Sekunden angegeben ist, so startet JMeter innerhalb dieses Zeitraums alle 10 Sekunden eine weitere Instanz.
- Wiederholungszahl des Tests
Standardmäßig läuft eine Testgruppe unbegrenzt oft durch Ihre Elemente. Alternativ dazu kann die Anzahl der Durchläufe festgelegt werden. Wird 1 angegeben, so wird JMeter die Testgruppe nur einmal durchlaufen.
- ein frei wählbarer Name
- der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
- die Portnummer, auf welcher der Server getestet werden soll.
- der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.
Tools für Performance- und Lasttests
Tools für Performance- und Lasttests
Tools für Performance- und Lasttests
Tools für Performance- und Lasttests
Tools für Performance- und Lasttests
Tools für Performance- und Lasttests
Als Schwerpunkt dieser Arbeit wird die Auswahl an Programmen, welche aus dem Bereich der GNU-Lizenz oder anderen freien Varianten stammen, vorgestellt. Ergänzend sollen zwei kommerzielle Lösungen kurz angesprochen werden, da diese in ihrem Leistungsumfang den meisten freien Tests weit überlegen sind.
[Win03] stellt die Hauptgrundlage der folgenden Recherche dar, da hier die Autoren verschiedenste Tools aufführen. Diese sind weniger im Anwendungsbereich der Whitebox-Tests angesiedelt, und können im konkreten Fall des Amacont-Projektes an zwei Stellen angelegt werden: Zum Einen sollen komplette Black-Box-Tests die durchschnittliche Webdienst-Bearbeitungszeit r einschließlich Wartezeit errechnen. Zum Zweiten zeigen Grey-Box - Tests direkt am Service die durchschnittliche Webdienst-Bearbeitungszeit s und daraus resultierend die durchschnittliche Webservice-Rate µ= 1/s an ausgewählten Beispielen.
Um diese beiden Grundprinzipien besser zu verstehen und einen Überblick über den grundlegenden Aufbau eines Performance-Testtools zu erlangen, wird folgend exemplarisch das Programm Apache Jakarta JMeter ausführlicher erläutert. Es soll dabei als kompletter Black-Box-Test auftreten, da das genutzte Server-System ohne genaue Kenntnisse des Gesamtaufbaus getestet und lediglich die Größe r, also die durchschnittliche Webbearbeitungszeit inklusive Wartezeit, untersucht wird.
Als Gegensatz dazu und vollständige Grey-Box-Test-Variante wird daraufhin auf die Decorator-Technik von JUnit und JUnitPerf zur Unterstützung der Testgetriebenen Programmierung kurz eingegangen. Sie motiviert jede Änderung des Programmverhaltens zuvor durch einen automatisierten Test und führt so die zuvor adHoc-motivierte Programmiertätigkeit zu einem methodischen Vorgehen.
Somit soll sich folgend von außen an das Projekt der Performanztestung herangetastet werden, um im späteren Verlauf den inneren Aufbau besser zu verstehen und die Geschwindigkeit an einzelnen Komponenten zu verbessern. Im Kapitel 5 wird auf diese Erkenntnisse aufbauend eine konkrete Änderung innerhalb der Amacont-Architektur erläutert werden, welche gleichzeitig den praktischen Anteil dieser Belegarbeit darstellt.
Apache Jakarta JMeter
JMeter ist ein Werkzeug zum Ausführen von Lasttests in Client/Server-Anwendungen. Dabei wird mittels Zusammenstellen eines Testplanes spezifiziert, welche Teile der Anwendung durchlaufen werden sollen, um konkrete Ergebnisse über das Antwort-Zeit-Verhalten zu bekommen.
Graph-Visualizer des Apache JMeter
Mit Hilfe von Testplänen werden dabei die Testschritte beschrieben, welche JMeter durchlaufen muss. Ein kompletter Testplan besteht nach [Apa04] aus einem oder mehreren Testschritten, Logik-Komponenten, Listener, Sampler, Timer, Assertions und Konfigurationselementen.
Komponenten von JMeter
Ein jeder Testplan beginnt mit Testgruppen (ThreadGroups). Alle Elemente eines Testplans werden unter einer Testgruppe angeordnet, welche die dazugehörige Anzahl der Instanzen, welche JMeter zum Ausführen des gewünschten Tests nutzt, angibt. Es sind die folgenden Optionen anzugeben:
Als nächstes folgen in einer Testgruppe verschiedene Controller. Diese sind in 2 Arten unterteilt: Sampler und Logik-Controller.
Sampler geben dabei die Art des Requests an. Ein http-Request-Sampler sendet beispielsweise Requests unter Nutzung des HTTP-Protokolls. Requests können weiterhin durch Hinzufügen eines oder mehrerer Konfigurationselemente zu einem Sampler angepasst werden.
Über Logik-Controller kann die Logik angepasst werden, welche JMeter zur Entscheidung nutzt, wann ein Request gesendet wird. So kann beispielsweise ein Interleave Logik-Controller genutzt werden, um zwischen 2 HTTP-Request-Samplern zu wechseln. Ein weiterer Logik-Kontroller, der “Modification Manager”, erlaubt das Verändern eines Request-Ergebnisses.
Zur Veranschaulichung beziehen wir die Controller-Thematik kurz auf das Beispiel der Amacont-Architektur. Hier wird beispielsweise zunächst ein “Once-Only-Controller” zum Einsatz kommen, welcher den Login-Request (ein http-Request) an das System sendet. Nach erfolgreichem Login in das System wird durch einen weiteren Sampler auf eine zu testende Seite gewechselt werden. Dies ist ein einfacher Request, welcher durch keinerlei Logik gefiltert werden muss. Nach dem Laden dieser gewünschten Testseite können dann abwechselnd bestimmte Anfragen gestellt werden, welche ein “Interleave Controller” kontrolliert und steuert.
Während der Test-Durchläufe werden Informationen angesammelt. Listener stellen diese zur Verfügung. Der einfachste Vertreter ist dabei der “Graph Result Listener”, welcher die Antwortzeiten in einem Graphen wiedergibt. Listener stellen graphische Sichten auf die erhaltenen Daten zur Verfügung. Ebenfalls können durch sie gesammelte Daten in einer Datei für die spätere Anwendung gespeichert werden. Dafür stellt jeder Vertreter in JMeter ein Feld zur Verfügung, in welches der entsprechende Dateiname eingetragen werden kann.
Für gewöhnlich sendet JMeter Anfragen ohne entsprechende Wartezeiten. Da das Absetzen zu vieler Anfragen in einer sehr kurzen Zeit zu einer Überlastung des Servers führen kann, ist das Einfügen einer Verzögerung sinnvoll. Der Timer übernimmt diese Aufgabe und hält die definierte Wartezeit zwischen verschiedenen Requests ein. Bei mehreren in Reihe geschalteten Timern wird die Summe der Pausen gebildet und als Wartezeit definiert.
Assertions wiederum erlauben Behauptungen über bestimmte Test-Antworten des Servers. Bei der Benutzung von Assertions kann essentiell getestet werden, dass die Anwendung genau so antwortet, wie dies erwartet wird. Beispielsweise kann behauptet werden, dass eine Antwort auf eine bestimmte Anfrage einen bestimmten Textteil enthalten muss. Der zu suchende Text kann dabei als regulärer Ausdruck im Perl-Style angegeben werden, welcher entweder in der Antwort enthalten sein muss, oder ob der gesamte Response darauf passen soll. Wird eine Behauptung nicht erfüllt, so wird der betreffende Test als fehlgeschlagen gekennzeichnet. Um das Behauptungs-Ergebnis zu sehen, muss ein “Assertion-Listener” zur Testgruppe hinzugefügt werden.
Ein Konfigurationselement (configuration element) arbeitet ähnlich einem Sampler. Wenn gleich es auch (mit Ausnahme des http Proxy Servers) keinen Request sendet, so kann es Requests hinzufügen oder verändern. Auf ein Konfigurationselement ist lediglich innerhalb des eigenen Baumzweiges ein Zugriff möglich. Wenn also ein “HTTP Cookie Manager” innerhalb eines “Simple Logic Controllers” gelegt wird, so ist er nur von den “HTTP Request Controllern” innerhalb dieses “Simple Logic Controllers” abfragbar.
Testplanaufstellung unter JMeter
Im Beispiel könnten demnach “Web Page 1” und “Web Page 2” auf den “Cookie Manager” zugreifen, jedoch nicht “Web Page 3”.
Pre-Prozessoren ermöglichen die Ausführung von Aktionen, bevor der Sampler-Request beginnt. Wenn ein Pre-Prozessor an ein Sampler-Element angefügt wird, so wird es kurz vor dem Starten des Sampler-Requestes ausgeführt. Er wird daher oft verwendet, um Einstellungen am Sample Request zu ändern, bevor er startet, oder um Variablen zu aktualisieren, welche nicht aus dem Response-Text extrahiert wurden.
Ein Post-Prozessor-Element führt parallel dazu Aktionen kurz nach dem Sampler-Request aus. Der Post-Prozessor wird meistens zur Auswertung von Response-Daten genutzt, oft, um daraus Werte zu extrahieren.
Erstellen eines Web-Testplanes
Wie bereits unter 2.2.1.1 kurz angesprochen, beschreibt also ein Testplan eine Serie von Testschritten, die JMeter nacheinander ausführt. Ein kompletter Testplan wird dabei aus einem oder mehreren Testgruppen bestehen.
Der erste Schritt des Testplans ist das Hinzufügen eines Testgruppen-Elementes. Dieser gibt JMeter Informationen über die Anzahl der zu simulierenden Nutzer, wie viele Anfragen sie senden und wie oft sie das tun sollen. Dies stellt die Grundeinstellungen einer Testgruppe dar.
Hinzufuegen einer Test-Gruppen in JMeter
Nach der Eingabe eines aussagekräftigeren Namens für die Testgruppe folgt die Anzahl der Nutzer, die Anlaufzeit sowie die Wiederholungsanzahl. Über den “Scheduler” kann eine feste Start- und Ende-Zeit für den Test angegeben werden.
Nachdem die Nutzer definiert sind, folgt die Angabe der Aufträge, welche sie abarbeiten. Zunächst werden dazu Grundeinstellungen vorgenommen, auf welche später durch spezielle HTTP-Request-Elemente als Standard-Werte zurückgegriffen werden sollen.
Dies sind im Einzeln
Request-Grundeinstellungen in JMeter
An dieser Stelle wird aufgrund des Cookie-gestützten Amacont-Projekts der bereits erwähnte “HTTP Cookie Manager” in den Testplan eingefügt. Dadurch wird sichergestellt, dass jeder Thread seinen eigenen Session-Cookie bekommt, welcher über alle HTTP-Request Objekte geteilt wird.
Als nächstes folgen auf einzelne Requests spezialisierte Einstellungen.
Der Servername bzw. die IP kann hier weggelassen werden, da diese bereits bei den Voreinstellungen eingetragen wurde, ebenso die Port-Nummer. Angegeben werden können hier weiterhin das Protokoll, die Art der Parameterübergabe sowie der genaue Seitenaufruf. Ebenfalls kann eine zu übertragende Seite mit passendem MIME-Typ ausgestattet werden.
http-Request-Einstellungen in JMeter
Falls die User-Session nicht durch Cookies sondern per URL-Rewriting weitergegeben werden würde, käme der “HTTP-URL-Rewriting Modifier” zum Einsatz. Hierbei würde der Name der Session-ID eingetragen, so dass JMeter diesen finden und an jeden Request anhängen könnte. Falls dieser bereits einen Parameter besäße, würde dieser überschrieben werden.
URL-Rewrite-Veränderung in JMeter
Um die erzielten Ergebnisse in einer Datei zu speichern und graphisch darzustellen, folgt der “Graph Result Listener”. Bei diesem ist die gewünschte Datei zu spezifizieren, ebenso wie die anzuzeigenden Kurven. Dazu gibt es die Möglichkeiten der gesamten Daten-Darstellung, des Durchschnittswertes, des Mittelwertes, der Abweichung und des Datendurchsatzes.
Graph-Visualizer des Apache JMeter
Um den Testplan nun zu starten, genügt das Aufrufen des “Run”-Buttons. Falls das Ergebnis in einer Datei gespeichert wurde, kann diese nachträglich in einem Visualizer geöffnet werden. Jeder Visualizer zeigt dabei das Ergebnis in der vorher definierten Art und Weise.
Startseite “The Grinder”
Dieses Tool ist ein Framework, um Test-Skripte über eine bestimmte Anzahl von Maschinen arbeiten zu lassen. Es gibt damit die Möglichkeit, mit mehreren Rechnern gleichzeitig und synchronisiert auf einen zu testenden Rechner zuzugreifen und somit eine höhere Last auf diesen ausüben zu können. Er ist daher in die Gruppe der kompletten Black-Boxtests einzuordnen und JMeter sehr ähnlich.
Ein Unterschied besteht allerdings zum Einen in der Drei-Schichten-Architektur dieses Frameworks, welche sich aus den Arbeits-Prozessen, den Agenten-Prozessen und der Konsole zusammensetzt.
Funktionsweise von “The Grinder”
Die Arbeitsprozesse interpretieren dabei als weiteren Unterschied Jython-Testskripte und führen die darin beschriebenen Tests mit einer vorher definierten Anzahl von Arbeits-Threads aus. Die Agenten-Prozesse steuern die Arbeiter-Prozesse. Dazu läuft ein Agenten-Prozess auf jeder Client-Maschine. Zur Koordination dieser Prozesse nutzt der Anwender die Konsole, welche ebenso die einzelnen Prozesse vereinigt und die Statistiken präsentiert.
Da "The Grinder", wie auch JMeter, in Java geschrieben ist, stellt jeder dieser Prozesse eine "Java Virtual Machine" (JVM) dar. Für Hochleistungstest werden Agenten-Prozesse auf jedem Client-Rechner gestartet. Die durch diese gestarteten Arbeiter-Prozesse können von der Konsole aus kontrolliert und aufgezeichnet werden.
Ein "Test" ist hierbei ebenfalls eine Einheit von Tätigkeiten, von welchen Statistiken aufgezeichnet werden. Die Spezifikation der zu startenden Tests gibt das jeweilige Jython-Testskript an.
Das Skript wird, ähnlich dem Testplan unter JMeter, mehrmals in typischen Testszenarien ausgeführt. Jeder Arbeiterprozess hat dabei eine Anzahl von Arbeiter-Threads, und jeder Thread ruft das Skript mehrmals auf, wobei ein einzelner Aufruf des Skripts dabei als “run” bezeichnet wird.
JStress als architektur-unabhängiges Tools führt ebenso mittels verschiedener, verteilter Agenten, zentral gesteuert Testläufe durch. Es liegt in der Version 0.3 bereit, wird aber auf Grund der geringen Entwicklungshöhe in diesem Beleg nicht weiter betrachtet.
PerfectLoad kann mit mehreren tausend Nutzern, die konkurrierend HTTP-Requests abschicken, Belastungstests durchführen.
Ansichten von ”PerfectLoad”
Die dabei genutzten Requests werden vorher durch Live-Interaktion aufgezeichnet und als XML abgespeichtert. Es erleichtert somit im Gegensatz zum Referenzobjekt JMeter die Testplan-Einrichtung und Portabilität.
Das kleine Tool unterstützt ebenfalls Cookies und gibt die Möglichkeit, die Daten eines Requests eines jeweiligen virtuellen Nutzers mit Daten aus einem Daten-Pool zu manipulieren. JMeter kann diese stochastischen Zugriffe aktuell nicht emulieren. PerfectLoad ermittelt daraufhin anhand der Anforderungen, ob die getestete Anwendung diesen standhält.
Eine nützliche Option ist die Hilfe, ob sich ein etwaig gezeigtes Problem eher durch neue Hardware oder eine Software-Verbesserung beheben lässt.
Das Tool ist für bis zu 5 Nutzer kostenlos, bei kommerziellem Gebrauch sind entsprechende Lizenzen zu kaufen. Nähere Informationen befinden sich dabei unter [Per04]
Da die genannten Tools nicht spezifischer auf die Server-Architektur eingehen, können entsprechende Eigenschaften nicht näher untersucht werden. Daher wird nun zunächst eine einfache Methode zur Identifizierung der benötigten Zeit innerhalb der Cocoon- Ablaufreihenfolge aufgezeigt. Mit den daraufhin vorgestellten Werkzeugen können nun einzelne Java-Transformatoren genauer überprüft und entsprechend angepasst werden.
Diese einfache Methode stellt einen Java-Transformator dar, welcher die Zeit zwischen erstem und zweitem Aufruf misst. Die ermittelten Ergebnisse werden in einer externen Datei gespeichert und können am einfachsten durch ein entsprechendes Excel-Skript visualisiert werden. Bisherige Messungen an der Amacont-Architektur wurden durch dieses Tool erstellt und werden als Vergleichswerte in folgenden Kapiteln herangezogen.
Der Vorteil von JUnit-Tests besteht im Grey-Box-Ansatz. Die entsprechenden Tests werden als Dekorator-Klassen parallel zur eigentlichen Anwendung erstellt. Sie erlauben damit die sofortige Überprüfung des bearbeiteten Code-Abschnittes auf Erfüllung der Anforderungen.
JUnit im Eclipse IDE
JUnitPerf ist eine Sammlung von JUnit “Test-Dekorierer”, um die Performance und Skalierbarkeit der Funktionalität bei bereits bestehenden JUnit-Tests durchzuführen. Diese Erweiterung umfasst den “TimedTest”, einen Test-Dekorierer, welcher Tests mit Zeitbeschränkung der Durchführung ablaufen lässt, den “LoadTest”, der eine simulierten Anzahl von konkurrierenden Nutzern und Iterationen durchführt sowie den “ThreadedTest”, der einen Test in einem eigenen Thread startet, was die Zeitmessung erlaubt.
Der Einsatz von JUnit mit JUnitPerf ermöglicht bereits in frühen Entwicklungsstadien die Kontrolle der Skalierbarkeit. JUnit ist im Eclipse-IDE ab Version 3.0 integriert.
Eine Neuerscheinung, welche beiden Test-Suites eine kostenfreie Alternative gegenüberstellt, ist das Hyades Framework, welches unter dem Eclipse IDE eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Aufgrund der zugrunde liegenden “Common Public Licence” wird es näher beleuchtet.
Die JProbe-Suite (Version 5.0.1) von Quest Software beinhaltet neben der Zeitmessung eine Code-Coverage-Analyse und Deadlock-Erkennung. Die Speicheranalyse (vergleiche “EJP”) übernimmt der zur Suite gehörende Memory Debugger. Der Baum aufgerufener Klassen und Funktionen wird dabei als Call-Graph dargestellt, wo selektiv für jede Methode die Aufrufer oder aufgerufene Methode ein- und ausgeblendet oder die Anzeige auf einen bestimmten Pfad reduziert werden kann. Zu jedem Knoten im Graphen, der immer eine Methode darstellt, zeigt ein PopUp detaillierte Informationen. Weiterhin gibt es eine Liste, die alle Methoden mit ihrer Ausführungszeit und der Anzahl der Aufrufe auflistet.
Der Preis von 4255 Dollar ist bei diesem Produkt trotz großer Leistungsvielfalt nicht gerechtfertigt.
Ähnlich wie das IDE, stellt das Eclipse - Projekt Hyades selbst ein Framework dar, welches eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Damit soll [Sto04] folgend eine Interoperabilität zwischen Testwerkzeugen verschiedener Hersteller gewährleistet werden, wie auch eine schnellere Entwicklung innovativer Testwerkzeuge durch Wiederverwendung stets benötigter Komponenten.
Profiling
Die Grundfunktionalität des Profilings bei Hyades unterscheidet sich kaum von der kommerzieller Programme. Man kann Prozesse direkt aus Eclipse starten als sich auch nachträgliche mit laufenden Prozessen verbinden. Dabei können alle über das JVMPI erhältlichen Informationen gesammelt und analysiert werden, beispielsweise eine tabellarische Darstellung von Art und Anzahl der erzeugten sowie gerade existierenden Objekte, inklusive deren Größe im Speicher. Die Darstellung in der Notation eines UML2-Sequence-Diagramms ist ebenso möglich.
Hyades Ausführungsverlauf
Weiterhin können alle Methodenaufrufe und die Dauer ihrer Ausführung ausgewertet werden. Aus der Auswertung lässt sich der entsprechende Sourcecode anzeigen, so dass benötigte Änderungen zielgenau setztbar sind.
Log- und Trace-Analyse
Eine Besonderheit von Hyades stellt das “Logging Framework” dar, mit dem sich Ereignisse aus verschiedenen Quellen miteinander korrelieren lassen sollen. So können beispielsweise Einträge aus dem Logfile eines Applikationsservers mit der Dauer eines Requests in einem entfernt laufenden Java-Client überlagert werden. Die dabei ersichtliche Ursache - Wirkung - Beziehung erleichtert es deutlich, den Grund von Problemen zu erkennen.
Test browser-basierender Applikationen
Diese Funktionalität ist Jakarta JMeter sehr ähnlich. Allerdings bietet die Konfiguration beträchtliche Erleichterungen gegenüber JMeter. So kann ein Test einfach als Makro beim Durchsuchen der Website mit Hilfe des “Internet Explorers” aufgezeichnet werden. Durch Schliessen des Browser öffnet sich nun eine Übersicht der ausgeführten Requests, welche nachbearbeitet, in Schleifen mehrmals ausgeführt, und einem Datenpool zugeführt werden kann. Datenpools ermöglichen stochastische Zugriffe und somit die unter Kapitel 1.2 genannte Nutzeremulierung mit Ausschalten evtl. serverseitiger Caching-Methoden.
JUnit
Das bereits genannte JUnit ist ebenso vollständig in das Hyades-Framework implementiert und unterstützt eine wizardgesteuerte Test-Erstellung, die JavaCode-Generierung sowie die JUnit-Test-Auswertung.
Wie bei einem Framework üblich, lässt sich Hyades an allen Stellen durch eigene Funktionen erweitern. Dazu gehören unter anderem Parser für eigene Logfiles und Algorithmen zur Korrelation mehrerer Datenquellen.
Die soeben betrachteten Werkzeuge stellen einen Querschnitt durch das zurzeit verfügbare Angebot dar, besitzen jedoch auf Grund der Heterogenität des Entwicklungsumfeldes keinerlei Anspruch auf Vollständigkeit. Um einen schnellen Überblick zu ermöglichen, folgt nun nochmals eine Zusammenfassung.
| Bezeichnung | Hersteller | Plattform | Blackbox/ GreyBox | verteilte Anwend. / Multi-User/ Datenpool | grafische Auswertung | Lizenz /Kosten |
|---|---|---|---|---|---|---|
| Apache Jakarta JMeter | The Apache Foundation | Java | X / - | X/X/- | X | ASF |
| The Grinder | SourceForge | Java / Jython | X / - | X/X/- | X | GPL |
| JStress | ManAmplified | Java | X / - | X/X/- | - | GPL |
| PerfectLoad | Solnet solutions | Java / XML | X / - | -/X/X | X | ab 250 $ |
| JUnitPerf | Clarkware | Java-Decorateur | X / - | -/X/- | X | BSD-L |
| EJP | X | GPL | ||||
| Hyades | Eclipse.org | Eclipse-Framework | X / X | X/X/X | X | CPL |
| JProbe | Quest Software | - | X / X | X/X/X | X | 4255 $ |
| OptimizeIt! | Borland | Java | X / X | X/X/X | X | 2600 $ |
Für die folgenden Arbeiten am Amacont-Projekt wird eine Kombination der vorgestellten Werkzeuge genutzt. Jakarta JMeter wird dabei mit geeigneten Testplänen die Auslösung der HTTP-Requests übernehmen, da alle Test von einer einzelnen Maschine aus stattfinden.
Der Cocoon-Watch-Transformator wird während den Requests das Zeitverhalten einzelner Komponenten festhalten und hilft somit, zeitintensive Transformatoren zu identifizieren und deren Verhalten unter verschiedenen Konfigurationen zu testen (vergleiche Kapitel 3.4).
Identifizierte Transformatoren in Java können nun durch Speicherprofiling bzw. JUnitPerf-Komponenten auf Schwachstellen abgeklopft und ggf. angepasst werden. Da Tomcat ein Java-basierender Webserver ist, kann er grundsätzlich komplett speicherprofiliert werden. Man darf eine komplette Aufschlüsselung aller Prozesse erwarten und ebenfalls das Zusammenspiel paralleler Prozesse ergründen. Dies benötigt jedoch enorme Ressourcen und bedeutet einen extremen Geschwindigkeitsverlust, weswegen es als unpraktikabel angesehen wird.
Als Schwerpunkt dieser Arbeit wird die Auswahl an Programmen, welche aus dem Bereich der GNU-Lizenz oder anderen freien Varianten stammen, vorgestellt. Ergänzend sollen zwei kommerzielle Lösungen kurz angesprochen werden, da diese in ihrem Leistungsumfang den meisten freien Tests weit überlegen sind.
[Win03] stellt die Hauptgrundlage der folgenden Recherche dar, da hier die Autoren verschiedenste Tools aufführen. Diese sind weniger im Anwendungsbereich der Whitebox-Tests angesiedelt, und können im konkreten Fall des Amacont-Projektes an zwei Stellen angelegt werden: Zum Einen sollen komplette Black-Box-Tests die durchschnittliche Webdienst-Bearbeitungszeit r einschließlich Wartezeit errechnen. Zum Zweiten zeigen Grey-Box - Tests direkt am Service die durchschnittliche Webdienst-Bearbeitungszeit s und daraus resultierend die durchschnittliche Webservice-Rate µ= 1/s an ausgewählten Beispielen.
Um diese beiden Grundprinzipien besser zu verstehen und einen Überblick über den grundlegenden Aufbau eines Performance-Testtools zu erlangen, wird folgend exemplarisch das Programm Apache Jakarta JMeter ausführlicher erläutert. Es soll dabei als kompletter Black-Box-Test auftreten, da das genutzte Server-System ohne genaue Kenntnisse des Gesamtaufbaus getestet und lediglich die Größe r, also die durchschnittliche Webbearbeitungszeit inklusive Wartezeit, untersucht wird.
Als Gegensatz dazu und vollständige Grey-Box-Test-Variante wird daraufhin auf die Decorator-Technik von JUnit und JUnitPerf zur Unterstützung der Testgetriebenen Programmierung kurz eingegangen. Sie motiviert jede Änderung des Programmverhaltens zuvor durch einen automatisierten Test und führt so die zuvor adHoc-motivierte Programmiertätigkeit zu einem methodischen Vorgehen.
Somit soll sich folgend von außen an das Projekt der Performanztestung herangetastet werden, um im späteren Verlauf den inneren Aufbau besser zu verstehen und die Geschwindigkeit an einzelnen Komponenten zu verbessern. Im Kapitel 5 wird auf diese Erkenntnisse aufbauend eine konkrete Änderung innerhalb der Amacont-Architektur erläutert werden, welche gleichzeitig den praktischen Anteil dieser Belegarbeit darstellt.
Blackbox-Tests
Apache Jakarta JMeter
Apache Jakarta JMeter
JMeter ist ein Werkzeug zum Ausführen von Lasttests in Client/Server-Anwendungen. Dabei wird mittels Zusammenstellen eines Testplanes spezifiziert, welche Teile der Anwendung durchlaufen werden sollen, um konkrete Ergebnisse über das Antwort-Zeit-Verhalten zu bekommen.
Graph-Visualizer des Apache JMeter
Mit Hilfe von Testplänen werden dabei die Testschritte beschrieben, welche JMeter durchlaufen muss. Ein kompletter Testplan besteht nach [Apa04] aus einem oder mehreren Testschritten, Logik-Komponenten, Listener, Sampler, Timer, Assertions und Konfigurationselementen.
Komponenten von JMeter
Ein jeder Testplan beginnt mit Testgruppen (ThreadGroups). Alle Elemente eines Testplans werden unter einer Testgruppe angeordnet, welche die dazugehörige Anzahl der Instanzen, welche JMeter zum Ausführen des gewünschten Tests nutzt, angibt. Es sind die folgenden Optionen anzugeben:
Als nächstes folgen in einer Testgruppe verschiedene Controller. Diese sind in 2 Arten unterteilt: Sampler und Logik-Controller.
Sampler geben dabei die Art des Requests an. Ein http-Request-Sampler sendet beispielsweise Requests unter Nutzung des HTTP-Protokolls. Requests können weiterhin durch Hinzufügen eines oder mehrerer Konfigurationselemente zu einem Sampler angepasst werden.
Über Logik-Controller kann die Logik angepasst werden, welche JMeter zur Entscheidung nutzt, wann ein Request gesendet wird. So kann beispielsweise ein Interleave Logik-Controller genutzt werden, um zwischen 2 HTTP-Request-Samplern zu wechseln. Ein weiterer Logik-Kontroller, der “Modification Manager”, erlaubt das Verändern eines Request-Ergebnisses.
Zur Veranschaulichung beziehen wir die Controller-Thematik kurz auf das Beispiel der Amacont-Architektur. Hier wird beispielsweise zunächst ein “Once-Only-Controller” zum Einsatz kommen, welcher den Login-Request (ein http-Request) an das System sendet. Nach erfolgreichem Login in das System wird durch einen weiteren Sampler auf eine zu testende Seite gewechselt werden. Dies ist ein einfacher Request, welcher durch keinerlei Logik gefiltert werden muss. Nach dem Laden dieser gewünschten Testseite können dann abwechselnd bestimmte Anfragen gestellt werden, welche ein “Interleave Controller” kontrolliert und steuert.
Während der Test-Durchläufe werden Informationen angesammelt. Listener stellen diese zur Verfügung. Der einfachste Vertreter ist dabei der “Graph Result Listener”, welcher die Antwortzeiten in einem Graphen wiedergibt. Listener stellen graphische Sichten auf die erhaltenen Daten zur Verfügung. Ebenfalls können durch sie gesammelte Daten in einer Datei für die spätere Anwendung gespeichert werden. Dafür stellt jeder Vertreter in JMeter ein Feld zur Verfügung, in welches der entsprechende Dateiname eingetragen werden kann.
Für gewöhnlich sendet JMeter Anfragen ohne entsprechende Wartezeiten. Da das Absetzen zu vieler Anfragen in einer sehr kurzen Zeit zu einer Überlastung des Servers führen kann, ist das Einfügen einer Verzögerung sinnvoll. Der Timer übernimmt diese Aufgabe und hält die definierte Wartezeit zwischen verschiedenen Requests ein. Bei mehreren in Reihe geschalteten Timern wird die Summe der Pausen gebildet und als Wartezeit definiert.
Assertions wiederum erlauben Behauptungen über bestimmte Test-Antworten des Servers. Bei der Benutzung von Assertions kann essentiell getestet werden, dass die Anwendung genau so antwortet, wie dies erwartet wird. Beispielsweise kann behauptet werden, dass eine Antwort auf eine bestimmte Anfrage einen bestimmten Textteil enthalten muss. Der zu suchende Text kann dabei als regulärer Ausdruck im Perl-Style angegeben werden, welcher entweder in der Antwort enthalten sein muss, oder ob der gesamte Response darauf passen soll. Wird eine Behauptung nicht erfüllt, so wird der betreffende Test als fehlgeschlagen gekennzeichnet. Um das Behauptungs-Ergebnis zu sehen, muss ein “Assertion-Listener” zur Testgruppe hinzugefügt werden.
Ein Konfigurationselement (configuration element) arbeitet ähnlich einem Sampler. Wenn gleich es auch (mit Ausnahme des http Proxy Servers) keinen Request sendet, so kann es Requests hinzufügen oder verändern. Auf ein Konfigurationselement ist lediglich innerhalb des eigenen Baumzweiges ein Zugriff möglich. Wenn also ein “HTTP Cookie Manager” innerhalb eines “Simple Logic Controllers” gelegt wird, so ist er nur von den “HTTP Request Controllern” innerhalb dieses “Simple Logic Controllers” abfragbar.
Testplanaufstellung unter JMeter
Im Beispiel könnten demnach “Web Page 1” und “Web Page 2” auf den “Cookie Manager” zugreifen, jedoch nicht “Web Page 3”.
Pre-Prozessoren ermöglichen die Ausführung von Aktionen, bevor der Sampler-Request beginnt. Wenn ein Pre-Prozessor an ein Sampler-Element angefügt wird, so wird es kurz vor dem Starten des Sampler-Requestes ausgeführt. Er wird daher oft verwendet, um Einstellungen am Sample Request zu ändern, bevor er startet, oder um Variablen zu aktualisieren, welche nicht aus dem Response-Text extrahiert wurden.
Ein Post-Prozessor-Element führt parallel dazu Aktionen kurz nach dem Sampler-Request aus. Der Post-Prozessor wird meistens zur Auswertung von Response-Daten genutzt, oft, um daraus Werte zu extrahieren.
Erstellen eines Web-Testplanes
Wie bereits unter 2.2.1.1 kurz angesprochen, beschreibt also ein Testplan eine Serie von Testschritten, die JMeter nacheinander ausführt. Ein kompletter Testplan wird dabei aus einem oder mehreren Testgruppen bestehen.
Der erste Schritt des Testplans ist das Hinzufügen eines Testgruppen-Elementes. Dieser gibt JMeter Informationen über die Anzahl der zu simulierenden Nutzer, wie viele Anfragen sie senden und wie oft sie das tun sollen. Dies stellt die Grundeinstellungen einer Testgruppe dar.
Hinzufuegen einer Test-Gruppen in JMeter
Nach der Eingabe eines aussagekräftigeren Namens für die Testgruppe folgt die Anzahl der Nutzer, die Anlaufzeit sowie die Wiederholungsanzahl. Über den “Scheduler” kann eine feste Start- und Ende-Zeit für den Test angegeben werden.
Nachdem die Nutzer definiert sind, folgt die Angabe der Aufträge, welche sie abarbeiten. Zunächst werden dazu Grundeinstellungen vorgenommen, auf welche später durch spezielle HTTP-Request-Elemente als Standard-Werte zurückgegriffen werden sollen.
Dies sind im Einzeln
Request-Grundeinstellungen in JMeter
An dieser Stelle wird aufgrund des Cookie-gestützten Amacont-Projekts der bereits erwähnte “HTTP Cookie Manager” in den Testplan eingefügt. Dadurch wird sichergestellt, dass jeder Thread seinen eigenen Session-Cookie bekommt, welcher über alle HTTP-Request Objekte geteilt wird.
Als nächstes folgen auf einzelne Requests spezialisierte Einstellungen.
Der Servername bzw. die IP kann hier weggelassen werden, da diese bereits bei den Voreinstellungen eingetragen wurde, ebenso die Port-Nummer. Angegeben werden können hier weiterhin das Protokoll, die Art der Parameterübergabe sowie der genaue Seitenaufruf. Ebenfalls kann eine zu übertragende Seite mit passendem MIME-Typ ausgestattet werden.
http-Request-Einstellungen in JMeter
Falls die User-Session nicht durch Cookies sondern per URL-Rewriting weitergegeben werden würde, käme der “HTTP-URL-Rewriting Modifier” zum Einsatz. Hierbei würde der Name der Session-ID eingetragen, so dass JMeter diesen finden und an jeden Request anhängen könnte. Falls dieser bereits einen Parameter besäße, würde dieser überschrieben werden.
URL-Rewrite-Veränderung in JMeter
Um die erzielten Ergebnisse in einer Datei zu speichern und graphisch darzustellen, folgt der “Graph Result Listener”. Bei diesem ist die gewünschte Datei zu spezifizieren, ebenso wie die anzuzeigenden Kurven. Dazu gibt es die Möglichkeiten der gesamten Daten-Darstellung, des Durchschnittswertes, des Mittelwertes, der Abweichung und des Datendurchsatzes.
Graph-Visualizer des Apache JMeter
Um den Testplan nun zu starten, genügt das Aufrufen des “Run”-Buttons. Falls das Ergebnis in einer Datei gespeichert wurde, kann diese nachträglich in einem Visualizer geöffnet werden. Jeder Visualizer zeigt dabei das Ergebnis in der vorher definierten Art und Weise.
The Grinder
Startseite “The Grinder”
Dieses Tool ist ein Framework, um Test-Skripte über eine bestimmte Anzahl von Maschinen arbeiten zu lassen. Es gibt damit die Möglichkeit, mit mehreren Rechnern gleichzeitig und synchronisiert auf einen zu testenden Rechner zuzugreifen und somit eine höhere Last auf diesen ausüben zu können. Er ist daher in die Gruppe der kompletten Black-Boxtests einzuordnen und JMeter sehr ähnlich.
Ein Unterschied besteht allerdings zum Einen in der Drei-Schichten-Architektur dieses Frameworks, welche sich aus den Arbeits-Prozessen, den Agenten-Prozessen und der Konsole zusammensetzt.
Funktionsweise von “The Grinder”
Die Arbeitsprozesse interpretieren dabei als weiteren Unterschied Jython-Testskripte und führen die darin beschriebenen Tests mit einer vorher definierten Anzahl von Arbeits-Threads aus. Die Agenten-Prozesse steuern die Arbeiter-Prozesse. Dazu läuft ein Agenten-Prozess auf jeder Client-Maschine. Zur Koordination dieser Prozesse nutzt der Anwender die Konsole, welche ebenso die einzelnen Prozesse vereinigt und die Statistiken präsentiert.
Da "The Grinder", wie auch JMeter, in Java geschrieben ist, stellt jeder dieser Prozesse eine "Java Virtual Machine" (JVM) dar. Für Hochleistungstest werden Agenten-Prozesse auf jedem Client-Rechner gestartet. Die durch diese gestarteten Arbeiter-Prozesse können von der Konsole aus kontrolliert und aufgezeichnet werden.
Ein "Test" ist hierbei ebenfalls eine Einheit von Tätigkeiten, von welchen Statistiken aufgezeichnet werden. Die Spezifikation der zu startenden Tests gibt das jeweilige Jython-Testskript an.
Das Skript wird, ähnlich dem Testplan unter JMeter, mehrmals in typischen Testszenarien ausgeführt. Jeder Arbeiterprozess hat dabei eine Anzahl von Arbeiter-Threads, und jeder Thread ruft das Skript mehrmals auf, wobei ein einzelner Aufruf des Skripts dabei als “run” bezeichnet wird.
JStress
JStress als architektur-unabhängiges Tools führt ebenso mittels verschiedener, verteilter Agenten, zentral gesteuert Testläufe durch. Es liegt in der Version 0.3 bereit, wird aber auf Grund der geringen Entwicklungshöhe in diesem Beleg nicht weiter betrachtet.
PerfectLoad
PerfectLoad kann mit mehreren tausend Nutzern, die konkurrierend HTTP-Requests abschicken, Belastungstests durchführen.
Ansichten von ”PerfectLoad”
Die dabei genutzten Requests werden vorher durch Live-Interaktion aufgezeichnet und als XML abgespeichtert. Es erleichtert somit im Gegensatz zum Referenzobjekt JMeter die Testplan-Einrichtung und Portabilität.
Das kleine Tool unterstützt ebenfalls Cookies und gibt die Möglichkeit, die Daten eines Requests eines jeweiligen virtuellen Nutzers mit Daten aus einem Daten-Pool zu manipulieren. JMeter kann diese stochastischen Zugriffe aktuell nicht emulieren. PerfectLoad ermittelt daraufhin anhand der Anforderungen, ob die getestete Anwendung diesen standhält.
Eine nützliche Option ist die Hilfe, ob sich ein etwaig gezeigtes Problem eher durch neue Hardware oder eine Software-Verbesserung beheben lässt.
Das Tool ist für bis zu 5 Nutzer kostenlos, bei kommerziellem Gebrauch sind entsprechende Lizenzen zu kaufen. Nähere Informationen befinden sich dabei unter [Per04]
Greybox-Tests
Da die genannten Tools nicht spezifischer auf die Server-Architektur eingehen, können entsprechende Eigenschaften nicht näher untersucht werden. Daher wird nun zunächst eine einfache Methode zur Identifizierung der benötigten Zeit innerhalb der Cocoon- Ablaufreihenfolge aufgezeigt. Mit den daraufhin vorgestellten Werkzeugen können nun einzelne Java-Transformatoren genauer überprüft und entsprechend angepasst werden.
Cocoon-Watch-Transformator
Diese einfache Methode stellt einen Java-Transformator dar, welcher die Zeit zwischen erstem und zweitem Aufruf misst. Die ermittelten Ergebnisse werden in einer externen Datei gespeichert und können am einfachsten durch ein entsprechendes Excel-Skript visualisiert werden. Bisherige Messungen an der Amacont-Architektur wurden durch dieses Tool erstellt und werden als Vergleichswerte in folgenden Kapiteln herangezogen.
Extensible Java Profiler (EJP)
JUnitPerf
Der Vorteil von JUnit-Tests besteht im Grey-Box-Ansatz. Die entsprechenden Tests werden als Dekorator-Klassen parallel zur eigentlichen Anwendung erstellt. Sie erlauben damit die sofortige Überprüfung des bearbeiteten Code-Abschnittes auf Erfüllung der Anforderungen.
JUnit im Eclipse IDE
JUnitPerf ist eine Sammlung von JUnit “Test-Dekorierer”, um die Performance und Skalierbarkeit der Funktionalität bei bereits bestehenden JUnit-Tests durchzuführen. Diese Erweiterung umfasst den “TimedTest”, einen Test-Dekorierer, welcher Tests mit Zeitbeschränkung der Durchführung ablaufen lässt, den “LoadTest”, der eine simulierten Anzahl von konkurrierenden Nutzern und Iterationen durchführt sowie den “ThreadedTest”, der einen Test in einem eigenen Thread startet, was die Zeitmessung erlaubt.
Der Einsatz von JUnit mit JUnitPerf ermöglicht bereits in frühen Entwicklungsstadien die Kontrolle der Skalierbarkeit. JUnit ist im Eclipse-IDE ab Version 3.0 integriert.
Test-Suites
Eine Neuerscheinung, welche beiden Test-Suites eine kostenfreie Alternative gegenüberstellt, ist das Hyades Framework, welches unter dem Eclipse IDE eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Aufgrund der zugrunde liegenden “Common Public Licence” wird es näher beleuchtet.
JProbe
Die JProbe-Suite (Version 5.0.1) von Quest Software beinhaltet neben der Zeitmessung eine Code-Coverage-Analyse und Deadlock-Erkennung. Die Speicheranalyse (vergleiche “EJP”) übernimmt der zur Suite gehörende Memory Debugger. Der Baum aufgerufener Klassen und Funktionen wird dabei als Call-Graph dargestellt, wo selektiv für jede Methode die Aufrufer oder aufgerufene Methode ein- und ausgeblendet oder die Anzeige auf einen bestimmten Pfad reduziert werden kann. Zu jedem Knoten im Graphen, der immer eine Methode darstellt, zeigt ein PopUp detaillierte Informationen. Weiterhin gibt es eine Liste, die alle Methoden mit ihrer Ausführungszeit und der Anzahl der Aufrufe auflistet.
Der Preis von 4255 Dollar ist bei diesem Produkt trotz großer Leistungsvielfalt nicht gerechtfertigt.
Hyades
Ähnlich wie das IDE, stellt das Eclipse - Projekt Hyades selbst ein Framework dar, welches eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Damit soll [Sto04] folgend eine Interoperabilität zwischen Testwerkzeugen verschiedener Hersteller gewährleistet werden, wie auch eine schnellere Entwicklung innovativer Testwerkzeuge durch Wiederverwendung stets benötigter Komponenten.
Profiling
Die Grundfunktionalität des Profilings bei Hyades unterscheidet sich kaum von der kommerzieller Programme. Man kann Prozesse direkt aus Eclipse starten als sich auch nachträgliche mit laufenden Prozessen verbinden. Dabei können alle über das JVMPI erhältlichen Informationen gesammelt und analysiert werden, beispielsweise eine tabellarische Darstellung von Art und Anzahl der erzeugten sowie gerade existierenden Objekte, inklusive deren Größe im Speicher. Die Darstellung in der Notation eines UML2-Sequence-Diagramms ist ebenso möglich.
Hyades Ausführungsverlauf
Weiterhin können alle Methodenaufrufe und die Dauer ihrer Ausführung ausgewertet werden. Aus der Auswertung lässt sich der entsprechende Sourcecode anzeigen, so dass benötigte Änderungen zielgenau setztbar sind.
Log- und Trace-Analyse
Eine Besonderheit von Hyades stellt das “Logging Framework” dar, mit dem sich Ereignisse aus verschiedenen Quellen miteinander korrelieren lassen sollen. So können beispielsweise Einträge aus dem Logfile eines Applikationsservers mit der Dauer eines Requests in einem entfernt laufenden Java-Client überlagert werden. Die dabei ersichtliche Ursache - Wirkung - Beziehung erleichtert es deutlich, den Grund von Problemen zu erkennen.
Test browser-basierender Applikationen
Diese Funktionalität ist Jakarta JMeter sehr ähnlich. Allerdings bietet die Konfiguration beträchtliche Erleichterungen gegenüber JMeter. So kann ein Test einfach als Makro beim Durchsuchen der Website mit Hilfe des “Internet Explorers” aufgezeichnet werden. Durch Schliessen des Browser öffnet sich nun eine Übersicht der ausgeführten Requests, welche nachbearbeitet, in Schleifen mehrmals ausgeführt, und einem Datenpool zugeführt werden kann. Datenpools ermöglichen stochastische Zugriffe und somit die unter Kapitel 1.2 genannte Nutzeremulierung mit Ausschalten evtl. serverseitiger Caching-Methoden.
JUnit
Das bereits genannte JUnit ist ebenso vollständig in das Hyades-Framework implementiert und unterstützt eine wizardgesteuerte Test-Erstellung, die JavaCode-Generierung sowie die JUnit-Test-Auswertung.
Wie bei einem Framework üblich, lässt sich Hyades an allen Stellen durch eigene Funktionen erweitern. Dazu gehören unter anderem Parser für eigene Logfiles und Algorithmen zur Korrelation mehrerer Datenquellen.
Übersicht
Die soeben betrachteten Werkzeuge stellen einen Querschnitt durch das zurzeit verfügbare Angebot dar, besitzen jedoch auf Grund der Heterogenität des Entwicklungsumfeldes keinerlei Anspruch auf Vollständigkeit. Um einen schnellen Überblick zu ermöglichen, folgt nun nochmals eine Zusammenfassung.
| Bezeichnung | Hersteller | Plattform | Blackbox/ GreyBox | verteilte Anwend. / Multi-User/ Datenpool | grafische Auswertung | Lizenz /Kosten |
|---|---|---|---|---|---|---|
| Apache Jakarta JMeter | The Apache Foundation | Java | X / - | X/X/- | X | ASF |
| The Grinder | SourceForge | Java / Jython | X / - | X/X/- | X | GPL |
| JStress | ManAmplified | Java | X / - | X/X/- | - | GPL |
| PerfectLoad | Solnet solutions | Java / XML | X / - | -/X/X | X | ab 250 $ |
| JUnitPerf | Clarkware | Java-Decorateur | X / - | -/X/- | X | BSD-L |
| EJP | X | GPL | ||||
| Hyades | Eclipse.org | Eclipse-Framework | X / X | X/X/X | X | CPL |
| JProbe | Quest Software | - | X / X | X/X/X | X | 4255 $ |
| OptimizeIt! | Borland | Java | X / X | X/X/X | X | 2600 $ |
Zusammenfassung
Für die folgenden Arbeiten am Amacont-Projekt wird eine Kombination der vorgestellten Werkzeuge genutzt. Jakarta JMeter wird dabei mit geeigneten Testplänen die Auslösung der HTTP-Requests übernehmen, da alle Test von einer einzelnen Maschine aus stattfinden.
Der Cocoon-Watch-Transformator wird während den Requests das Zeitverhalten einzelner Komponenten festhalten und hilft somit, zeitintensive Transformatoren zu identifizieren und deren Verhalten unter verschiedenen Konfigurationen zu testen (vergleiche Kapitel 3.4).
Identifizierte Transformatoren in Java können nun durch Speicherprofiling bzw. JUnitPerf-Komponenten auf Schwachstellen abgeklopft und ggf. angepasst werden. Da Tomcat ein Java-basierender Webserver ist, kann er grundsätzlich komplett speicherprofiliert werden. Man darf eine komplette Aufschlüsselung aller Prozesse erwarten und ebenfalls das Zusammenspiel paralleler Prozesse ergründen. Dies benötigt jedoch enorme Ressourcen und bedeutet einen extremen Geschwindigkeitsverlust, weswegen es als unpraktikabel angesehen wird.
Als Schwerpunkt dieser Arbeit wird die Auswahl an Programmen, welche aus dem Bereich der GNU-Lizenz oder anderen freien Varianten stammen, vorgestellt. Ergänzend sollen zwei kommerzielle Lösungen kurz angesprochen werden, da diese in ihrem Leistungsumfang den meisten freien Tests weit überlegen sind.
[Win03] stellt die Hauptgrundlage der folgenden Recherche dar, da hier die Autoren verschiedenste Tools aufführen. Diese sind weniger im Anwendungsbereich der Whitebox-Tests angesiedelt, und können im konkreten Fall des Amacont-Projektes an zwei Stellen angelegt werden: Zum Einen sollen komplette Black-Box-Tests die durchschnittliche Webdienst-Bearbeitungszeit r einschließlich Wartezeit errechnen. Zum Zweiten zeigen Grey-Box - Tests direkt am Service die durchschnittliche Webdienst-Bearbeitungszeit s und daraus resultierend die durchschnittliche Webservice-Rate µ= 1/s an ausgewählten Beispielen.
Um diese beiden Grundprinzipien besser zu verstehen und einen Überblick über den grundlegenden Aufbau eines Performance-Testtools zu erlangen, wird folgend exemplarisch das Programm Apache Jakarta JMeter ausführlicher erläutert. Es soll dabei als kompletter Black-Box-Test auftreten, da das genutzte Server-System ohne genaue Kenntnisse des Gesamtaufbaus getestet und lediglich die Größe r, also die durchschnittliche Webbearbeitungszeit inklusive Wartezeit, untersucht wird.
Als Gegensatz dazu und vollständige Grey-Box-Test-Variante wird daraufhin auf die Decorator-Technik von JUnit und JUnitPerf zur Unterstützung der Testgetriebenen Programmierung kurz eingegangen. Sie motiviert jede Änderung des Programmverhaltens zuvor durch einen automatisierten Test und führt so die zuvor adHoc-motivierte Programmiertätigkeit zu einem methodischen Vorgehen.
Somit soll sich folgend von außen an das Projekt der Performanztestung herangetastet werden, um im späteren Verlauf den inneren Aufbau besser zu verstehen und die Geschwindigkeit an einzelnen Komponenten zu verbessern. Im Kapitel 5 wird auf diese Erkenntnisse aufbauend eine konkrete Änderung innerhalb der Amacont-Architektur erläutert werden, welche gleichzeitig den praktischen Anteil dieser Belegarbeit darstellt.
Blackbox-Tests
Apache Jakarta JMeter
Apache Jakarta JMeter
JMeter ist ein Werkzeug zum Ausführen von Lasttests in Client/Server-Anwendungen. Dabei wird mittels Zusammenstellen eines Testplanes spezifiziert, welche Teile der Anwendung durchlaufen werden sollen, um konkrete Ergebnisse über das Antwort-Zeit-Verhalten zu bekommen.
Graph-Visualizer des Apache JMeter
Mit Hilfe von Testplänen werden dabei die Testschritte beschrieben, welche JMeter durchlaufen muss. Ein kompletter Testplan besteht nach [Apa04] aus einem oder mehreren Testschritten, Logik-Komponenten, Listener, Sampler, Timer, Assertions und Konfigurationselementen.
Komponenten von JMeter
Ein jeder Testplan beginnt mit Testgruppen (ThreadGroups). Alle Elemente eines Testplans werden unter einer Testgruppe angeordnet, welche die dazugehörige Anzahl der Instanzen, welche JMeter zum Ausführen des gewünschten Tests nutzt, angibt. Es sind die folgenden Optionen anzugeben:
Als nächstes folgen in einer Testgruppe verschiedene Controller. Diese sind in 2 Arten unterteilt: Sampler und Logik-Controller.
Sampler geben dabei die Art des Requests an. Ein http-Request-Sampler sendet beispielsweise Requests unter Nutzung des HTTP-Protokolls. Requests können weiterhin durch Hinzufügen eines oder mehrerer Konfigurationselemente zu einem Sampler angepasst werden.
Über Logik-Controller kann die Logik angepasst werden, welche JMeter zur Entscheidung nutzt, wann ein Request gesendet wird. So kann beispielsweise ein Interleave Logik-Controller genutzt werden, um zwischen 2 HTTP-Request-Samplern zu wechseln. Ein weiterer Logik-Kontroller, der “Modification Manager”, erlaubt das Verändern eines Request-Ergebnisses.
Zur Veranschaulichung beziehen wir die Controller-Thematik kurz auf das Beispiel der Amacont-Architektur. Hier wird beispielsweise zunächst ein “Once-Only-Controller” zum Einsatz kommen, welcher den Login-Request (ein http-Request) an das System sendet. Nach erfolgreichem Login in das System wird durch einen weiteren Sampler auf eine zu testende Seite gewechselt werden. Dies ist ein einfacher Request, welcher durch keinerlei Logik gefiltert werden muss. Nach dem Laden dieser gewünschten Testseite können dann abwechselnd bestimmte Anfragen gestellt werden, welche ein “Interleave Controller” kontrolliert und steuert.
Während der Test-Durchläufe werden Informationen angesammelt. Listener stellen diese zur Verfügung. Der einfachste Vertreter ist dabei der “Graph Result Listener”, welcher die Antwortzeiten in einem Graphen wiedergibt. Listener stellen graphische Sichten auf die erhaltenen Daten zur Verfügung. Ebenfalls können durch sie gesammelte Daten in einer Datei für die spätere Anwendung gespeichert werden. Dafür stellt jeder Vertreter in JMeter ein Feld zur Verfügung, in welches der entsprechende Dateiname eingetragen werden kann.
Für gewöhnlich sendet JMeter Anfragen ohne entsprechende Wartezeiten. Da das Absetzen zu vieler Anfragen in einer sehr kurzen Zeit zu einer Überlastung des Servers führen kann, ist das Einfügen einer Verzögerung sinnvoll. Der Timer übernimmt diese Aufgabe und hält die definierte Wartezeit zwischen verschiedenen Requests ein. Bei mehreren in Reihe geschalteten Timern wird die Summe der Pausen gebildet und als Wartezeit definiert.
Assertions wiederum erlauben Behauptungen über bestimmte Test-Antworten des Servers. Bei der Benutzung von Assertions kann essentiell getestet werden, dass die Anwendung genau so antwortet, wie dies erwartet wird. Beispielsweise kann behauptet werden, dass eine Antwort auf eine bestimmte Anfrage einen bestimmten Textteil enthalten muss. Der zu suchende Text kann dabei als regulärer Ausdruck im Perl-Style angegeben werden, welcher entweder in der Antwort enthalten sein muss, oder ob der gesamte Response darauf passen soll. Wird eine Behauptung nicht erfüllt, so wird der betreffende Test als fehlgeschlagen gekennzeichnet. Um das Behauptungs-Ergebnis zu sehen, muss ein “Assertion-Listener” zur Testgruppe hinzugefügt werden.
Ein Konfigurationselement (configuration element) arbeitet ähnlich einem Sampler. Wenn gleich es auch (mit Ausnahme des http Proxy Servers) keinen Request sendet, so kann es Requests hinzufügen oder verändern. Auf ein Konfigurationselement ist lediglich innerhalb des eigenen Baumzweiges ein Zugriff möglich. Wenn also ein “HTTP Cookie Manager” innerhalb eines “Simple Logic Controllers” gelegt wird, so ist er nur von den “HTTP Request Controllern” innerhalb dieses “Simple Logic Controllers” abfragbar.
Testplanaufstellung unter JMeter
Im Beispiel könnten demnach “Web Page 1” und “Web Page 2” auf den “Cookie Manager” zugreifen, jedoch nicht “Web Page 3”.
Pre-Prozessoren ermöglichen die Ausführung von Aktionen, bevor der Sampler-Request beginnt. Wenn ein Pre-Prozessor an ein Sampler-Element angefügt wird, so wird es kurz vor dem Starten des Sampler-Requestes ausgeführt. Er wird daher oft verwendet, um Einstellungen am Sample Request zu ändern, bevor er startet, oder um Variablen zu aktualisieren, welche nicht aus dem Response-Text extrahiert wurden.
Ein Post-Prozessor-Element führt parallel dazu Aktionen kurz nach dem Sampler-Request aus. Der Post-Prozessor wird meistens zur Auswertung von Response-Daten genutzt, oft, um daraus Werte zu extrahieren.
Erstellen eines Web-Testplanes
Wie bereits unter 2.2.1.1 kurz angesprochen, beschreibt also ein Testplan eine Serie von Testschritten, die JMeter nacheinander ausführt. Ein kompletter Testplan wird dabei aus einem oder mehreren Testgruppen bestehen.
Der erste Schritt des Testplans ist das Hinzufügen eines Testgruppen-Elementes. Dieser gibt JMeter Informationen über die Anzahl der zu simulierenden Nutzer, wie viele Anfragen sie senden und wie oft sie das tun sollen. Dies stellt die Grundeinstellungen einer Testgruppe dar.
Hinzufuegen einer Test-Gruppen in JMeter
Nach der Eingabe eines aussagekräftigeren Namens für die Testgruppe folgt die Anzahl der Nutzer, die Anlaufzeit sowie die Wiederholungsanzahl. Über den “Scheduler” kann eine feste Start- und Ende-Zeit für den Test angegeben werden.
Nachdem die Nutzer definiert sind, folgt die Angabe der Aufträge, welche sie abarbeiten. Zunächst werden dazu Grundeinstellungen vorgenommen, auf welche später durch spezielle HTTP-Request-Elemente als Standard-Werte zurückgegriffen werden sollen.
Dies sind im Einzeln
Request-Grundeinstellungen in JMeter
An dieser Stelle wird aufgrund des Cookie-gestützten Amacont-Projekts der bereits erwähnte “HTTP Cookie Manager” in den Testplan eingefügt. Dadurch wird sichergestellt, dass jeder Thread seinen eigenen Session-Cookie bekommt, welcher über alle HTTP-Request Objekte geteilt wird.
Als nächstes folgen auf einzelne Requests spezialisierte Einstellungen.
Der Servername bzw. die IP kann hier weggelassen werden, da diese bereits bei den Voreinstellungen eingetragen wurde, ebenso die Port-Nummer. Angegeben werden können hier weiterhin das Protokoll, die Art der Parameterübergabe sowie der genaue Seitenaufruf. Ebenfalls kann eine zu übertragende Seite mit passendem MIME-Typ ausgestattet werden.
http-Request-Einstellungen in JMeter
Falls die User-Session nicht durch Cookies sondern per URL-Rewriting weitergegeben werden würde, käme der “HTTP-URL-Rewriting Modifier” zum Einsatz. Hierbei würde der Name der Session-ID eingetragen, so dass JMeter diesen finden und an jeden Request anhängen könnte. Falls dieser bereits einen Parameter besäße, würde dieser überschrieben werden.
URL-Rewrite-Veränderung in JMeter
Um die erzielten Ergebnisse in einer Datei zu speichern und graphisch darzustellen, folgt der “Graph Result Listener”. Bei diesem ist die gewünschte Datei zu spezifizieren, ebenso wie die anzuzeigenden Kurven. Dazu gibt es die Möglichkeiten der gesamten Daten-Darstellung, des Durchschnittswertes, des Mittelwertes, der Abweichung und des Datendurchsatzes.
Graph-Visualizer des Apache JMeter
Um den Testplan nun zu starten, genügt das Aufrufen des “Run”-Buttons. Falls das Ergebnis in einer Datei gespeichert wurde, kann diese nachträglich in einem Visualizer geöffnet werden. Jeder Visualizer zeigt dabei das Ergebnis in der vorher definierten Art und Weise.
The Grinder
Startseite “The Grinder”
Dieses Tool ist ein Framework, um Test-Skripte über eine bestimmte Anzahl von Maschinen arbeiten zu lassen. Es gibt damit die Möglichkeit, mit mehreren Rechnern gleichzeitig und synchronisiert auf einen zu testenden Rechner zuzugreifen und somit eine höhere Last auf diesen ausüben zu können. Er ist daher in die Gruppe der kompletten Black-Boxtests einzuordnen und JMeter sehr ähnlich.
Ein Unterschied besteht allerdings zum Einen in der Drei-Schichten-Architektur dieses Frameworks, welche sich aus den Arbeits-Prozessen, den Agenten-Prozessen und der Konsole zusammensetzt.
Funktionsweise von “The Grinder”
Die Arbeitsprozesse interpretieren dabei als weiteren Unterschied Jython-Testskripte und führen die darin beschriebenen Tests mit einer vorher definierten Anzahl von Arbeits-Threads aus. Die Agenten-Prozesse steuern die Arbeiter-Prozesse. Dazu läuft ein Agenten-Prozess auf jeder Client-Maschine. Zur Koordination dieser Prozesse nutzt der Anwender die Konsole, welche ebenso die einzelnen Prozesse vereinigt und die Statistiken präsentiert.
Da "The Grinder", wie auch JMeter, in Java geschrieben ist, stellt jeder dieser Prozesse eine "Java Virtual Machine" (JVM) dar. Für Hochleistungstest werden Agenten-Prozesse auf jedem Client-Rechner gestartet. Die durch diese gestarteten Arbeiter-Prozesse können von der Konsole aus kontrolliert und aufgezeichnet werden.
Ein "Test" ist hierbei ebenfalls eine Einheit von Tätigkeiten, von welchen Statistiken aufgezeichnet werden. Die Spezifikation der zu startenden Tests gibt das jeweilige Jython-Testskript an.
Das Skript wird, ähnlich dem Testplan unter JMeter, mehrmals in typischen Testszenarien ausgeführt. Jeder Arbeiterprozess hat dabei eine Anzahl von Arbeiter-Threads, und jeder Thread ruft das Skript mehrmals auf, wobei ein einzelner Aufruf des Skripts dabei als “run” bezeichnet wird.
JStress
JStress als architektur-unabhängiges Tools führt ebenso mittels verschiedener, verteilter Agenten, zentral gesteuert Testläufe durch. Es liegt in der Version 0.3 bereit, wird aber auf Grund der geringen Entwicklungshöhe in diesem Beleg nicht weiter betrachtet.
PerfectLoad
PerfectLoad kann mit mehreren tausend Nutzern, die konkurrierend HTTP-Requests abschicken, Belastungstests durchführen.
Ansichten von ”PerfectLoad”
Die dabei genutzten Requests werden vorher durch Live-Interaktion aufgezeichnet und als XML abgespeichtert. Es erleichtert somit im Gegensatz zum Referenzobjekt JMeter die Testplan-Einrichtung und Portabilität.
Das kleine Tool unterstützt ebenfalls Cookies und gibt die Möglichkeit, die Daten eines Requests eines jeweiligen virtuellen Nutzers mit Daten aus einem Daten-Pool zu manipulieren. JMeter kann diese stochastischen Zugriffe aktuell nicht emulieren. PerfectLoad ermittelt daraufhin anhand der Anforderungen, ob die getestete Anwendung diesen standhält.
Eine nützliche Option ist die Hilfe, ob sich ein etwaig gezeigtes Problem eher durch neue Hardware oder eine Software-Verbesserung beheben lässt.
Das Tool ist für bis zu 5 Nutzer kostenlos, bei kommerziellem Gebrauch sind entsprechende Lizenzen zu kaufen. Nähere Informationen befinden sich dabei unter [Per04]
Greybox-Tests
Da die genannten Tools nicht spezifischer auf die Server-Architektur eingehen, können entsprechende Eigenschaften nicht näher untersucht werden. Daher wird nun zunächst eine einfache Methode zur Identifizierung der benötigten Zeit innerhalb der Cocoon- Ablaufreihenfolge aufgezeigt. Mit den daraufhin vorgestellten Werkzeugen können nun einzelne Java-Transformatoren genauer überprüft und entsprechend angepasst werden.
Cocoon-Watch-Transformator
Diese einfache Methode stellt einen Java-Transformator dar, welcher die Zeit zwischen erstem und zweitem Aufruf misst. Die ermittelten Ergebnisse werden in einer externen Datei gespeichert und können am einfachsten durch ein entsprechendes Excel-Skript visualisiert werden. Bisherige Messungen an der Amacont-Architektur wurden durch dieses Tool erstellt und werden als Vergleichswerte in folgenden Kapiteln herangezogen.
Extensible Java Profiler (EJP)
JUnitPerf
Der Vorteil von JUnit-Tests besteht im Grey-Box-Ansatz. Die entsprechenden Tests werden als Dekorator-Klassen parallel zur eigentlichen Anwendung erstellt. Sie erlauben damit die sofortige Überprüfung des bearbeiteten Code-Abschnittes auf Erfüllung der Anforderungen.
JUnit im Eclipse IDE
JUnitPerf ist eine Sammlung von JUnit “Test-Dekorierer”, um die Performance und Skalierbarkeit der Funktionalität bei bereits bestehenden JUnit-Tests durchzuführen. Diese Erweiterung umfasst den “TimedTest”, einen Test-Dekorierer, welcher Tests mit Zeitbeschränkung der Durchführung ablaufen lässt, den “LoadTest”, der eine simulierten Anzahl von konkurrierenden Nutzern und Iterationen durchführt sowie den “ThreadedTest”, der einen Test in einem eigenen Thread startet, was die Zeitmessung erlaubt.
Der Einsatz von JUnit mit JUnitPerf ermöglicht bereits in frühen Entwicklungsstadien die Kontrolle der Skalierbarkeit. JUnit ist im Eclipse-IDE ab Version 3.0 integriert.
Test-Suites
Eine Neuerscheinung, welche beiden Test-Suites eine kostenfreie Alternative gegenüberstellt, ist das Hyades Framework, welches unter dem Eclipse IDE eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Aufgrund der zugrunde liegenden “Common Public Licence” wird es näher beleuchtet.
JProbe
Die JProbe-Suite (Version 5.0.1) von Quest Software beinhaltet neben der Zeitmessung eine Code-Coverage-Analyse und Deadlock-Erkennung. Die Speicheranalyse (vergleiche “EJP”) übernimmt der zur Suite gehörende Memory Debugger. Der Baum aufgerufener Klassen und Funktionen wird dabei als Call-Graph dargestellt, wo selektiv für jede Methode die Aufrufer oder aufgerufene Methode ein- und ausgeblendet oder die Anzeige auf einen bestimmten Pfad reduziert werden kann. Zu jedem Knoten im Graphen, der immer eine Methode darstellt, zeigt ein PopUp detaillierte Informationen. Weiterhin gibt es eine Liste, die alle Methoden mit ihrer Ausführungszeit und der Anzahl der Aufrufe auflistet.
Der Preis von 4255 Dollar ist bei diesem Produkt trotz großer Leistungsvielfalt nicht gerechtfertigt.
Hyades
Ähnlich wie das IDE, stellt das Eclipse - Projekt Hyades selbst ein Framework dar, welches eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Damit soll [Sto04] folgend eine Interoperabilität zwischen Testwerkzeugen verschiedener Hersteller gewährleistet werden, wie auch eine schnellere Entwicklung innovativer Testwerkzeuge durch Wiederverwendung stets benötigter Komponenten.
Profiling
Die Grundfunktionalität des Profilings bei Hyades unterscheidet sich kaum von der kommerzieller Programme. Man kann Prozesse direkt aus Eclipse starten als sich auch nachträgliche mit laufenden Prozessen verbinden. Dabei können alle über das JVMPI erhältlichen Informationen gesammelt und analysiert werden, beispielsweise eine tabellarische Darstellung von Art und Anzahl der erzeugten sowie gerade existierenden Objekte, inklusive deren Größe im Speicher. Die Darstellung in der Notation eines UML2-Sequence-Diagramms ist ebenso möglich.
Hyades Ausführungsverlauf
Weiterhin können alle Methodenaufrufe und die Dauer ihrer Ausführung ausgewertet werden. Aus der Auswertung lässt sich der entsprechende Sourcecode anzeigen, so dass benötigte Änderungen zielgenau setztbar sind.
Log- und Trace-Analyse
Eine Besonderheit von Hyades stellt das “Logging Framework” dar, mit dem sich Ereignisse aus verschiedenen Quellen miteinander korrelieren lassen sollen. So können beispielsweise Einträge aus dem Logfile eines Applikationsservers mit der Dauer eines Requests in einem entfernt laufenden Java-Client überlagert werden. Die dabei ersichtliche Ursache - Wirkung - Beziehung erleichtert es deutlich, den Grund von Problemen zu erkennen.
Test browser-basierender Applikationen
Diese Funktionalität ist Jakarta JMeter sehr ähnlich. Allerdings bietet die Konfiguration beträchtliche Erleichterungen gegenüber JMeter. So kann ein Test einfach als Makro beim Durchsuchen der Website mit Hilfe des “Internet Explorers” aufgezeichnet werden. Durch Schliessen des Browser öffnet sich nun eine Übersicht der ausgeführten Requests, welche nachbearbeitet, in Schleifen mehrmals ausgeführt, und einem Datenpool zugeführt werden kann. Datenpools ermöglichen stochastische Zugriffe und somit die unter Kapitel 1.2 genannte Nutzeremulierung mit Ausschalten evtl. serverseitiger Caching-Methoden.
JUnit
Das bereits genannte JUnit ist ebenso vollständig in das Hyades-Framework implementiert und unterstützt eine wizardgesteuerte Test-Erstellung, die JavaCode-Generierung sowie die JUnit-Test-Auswertung.
Wie bei einem Framework üblich, lässt sich Hyades an allen Stellen durch eigene Funktionen erweitern. Dazu gehören unter anderem Parser für eigene Logfiles und Algorithmen zur Korrelation mehrerer Datenquellen.
Übersicht
Die soeben betrachteten Werkzeuge stellen einen Querschnitt durch das zurzeit verfügbare Angebot dar, besitzen jedoch auf Grund der Heterogenität des Entwicklungsumfeldes keinerlei Anspruch auf Vollständigkeit. Um einen schnellen Überblick zu ermöglichen, folgt nun nochmals eine Zusammenfassung.
| Bezeichnung | Hersteller | Plattform | Blackbox/ GreyBox | verteilte Anwend. / Multi-User/ Datenpool | grafische Auswertung | Lizenz /Kosten |
|---|---|---|---|---|---|---|
| Apache Jakarta JMeter | The Apache Foundation | Java | X / - | X/X/- | X | ASF |
| The Grinder | SourceForge | Java / Jython | X / - | X/X/- | X | GPL |
| JStress | ManAmplified | Java | X / - | X/X/- | - | GPL |
| PerfectLoad | Solnet solutions | Java / XML | X / - | -/X/X | X | ab 250 $ |
| JUnitPerf | Clarkware | Java-Decorateur | X / - | -/X/- | X | BSD-L |
| EJP | X | GPL | ||||
| Hyades | Eclipse.org | Eclipse-Framework | X / X | X/X/X | X | CPL |
| JProbe | Quest Software | - | X / X | X/X/X | X | 4255 $ |
| OptimizeIt! | Borland | Java | X / X | X/X/X | X | 2600 $ |
Zusammenfassung
Für die folgenden Arbeiten am Amacont-Projekt wird eine Kombination der vorgestellten Werkzeuge genutzt. Jakarta JMeter wird dabei mit geeigneten Testplänen die Auslösung der HTTP-Requests übernehmen, da alle Test von einer einzelnen Maschine aus stattfinden.
Der Cocoon-Watch-Transformator wird während den Requests das Zeitverhalten einzelner Komponenten festhalten und hilft somit, zeitintensive Transformatoren zu identifizieren und deren Verhalten unter verschiedenen Konfigurationen zu testen (vergleiche Kapitel 3.4).
Identifizierte Transformatoren in Java können nun durch Speicherprofiling bzw. JUnitPerf-Komponenten auf Schwachstellen abgeklopft und ggf. angepasst werden. Da Tomcat ein Java-basierender Webserver ist, kann er grundsätzlich komplett speicherprofiliert werden. Man darf eine komplette Aufschlüsselung aller Prozesse erwarten und ebenfalls das Zusammenspiel paralleler Prozesse ergründen. Dies benötigt jedoch enorme Ressourcen und bedeutet einen extremen Geschwindigkeitsverlust, weswegen es als unpraktikabel angesehen wird.
Als Schwerpunkt dieser Arbeit wird die Auswahl an Programmen, welche aus dem Bereich der GNU-Lizenz oder anderen freien Varianten stammen, vorgestellt. Ergänzend sollen zwei kommerzielle Lösungen kurz angesprochen werden, da diese in ihrem Leistungsumfang den meisten freien Tests weit überlegen sind.
[Win03] stellt die Hauptgrundlage der folgenden Recherche dar, da hier die Autoren verschiedenste Tools aufführen. Diese sind weniger im Anwendungsbereich der Whitebox-Tests angesiedelt, und können im konkreten Fall des Amacont-Projektes an zwei Stellen angelegt werden: Zum Einen sollen komplette Black-Box-Tests die durchschnittliche Webdienst-Bearbeitungszeit r einschließlich Wartezeit errechnen. Zum Zweiten zeigen Grey-Box - Tests direkt am Service die durchschnittliche Webdienst-Bearbeitungszeit s und daraus resultierend die durchschnittliche Webservice-Rate µ= 1/s an ausgewählten Beispielen.
Um diese beiden Grundprinzipien besser zu verstehen und einen Überblick über den grundlegenden Aufbau eines Performance-Testtools zu erlangen, wird folgend exemplarisch das Programm Apache Jakarta JMeter ausführlicher erläutert. Es soll dabei als kompletter Black-Box-Test auftreten, da das genutzte Server-System ohne genaue Kenntnisse des Gesamtaufbaus getestet und lediglich die Größe r, also die durchschnittliche Webbearbeitungszeit inklusive Wartezeit, untersucht wird.
Als Gegensatz dazu und vollständige Grey-Box-Test-Variante wird daraufhin auf die Decorator-Technik von JUnit und JUnitPerf zur Unterstützung der Testgetriebenen Programmierung kurz eingegangen. Sie motiviert jede Änderung des Programmverhaltens zuvor durch einen automatisierten Test und führt so die zuvor adHoc-motivierte Programmiertätigkeit zu einem methodischen Vorgehen.
Somit soll sich folgend von außen an das Projekt der Performanztestung herangetastet werden, um im späteren Verlauf den inneren Aufbau besser zu verstehen und die Geschwindigkeit an einzelnen Komponenten zu verbessern. Im Kapitel 5 wird auf diese Erkenntnisse aufbauend eine konkrete Änderung innerhalb der Amacont-Architektur erläutert werden, welche gleichzeitig den praktischen Anteil dieser Belegarbeit darstellt.
Blackbox-Tests
Apache Jakarta JMeter
Apache Jakarta JMeter
JMeter ist ein Werkzeug zum Ausführen von Lasttests in Client/Server-Anwendungen. Dabei wird mittels Zusammenstellen eines Testplanes spezifiziert, welche Teile der Anwendung durchlaufen werden sollen, um konkrete Ergebnisse über das Antwort-Zeit-Verhalten zu bekommen.
Graph-Visualizer des Apache JMeter
Mit Hilfe von Testplänen werden dabei die Testschritte beschrieben, welche JMeter durchlaufen muss. Ein kompletter Testplan besteht nach [Apa04] aus einem oder mehreren Testschritten, Logik-Komponenten, Listener, Sampler, Timer, Assertions und Konfigurationselementen.
Komponenten von JMeter
Ein jeder Testplan beginnt mit Testgruppen (ThreadGroups). Alle Elemente eines Testplans werden unter einer Testgruppe angeordnet, welche die dazugehörige Anzahl der Instanzen, welche JMeter zum Ausführen des gewünschten Tests nutzt, angibt. Es sind die folgenden Optionen anzugeben:
Als nächstes folgen in einer Testgruppe verschiedene Controller. Diese sind in 2 Arten unterteilt: Sampler und Logik-Controller.
Sampler geben dabei die Art des Requests an. Ein http-Request-Sampler sendet beispielsweise Requests unter Nutzung des HTTP-Protokolls. Requests können weiterhin durch Hinzufügen eines oder mehrerer Konfigurationselemente zu einem Sampler angepasst werden.
Über Logik-Controller kann die Logik angepasst werden, welche JMeter zur Entscheidung nutzt, wann ein Request gesendet wird. So kann beispielsweise ein Interleave Logik-Controller genutzt werden, um zwischen 2 HTTP-Request-Samplern zu wechseln. Ein weiterer Logik-Kontroller, der “Modification Manager”, erlaubt das Verändern eines Request-Ergebnisses.
Zur Veranschaulichung beziehen wir die Controller-Thematik kurz auf das Beispiel der Amacont-Architektur. Hier wird beispielsweise zunächst ein “Once-Only-Controller” zum Einsatz kommen, welcher den Login-Request (ein http-Request) an das System sendet. Nach erfolgreichem Login in das System wird durch einen weiteren Sampler auf eine zu testende Seite gewechselt werden. Dies ist ein einfacher Request, welcher durch keinerlei Logik gefiltert werden muss. Nach dem Laden dieser gewünschten Testseite können dann abwechselnd bestimmte Anfragen gestellt werden, welche ein “Interleave Controller” kontrolliert und steuert.
Während der Test-Durchläufe werden Informationen angesammelt. Listener stellen diese zur Verfügung. Der einfachste Vertreter ist dabei der “Graph Result Listener”, welcher die Antwortzeiten in einem Graphen wiedergibt. Listener stellen graphische Sichten auf die erhaltenen Daten zur Verfügung. Ebenfalls können durch sie gesammelte Daten in einer Datei für die spätere Anwendung gespeichert werden. Dafür stellt jeder Vertreter in JMeter ein Feld zur Verfügung, in welches der entsprechende Dateiname eingetragen werden kann.
Für gewöhnlich sendet JMeter Anfragen ohne entsprechende Wartezeiten. Da das Absetzen zu vieler Anfragen in einer sehr kurzen Zeit zu einer Überlastung des Servers führen kann, ist das Einfügen einer Verzögerung sinnvoll. Der Timer übernimmt diese Aufgabe und hält die definierte Wartezeit zwischen verschiedenen Requests ein. Bei mehreren in Reihe geschalteten Timern wird die Summe der Pausen gebildet und als Wartezeit definiert.
Assertions wiederum erlauben Behauptungen über bestimmte Test-Antworten des Servers. Bei der Benutzung von Assertions kann essentiell getestet werden, dass die Anwendung genau so antwortet, wie dies erwartet wird. Beispielsweise kann behauptet werden, dass eine Antwort auf eine bestimmte Anfrage einen bestimmten Textteil enthalten muss. Der zu suchende Text kann dabei als regulärer Ausdruck im Perl-Style angegeben werden, welcher entweder in der Antwort enthalten sein muss, oder ob der gesamte Response darauf passen soll. Wird eine Behauptung nicht erfüllt, so wird der betreffende Test als fehlgeschlagen gekennzeichnet. Um das Behauptungs-Ergebnis zu sehen, muss ein “Assertion-Listener” zur Testgruppe hinzugefügt werden.
Ein Konfigurationselement (configuration element) arbeitet ähnlich einem Sampler. Wenn gleich es auch (mit Ausnahme des http Proxy Servers) keinen Request sendet, so kann es Requests hinzufügen oder verändern. Auf ein Konfigurationselement ist lediglich innerhalb des eigenen Baumzweiges ein Zugriff möglich. Wenn also ein “HTTP Cookie Manager” innerhalb eines “Simple Logic Controllers” gelegt wird, so ist er nur von den “HTTP Request Controllern” innerhalb dieses “Simple Logic Controllers” abfragbar.
Testplanaufstellung unter JMeter
Im Beispiel könnten demnach “Web Page 1” und “Web Page 2” auf den “Cookie Manager” zugreifen, jedoch nicht “Web Page 3”.
Pre-Prozessoren ermöglichen die Ausführung von Aktionen, bevor der Sampler-Request beginnt. Wenn ein Pre-Prozessor an ein Sampler-Element angefügt wird, so wird es kurz vor dem Starten des Sampler-Requestes ausgeführt. Er wird daher oft verwendet, um Einstellungen am Sample Request zu ändern, bevor er startet, oder um Variablen zu aktualisieren, welche nicht aus dem Response-Text extrahiert wurden.
Ein Post-Prozessor-Element führt parallel dazu Aktionen kurz nach dem Sampler-Request aus. Der Post-Prozessor wird meistens zur Auswertung von Response-Daten genutzt, oft, um daraus Werte zu extrahieren.
Erstellen eines Web-Testplanes
Wie bereits unter 2.2.1.1 kurz angesprochen, beschreibt also ein Testplan eine Serie von Testschritten, die JMeter nacheinander ausführt. Ein kompletter Testplan wird dabei aus einem oder mehreren Testgruppen bestehen.
Der erste Schritt des Testplans ist das Hinzufügen eines Testgruppen-Elementes. Dieser gibt JMeter Informationen über die Anzahl der zu simulierenden Nutzer, wie viele Anfragen sie senden und wie oft sie das tun sollen. Dies stellt die Grundeinstellungen einer Testgruppe dar.
Hinzufuegen einer Test-Gruppen in JMeter
Nach der Eingabe eines aussagekräftigeren Namens für die Testgruppe folgt die Anzahl der Nutzer, die Anlaufzeit sowie die Wiederholungsanzahl. Über den “Scheduler” kann eine feste Start- und Ende-Zeit für den Test angegeben werden.
Nachdem die Nutzer definiert sind, folgt die Angabe der Aufträge, welche sie abarbeiten. Zunächst werden dazu Grundeinstellungen vorgenommen, auf welche später durch spezielle HTTP-Request-Elemente als Standard-Werte zurückgegriffen werden sollen.
Dies sind im Einzeln
Request-Grundeinstellungen in JMeter
An dieser Stelle wird aufgrund des Cookie-gestützten Amacont-Projekts der bereits erwähnte “HTTP Cookie Manager” in den Testplan eingefügt. Dadurch wird sichergestellt, dass jeder Thread seinen eigenen Session-Cookie bekommt, welcher über alle HTTP-Request Objekte geteilt wird.
Als nächstes folgen auf einzelne Requests spezialisierte Einstellungen.
Der Servername bzw. die IP kann hier weggelassen werden, da diese bereits bei den Voreinstellungen eingetragen wurde, ebenso die Port-Nummer. Angegeben werden können hier weiterhin das Protokoll, die Art der Parameterübergabe sowie der genaue Seitenaufruf. Ebenfalls kann eine zu übertragende Seite mit passendem MIME-Typ ausgestattet werden.
http-Request-Einstellungen in JMeter
Falls die User-Session nicht durch Cookies sondern per URL-Rewriting weitergegeben werden würde, käme der “HTTP-URL-Rewriting Modifier” zum Einsatz. Hierbei würde der Name der Session-ID eingetragen, so dass JMeter diesen finden und an jeden Request anhängen könnte. Falls dieser bereits einen Parameter besäße, würde dieser überschrieben werden.
URL-Rewrite-Veränderung in JMeter
Um die erzielten Ergebnisse in einer Datei zu speichern und graphisch darzustellen, folgt der “Graph Result Listener”. Bei diesem ist die gewünschte Datei zu spezifizieren, ebenso wie die anzuzeigenden Kurven. Dazu gibt es die Möglichkeiten der gesamten Daten-Darstellung, des Durchschnittswertes, des Mittelwertes, der Abweichung und des Datendurchsatzes.
Graph-Visualizer des Apache JMeter
Um den Testplan nun zu starten, genügt das Aufrufen des “Run”-Buttons. Falls das Ergebnis in einer Datei gespeichert wurde, kann diese nachträglich in einem Visualizer geöffnet werden. Jeder Visualizer zeigt dabei das Ergebnis in der vorher definierten Art und Weise.
The Grinder
Startseite “The Grinder”
Dieses Tool ist ein Framework, um Test-Skripte über eine bestimmte Anzahl von Maschinen arbeiten zu lassen. Es gibt damit die Möglichkeit, mit mehreren Rechnern gleichzeitig und synchronisiert auf einen zu testenden Rechner zuzugreifen und somit eine höhere Last auf diesen ausüben zu können. Er ist daher in die Gruppe der kompletten Black-Boxtests einzuordnen und JMeter sehr ähnlich.
Ein Unterschied besteht allerdings zum Einen in der Drei-Schichten-Architektur dieses Frameworks, welche sich aus den Arbeits-Prozessen, den Agenten-Prozessen und der Konsole zusammensetzt.
Funktionsweise von “The Grinder”
Die Arbeitsprozesse interpretieren dabei als weiteren Unterschied Jython-Testskripte und führen die darin beschriebenen Tests mit einer vorher definierten Anzahl von Arbeits-Threads aus. Die Agenten-Prozesse steuern die Arbeiter-Prozesse. Dazu läuft ein Agenten-Prozess auf jeder Client-Maschine. Zur Koordination dieser Prozesse nutzt der Anwender die Konsole, welche ebenso die einzelnen Prozesse vereinigt und die Statistiken präsentiert.
Da "The Grinder", wie auch JMeter, in Java geschrieben ist, stellt jeder dieser Prozesse eine "Java Virtual Machine" (JVM) dar. Für Hochleistungstest werden Agenten-Prozesse auf jedem Client-Rechner gestartet. Die durch diese gestarteten Arbeiter-Prozesse können von der Konsole aus kontrolliert und aufgezeichnet werden.
Ein "Test" ist hierbei ebenfalls eine Einheit von Tätigkeiten, von welchen Statistiken aufgezeichnet werden. Die Spezifikation der zu startenden Tests gibt das jeweilige Jython-Testskript an.
Das Skript wird, ähnlich dem Testplan unter JMeter, mehrmals in typischen Testszenarien ausgeführt. Jeder Arbeiterprozess hat dabei eine Anzahl von Arbeiter-Threads, und jeder Thread ruft das Skript mehrmals auf, wobei ein einzelner Aufruf des Skripts dabei als “run” bezeichnet wird.
JStress
JStress als architektur-unabhängiges Tools führt ebenso mittels verschiedener, verteilter Agenten, zentral gesteuert Testläufe durch. Es liegt in der Version 0.3 bereit, wird aber auf Grund der geringen Entwicklungshöhe in diesem Beleg nicht weiter betrachtet.
PerfectLoad
PerfectLoad kann mit mehreren tausend Nutzern, die konkurrierend HTTP-Requests abschicken, Belastungstests durchführen.
Ansichten von ”PerfectLoad”
Die dabei genutzten Requests werden vorher durch Live-Interaktion aufgezeichnet und als XML abgespeichtert. Es erleichtert somit im Gegensatz zum Referenzobjekt JMeter die Testplan-Einrichtung und Portabilität.
Das kleine Tool unterstützt ebenfalls Cookies und gibt die Möglichkeit, die Daten eines Requests eines jeweiligen virtuellen Nutzers mit Daten aus einem Daten-Pool zu manipulieren. JMeter kann diese stochastischen Zugriffe aktuell nicht emulieren. PerfectLoad ermittelt daraufhin anhand der Anforderungen, ob die getestete Anwendung diesen standhält.
Eine nützliche Option ist die Hilfe, ob sich ein etwaig gezeigtes Problem eher durch neue Hardware oder eine Software-Verbesserung beheben lässt.
Das Tool ist für bis zu 5 Nutzer kostenlos, bei kommerziellem Gebrauch sind entsprechende Lizenzen zu kaufen. Nähere Informationen befinden sich dabei unter [Per04]
Greybox-Tests
Da die genannten Tools nicht spezifischer auf die Server-Architektur eingehen, können entsprechende Eigenschaften nicht näher untersucht werden. Daher wird nun zunächst eine einfache Methode zur Identifizierung der benötigten Zeit innerhalb der Cocoon- Ablaufreihenfolge aufgezeigt. Mit den daraufhin vorgestellten Werkzeugen können nun einzelne Java-Transformatoren genauer überprüft und entsprechend angepasst werden.
Cocoon-Watch-Transformator
Diese einfache Methode stellt einen Java-Transformator dar, welcher die Zeit zwischen erstem und zweitem Aufruf misst. Die ermittelten Ergebnisse werden in einer externen Datei gespeichert und können am einfachsten durch ein entsprechendes Excel-Skript visualisiert werden. Bisherige Messungen an der Amacont-Architektur wurden durch dieses Tool erstellt und werden als Vergleichswerte in folgenden Kapiteln herangezogen.
Extensible Java Profiler (EJP)
JUnitPerf
Der Vorteil von JUnit-Tests besteht im Grey-Box-Ansatz. Die entsprechenden Tests werden als Dekorator-Klassen parallel zur eigentlichen Anwendung erstellt. Sie erlauben damit die sofortige Überprüfung des bearbeiteten Code-Abschnittes auf Erfüllung der Anforderungen.
JUnit im Eclipse IDE
JUnitPerf ist eine Sammlung von JUnit “Test-Dekorierer”, um die Performance und Skalierbarkeit der Funktionalität bei bereits bestehenden JUnit-Tests durchzuführen. Diese Erweiterung umfasst den “TimedTest”, einen Test-Dekorierer, welcher Tests mit Zeitbeschränkung der Durchführung ablaufen lässt, den “LoadTest”, der eine simulierten Anzahl von konkurrierenden Nutzern und Iterationen durchführt sowie den “ThreadedTest”, der einen Test in einem eigenen Thread startet, was die Zeitmessung erlaubt.
Der Einsatz von JUnit mit JUnitPerf ermöglicht bereits in frühen Entwicklungsstadien die Kontrolle der Skalierbarkeit. JUnit ist im Eclipse-IDE ab Version 3.0 integriert.
Test-Suites
Eine Neuerscheinung, welche beiden Test-Suites eine kostenfreie Alternative gegenüberstellt, ist das Hyades Framework, welches unter dem Eclipse IDE eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Aufgrund der zugrunde liegenden “Common Public Licence” wird es näher beleuchtet.
JProbe
Die JProbe-Suite (Version 5.0.1) von Quest Software beinhaltet neben der Zeitmessung eine Code-Coverage-Analyse und Deadlock-Erkennung. Die Speicheranalyse (vergleiche “EJP”) übernimmt der zur Suite gehörende Memory Debugger. Der Baum aufgerufener Klassen und Funktionen wird dabei als Call-Graph dargestellt, wo selektiv für jede Methode die Aufrufer oder aufgerufene Methode ein- und ausgeblendet oder die Anzeige auf einen bestimmten Pfad reduziert werden kann. Zu jedem Knoten im Graphen, der immer eine Methode darstellt, zeigt ein PopUp detaillierte Informationen. Weiterhin gibt es eine Liste, die alle Methoden mit ihrer Ausführungszeit und der Anzahl der Aufrufe auflistet.
Der Preis von 4255 Dollar ist bei diesem Produkt trotz großer Leistungsvielfalt nicht gerechtfertigt.
Hyades
Ähnlich wie das IDE, stellt das Eclipse - Projekt Hyades selbst ein Framework dar, welches eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Damit soll [Sto04] folgend eine Interoperabilität zwischen Testwerkzeugen verschiedener Hersteller gewährleistet werden, wie auch eine schnellere Entwicklung innovativer Testwerkzeuge durch Wiederverwendung stets benötigter Komponenten.
Profiling
Die Grundfunktionalität des Profilings bei Hyades unterscheidet sich kaum von der kommerzieller Programme. Man kann Prozesse direkt aus Eclipse starten als sich auch nachträgliche mit laufenden Prozessen verbinden. Dabei können alle über das JVMPI erhältlichen Informationen gesammelt und analysiert werden, beispielsweise eine tabellarische Darstellung von Art und Anzahl der erzeugten sowie gerade existierenden Objekte, inklusive deren Größe im Speicher. Die Darstellung in der Notation eines UML2-Sequence-Diagramms ist ebenso möglich.
Hyades Ausführungsverlauf
Weiterhin können alle Methodenaufrufe und die Dauer ihrer Ausführung ausgewertet werden. Aus der Auswertung lässt sich der entsprechende Sourcecode anzeigen, so dass benötigte Änderungen zielgenau setztbar sind.
Log- und Trace-Analyse
Eine Besonderheit von Hyades stellt das “Logging Framework” dar, mit dem sich Ereignisse aus verschiedenen Quellen miteinander korrelieren lassen sollen. So können beispielsweise Einträge aus dem Logfile eines Applikationsservers mit der Dauer eines Requests in einem entfernt laufenden Java-Client überlagert werden. Die dabei ersichtliche Ursache - Wirkung - Beziehung erleichtert es deutlich, den Grund von Problemen zu erkennen.
Test browser-basierender Applikationen
Diese Funktionalität ist Jakarta JMeter sehr ähnlich. Allerdings bietet die Konfiguration beträchtliche Erleichterungen gegenüber JMeter. So kann ein Test einfach als Makro beim Durchsuchen der Website mit Hilfe des “Internet Explorers” aufgezeichnet werden. Durch Schliessen des Browser öffnet sich nun eine Übersicht der ausgeführten Requests, welche nachbearbeitet, in Schleifen mehrmals ausgeführt, und einem Datenpool zugeführt werden kann. Datenpools ermöglichen stochastische Zugriffe und somit die unter Kapitel 1.2 genannte Nutzeremulierung mit Ausschalten evtl. serverseitiger Caching-Methoden.
JUnit
Das bereits genannte JUnit ist ebenso vollständig in das Hyades-Framework implementiert und unterstützt eine wizardgesteuerte Test-Erstellung, die JavaCode-Generierung sowie die JUnit-Test-Auswertung.
Wie bei einem Framework üblich, lässt sich Hyades an allen Stellen durch eigene Funktionen erweitern. Dazu gehören unter anderem Parser für eigene Logfiles und Algorithmen zur Korrelation mehrerer Datenquellen.
Übersicht
Die soeben betrachteten Werkzeuge stellen einen Querschnitt durch das zurzeit verfügbare Angebot dar, besitzen jedoch auf Grund der Heterogenität des Entwicklungsumfeldes keinerlei Anspruch auf Vollständigkeit. Um einen schnellen Überblick zu ermöglichen, folgt nun nochmals eine Zusammenfassung.
| Bezeichnung | Hersteller | Plattform | Blackbox/ GreyBox | verteilte Anwend. / Multi-User/ Datenpool | grafische Auswertung | Lizenz /Kosten |
|---|---|---|---|---|---|---|
| Apache Jakarta JMeter | The Apache Foundation | Java | X / - | X/X/- | X | ASF |
| The Grinder | SourceForge | Java / Jython | X / - | X/X/- | X | GPL |
| JStress | ManAmplified | Java | X / - | X/X/- | - | GPL |
| PerfectLoad | Solnet solutions | Java / XML | X / - | -/X/X | X | ab 250 $ |
| JUnitPerf | Clarkware | Java-Decorateur | X / - | -/X/- | X | BSD-L |
| EJP | X | GPL | ||||
| Hyades | Eclipse.org | Eclipse-Framework | X / X | X/X/X | X | CPL |
| JProbe | Quest Software | - | X / X | X/X/X | X | 4255 $ |
| OptimizeIt! | Borland | Java | X / X | X/X/X | X | 2600 $ |
Zusammenfassung
Für die folgenden Arbeiten am Amacont-Projekt wird eine Kombination der vorgestellten Werkzeuge genutzt. Jakarta JMeter wird dabei mit geeigneten Testplänen die Auslösung der HTTP-Requests übernehmen, da alle Test von einer einzelnen Maschine aus stattfinden.
Der Cocoon-Watch-Transformator wird während den Requests das Zeitverhalten einzelner Komponenten festhalten und hilft somit, zeitintensive Transformatoren zu identifizieren und deren Verhalten unter verschiedenen Konfigurationen zu testen (vergleiche Kapitel 3.4).
Identifizierte Transformatoren in Java können nun durch Speicherprofiling bzw. JUnitPerf-Komponenten auf Schwachstellen abgeklopft und ggf. angepasst werden. Da Tomcat ein Java-basierender Webserver ist, kann er grundsätzlich komplett speicherprofiliert werden. Man darf eine komplette Aufschlüsselung aller Prozesse erwarten und ebenfalls das Zusammenspiel paralleler Prozesse ergründen. Dies benötigt jedoch enorme Ressourcen und bedeutet einen extremen Geschwindigkeitsverlust, weswegen es als unpraktikabel angesehen wird.
Als Schwerpunkt dieser Arbeit wird die Auswahl an Programmen, welche aus dem Bereich der GNU-Lizenz oder anderen freien Varianten stammen, vorgestellt. Ergänzend sollen zwei kommerzielle Lösungen kurz angesprochen werden, da diese in ihrem Leistungsumfang den meisten freien Tests weit überlegen sind.
[Win03] stellt die Hauptgrundlage der folgenden Recherche dar, da hier die Autoren verschiedenste Tools aufführen. Diese sind weniger im Anwendungsbereich der Whitebox-Tests angesiedelt, und können im konkreten Fall des Amacont-Projektes an zwei Stellen angelegt werden: Zum Einen sollen komplette Black-Box-Tests die durchschnittliche Webdienst-Bearbeitungszeit r einschließlich Wartezeit errechnen. Zum Zweiten zeigen Grey-Box - Tests direkt am Service die durchschnittliche Webdienst-Bearbeitungszeit s und daraus resultierend die durchschnittliche Webservice-Rate µ= 1/s an ausgewählten Beispielen.
Um diese beiden Grundprinzipien besser zu verstehen und einen Überblick über den grundlegenden Aufbau eines Performance-Testtools zu erlangen, wird folgend exemplarisch das Programm Apache Jakarta JMeter ausführlicher erläutert. Es soll dabei als kompletter Black-Box-Test auftreten, da das genutzte Server-System ohne genaue Kenntnisse des Gesamtaufbaus getestet und lediglich die Größe r, also die durchschnittliche Webbearbeitungszeit inklusive Wartezeit, untersucht wird.
Als Gegensatz dazu und vollständige Grey-Box-Test-Variante wird daraufhin auf die Decorator-Technik von JUnit und JUnitPerf zur Unterstützung der Testgetriebenen Programmierung kurz eingegangen. Sie motiviert jede Änderung des Programmverhaltens zuvor durch einen automatisierten Test und führt so die zuvor adHoc-motivierte Programmiertätigkeit zu einem methodischen Vorgehen.
Somit soll sich folgend von außen an das Projekt der Performanztestung herangetastet werden, um im späteren Verlauf den inneren Aufbau besser zu verstehen und die Geschwindigkeit an einzelnen Komponenten zu verbessern. Im Kapitel 5 wird auf diese Erkenntnisse aufbauend eine konkrete Änderung innerhalb der Amacont-Architektur erläutert werden, welche gleichzeitig den praktischen Anteil dieser Belegarbeit darstellt.
Blackbox-Tests
Apache Jakarta JMeter
Apache Jakarta JMeter
JMeter ist ein Werkzeug zum Ausführen von Lasttests in Client/Server-Anwendungen. Dabei wird mittels Zusammenstellen eines Testplanes spezifiziert, welche Teile der Anwendung durchlaufen werden sollen, um konkrete Ergebnisse über das Antwort-Zeit-Verhalten zu bekommen.
Graph-Visualizer des Apache JMeter
Mit Hilfe von Testplänen werden dabei die Testschritte beschrieben, welche JMeter durchlaufen muss. Ein kompletter Testplan besteht nach [Apa04] aus einem oder mehreren Testschritten, Logik-Komponenten, Listener, Sampler, Timer, Assertions und Konfigurationselementen.
Komponenten von JMeter
Ein jeder Testplan beginnt mit Testgruppen (ThreadGroups). Alle Elemente eines Testplans werden unter einer Testgruppe angeordnet, welche die dazugehörige Anzahl der Instanzen, welche JMeter zum Ausführen des gewünschten Tests nutzt, angibt. Es sind die folgenden Optionen anzugeben:
Als nächstes folgen in einer Testgruppe verschiedene Controller. Diese sind in 2 Arten unterteilt: Sampler und Logik-Controller.
Sampler geben dabei die Art des Requests an. Ein http-Request-Sampler sendet beispielsweise Requests unter Nutzung des HTTP-Protokolls. Requests können weiterhin durch Hinzufügen eines oder mehrerer Konfigurationselemente zu einem Sampler angepasst werden.
Über Logik-Controller kann die Logik angepasst werden, welche JMeter zur Entscheidung nutzt, wann ein Request gesendet wird. So kann beispielsweise ein Interleave Logik-Controller genutzt werden, um zwischen 2 HTTP-Request-Samplern zu wechseln. Ein weiterer Logik-Kontroller, der “Modification Manager”, erlaubt das Verändern eines Request-Ergebnisses.
Zur Veranschaulichung beziehen wir die Controller-Thematik kurz auf das Beispiel der Amacont-Architektur. Hier wird beispielsweise zunächst ein “Once-Only-Controller” zum Einsatz kommen, welcher den Login-Request (ein http-Request) an das System sendet. Nach erfolgreichem Login in das System wird durch einen weiteren Sampler auf eine zu testende Seite gewechselt werden. Dies ist ein einfacher Request, welcher durch keinerlei Logik gefiltert werden muss. Nach dem Laden dieser gewünschten Testseite können dann abwechselnd bestimmte Anfragen gestellt werden, welche ein “Interleave Controller” kontrolliert und steuert.
Während der Test-Durchläufe werden Informationen angesammelt. Listener stellen diese zur Verfügung. Der einfachste Vertreter ist dabei der “Graph Result Listener”, welcher die Antwortzeiten in einem Graphen wiedergibt. Listener stellen graphische Sichten auf die erhaltenen Daten zur Verfügung. Ebenfalls können durch sie gesammelte Daten in einer Datei für die spätere Anwendung gespeichert werden. Dafür stellt jeder Vertreter in JMeter ein Feld zur Verfügung, in welches der entsprechende Dateiname eingetragen werden kann.
Für gewöhnlich sendet JMeter Anfragen ohne entsprechende Wartezeiten. Da das Absetzen zu vieler Anfragen in einer sehr kurzen Zeit zu einer Überlastung des Servers führen kann, ist das Einfügen einer Verzögerung sinnvoll. Der Timer übernimmt diese Aufgabe und hält die definierte Wartezeit zwischen verschiedenen Requests ein. Bei mehreren in Reihe geschalteten Timern wird die Summe der Pausen gebildet und als Wartezeit definiert.
Assertions wiederum erlauben Behauptungen über bestimmte Test-Antworten des Servers. Bei der Benutzung von Assertions kann essentiell getestet werden, dass die Anwendung genau so antwortet, wie dies erwartet wird. Beispielsweise kann behauptet werden, dass eine Antwort auf eine bestimmte Anfrage einen bestimmten Textteil enthalten muss. Der zu suchende Text kann dabei als regulärer Ausdruck im Perl-Style angegeben werden, welcher entweder in der Antwort enthalten sein muss, oder ob der gesamte Response darauf passen soll. Wird eine Behauptung nicht erfüllt, so wird der betreffende Test als fehlgeschlagen gekennzeichnet. Um das Behauptungs-Ergebnis zu sehen, muss ein “Assertion-Listener” zur Testgruppe hinzugefügt werden.
Ein Konfigurationselement (configuration element) arbeitet ähnlich einem Sampler. Wenn gleich es auch (mit Ausnahme des http Proxy Servers) keinen Request sendet, so kann es Requests hinzufügen oder verändern. Auf ein Konfigurationselement ist lediglich innerhalb des eigenen Baumzweiges ein Zugriff möglich. Wenn also ein “HTTP Cookie Manager” innerhalb eines “Simple Logic Controllers” gelegt wird, so ist er nur von den “HTTP Request Controllern” innerhalb dieses “Simple Logic Controllers” abfragbar.
Testplanaufstellung unter JMeter
Im Beispiel könnten demnach “Web Page 1” und “Web Page 2” auf den “Cookie Manager” zugreifen, jedoch nicht “Web Page 3”.
Pre-Prozessoren ermöglichen die Ausführung von Aktionen, bevor der Sampler-Request beginnt. Wenn ein Pre-Prozessor an ein Sampler-Element angefügt wird, so wird es kurz vor dem Starten des Sampler-Requestes ausgeführt. Er wird daher oft verwendet, um Einstellungen am Sample Request zu ändern, bevor er startet, oder um Variablen zu aktualisieren, welche nicht aus dem Response-Text extrahiert wurden.
Ein Post-Prozessor-Element führt parallel dazu Aktionen kurz nach dem Sampler-Request aus. Der Post-Prozessor wird meistens zur Auswertung von Response-Daten genutzt, oft, um daraus Werte zu extrahieren.
Erstellen eines Web-Testplanes
Wie bereits unter 2.2.1.1 kurz angesprochen, beschreibt also ein Testplan eine Serie von Testschritten, die JMeter nacheinander ausführt. Ein kompletter Testplan wird dabei aus einem oder mehreren Testgruppen bestehen.
Der erste Schritt des Testplans ist das Hinzufügen eines Testgruppen-Elementes. Dieser gibt JMeter Informationen über die Anzahl der zu simulierenden Nutzer, wie viele Anfragen sie senden und wie oft sie das tun sollen. Dies stellt die Grundeinstellungen einer Testgruppe dar.
Hinzufuegen einer Test-Gruppen in JMeter
Nach der Eingabe eines aussagekräftigeren Namens für die Testgruppe folgt die Anzahl der Nutzer, die Anlaufzeit sowie die Wiederholungsanzahl. Über den “Scheduler” kann eine feste Start- und Ende-Zeit für den Test angegeben werden.
Nachdem die Nutzer definiert sind, folgt die Angabe der Aufträge, welche sie abarbeiten. Zunächst werden dazu Grundeinstellungen vorgenommen, auf welche später durch spezielle HTTP-Request-Elemente als Standard-Werte zurückgegriffen werden sollen.
Dies sind im Einzeln
Request-Grundeinstellungen in JMeter
An dieser Stelle wird aufgrund des Cookie-gestützten Amacont-Projekts der bereits erwähnte “HTTP Cookie Manager” in den Testplan eingefügt. Dadurch wird sichergestellt, dass jeder Thread seinen eigenen Session-Cookie bekommt, welcher über alle HTTP-Request Objekte geteilt wird.
Als nächstes folgen auf einzelne Requests spezialisierte Einstellungen.
Der Servername bzw. die IP kann hier weggelassen werden, da diese bereits bei den Voreinstellungen eingetragen wurde, ebenso die Port-Nummer. Angegeben werden können hier weiterhin das Protokoll, die Art der Parameterübergabe sowie der genaue Seitenaufruf. Ebenfalls kann eine zu übertragende Seite mit passendem MIME-Typ ausgestattet werden.
http-Request-Einstellungen in JMeter
Falls die User-Session nicht durch Cookies sondern per URL-Rewriting weitergegeben werden würde, käme der “HTTP-URL-Rewriting Modifier” zum Einsatz. Hierbei würde der Name der Session-ID eingetragen, so dass JMeter diesen finden und an jeden Request anhängen könnte. Falls dieser bereits einen Parameter besäße, würde dieser überschrieben werden.
URL-Rewrite-Veränderung in JMeter
Um die erzielten Ergebnisse in einer Datei zu speichern und graphisch darzustellen, folgt der “Graph Result Listener”. Bei diesem ist die gewünschte Datei zu spezifizieren, ebenso wie die anzuzeigenden Kurven. Dazu gibt es die Möglichkeiten der gesamten Daten-Darstellung, des Durchschnittswertes, des Mittelwertes, der Abweichung und des Datendurchsatzes.
Graph-Visualizer des Apache JMeter
Um den Testplan nun zu starten, genügt das Aufrufen des “Run”-Buttons. Falls das Ergebnis in einer Datei gespeichert wurde, kann diese nachträglich in einem Visualizer geöffnet werden. Jeder Visualizer zeigt dabei das Ergebnis in der vorher definierten Art und Weise.
The Grinder
Startseite “The Grinder”
Dieses Tool ist ein Framework, um Test-Skripte über eine bestimmte Anzahl von Maschinen arbeiten zu lassen. Es gibt damit die Möglichkeit, mit mehreren Rechnern gleichzeitig und synchronisiert auf einen zu testenden Rechner zuzugreifen und somit eine höhere Last auf diesen ausüben zu können. Er ist daher in die Gruppe der kompletten Black-Boxtests einzuordnen und JMeter sehr ähnlich.
Ein Unterschied besteht allerdings zum Einen in der Drei-Schichten-Architektur dieses Frameworks, welche sich aus den Arbeits-Prozessen, den Agenten-Prozessen und der Konsole zusammensetzt.
Funktionsweise von “The Grinder”
Die Arbeitsprozesse interpretieren dabei als weiteren Unterschied Jython-Testskripte und führen die darin beschriebenen Tests mit einer vorher definierten Anzahl von Arbeits-Threads aus. Die Agenten-Prozesse steuern die Arbeiter-Prozesse. Dazu läuft ein Agenten-Prozess auf jeder Client-Maschine. Zur Koordination dieser Prozesse nutzt der Anwender die Konsole, welche ebenso die einzelnen Prozesse vereinigt und die Statistiken präsentiert.
Da "The Grinder", wie auch JMeter, in Java geschrieben ist, stellt jeder dieser Prozesse eine "Java Virtual Machine" (JVM) dar. Für Hochleistungstest werden Agenten-Prozesse auf jedem Client-Rechner gestartet. Die durch diese gestarteten Arbeiter-Prozesse können von der Konsole aus kontrolliert und aufgezeichnet werden.
Ein "Test" ist hierbei ebenfalls eine Einheit von Tätigkeiten, von welchen Statistiken aufgezeichnet werden. Die Spezifikation der zu startenden Tests gibt das jeweilige Jython-Testskript an.
Das Skript wird, ähnlich dem Testplan unter JMeter, mehrmals in typischen Testszenarien ausgeführt. Jeder Arbeiterprozess hat dabei eine Anzahl von Arbeiter-Threads, und jeder Thread ruft das Skript mehrmals auf, wobei ein einzelner Aufruf des Skripts dabei als “run” bezeichnet wird.
JStress
JStress als architektur-unabhängiges Tools führt ebenso mittels verschiedener, verteilter Agenten, zentral gesteuert Testläufe durch. Es liegt in der Version 0.3 bereit, wird aber auf Grund der geringen Entwicklungshöhe in diesem Beleg nicht weiter betrachtet.
PerfectLoad
PerfectLoad kann mit mehreren tausend Nutzern, die konkurrierend HTTP-Requests abschicken, Belastungstests durchführen.
Ansichten von ”PerfectLoad”
Die dabei genutzten Requests werden vorher durch Live-Interaktion aufgezeichnet und als XML abgespeichtert. Es erleichtert somit im Gegensatz zum Referenzobjekt JMeter die Testplan-Einrichtung und Portabilität.
Das kleine Tool unterstützt ebenfalls Cookies und gibt die Möglichkeit, die Daten eines Requests eines jeweiligen virtuellen Nutzers mit Daten aus einem Daten-Pool zu manipulieren. JMeter kann diese stochastischen Zugriffe aktuell nicht emulieren. PerfectLoad ermittelt daraufhin anhand der Anforderungen, ob die getestete Anwendung diesen standhält.
Eine nützliche Option ist die Hilfe, ob sich ein etwaig gezeigtes Problem eher durch neue Hardware oder eine Software-Verbesserung beheben lässt.
Das Tool ist für bis zu 5 Nutzer kostenlos, bei kommerziellem Gebrauch sind entsprechende Lizenzen zu kaufen. Nähere Informationen befinden sich dabei unter [Per04]
Greybox-Tests
Da die genannten Tools nicht spezifischer auf die Server-Architektur eingehen, können entsprechende Eigenschaften nicht näher untersucht werden. Daher wird nun zunächst eine einfache Methode zur Identifizierung der benötigten Zeit innerhalb der Cocoon- Ablaufreihenfolge aufgezeigt. Mit den daraufhin vorgestellten Werkzeugen können nun einzelne Java-Transformatoren genauer überprüft und entsprechend angepasst werden.
Cocoon-Watch-Transformator
Diese einfache Methode stellt einen Java-Transformator dar, welcher die Zeit zwischen erstem und zweitem Aufruf misst. Die ermittelten Ergebnisse werden in einer externen Datei gespeichert und können am einfachsten durch ein entsprechendes Excel-Skript visualisiert werden. Bisherige Messungen an der Amacont-Architektur wurden durch dieses Tool erstellt und werden als Vergleichswerte in folgenden Kapiteln herangezogen.
Extensible Java Profiler (EJP)
JUnitPerf
Der Vorteil von JUnit-Tests besteht im Grey-Box-Ansatz. Die entsprechenden Tests werden als Dekorator-Klassen parallel zur eigentlichen Anwendung erstellt. Sie erlauben damit die sofortige Überprüfung des bearbeiteten Code-Abschnittes auf Erfüllung der Anforderungen.
JUnit im Eclipse IDE
JUnitPerf ist eine Sammlung von JUnit “Test-Dekorierer”, um die Performance und Skalierbarkeit der Funktionalität bei bereits bestehenden JUnit-Tests durchzuführen. Diese Erweiterung umfasst den “TimedTest”, einen Test-Dekorierer, welcher Tests mit Zeitbeschränkung der Durchführung ablaufen lässt, den “LoadTest”, der eine simulierten Anzahl von konkurrierenden Nutzern und Iterationen durchführt sowie den “ThreadedTest”, der einen Test in einem eigenen Thread startet, was die Zeitmessung erlaubt.
Der Einsatz von JUnit mit JUnitPerf ermöglicht bereits in frühen Entwicklungsstadien die Kontrolle der Skalierbarkeit. JUnit ist im Eclipse-IDE ab Version 3.0 integriert.
Test-Suites
Eine Neuerscheinung, welche beiden Test-Suites eine kostenfreie Alternative gegenüberstellt, ist das Hyades Framework, welches unter dem Eclipse IDE eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Aufgrund der zugrunde liegenden “Common Public Licence” wird es näher beleuchtet.
JProbe
Die JProbe-Suite (Version 5.0.1) von Quest Software beinhaltet neben der Zeitmessung eine Code-Coverage-Analyse und Deadlock-Erkennung. Die Speicheranalyse (vergleiche “EJP”) übernimmt der zur Suite gehörende Memory Debugger. Der Baum aufgerufener Klassen und Funktionen wird dabei als Call-Graph dargestellt, wo selektiv für jede Methode die Aufrufer oder aufgerufene Methode ein- und ausgeblendet oder die Anzeige auf einen bestimmten Pfad reduziert werden kann. Zu jedem Knoten im Graphen, der immer eine Methode darstellt, zeigt ein PopUp detaillierte Informationen. Weiterhin gibt es eine Liste, die alle Methoden mit ihrer Ausführungszeit und der Anzahl der Aufrufe auflistet.
Der Preis von 4255 Dollar ist bei diesem Produkt trotz großer Leistungsvielfalt nicht gerechtfertigt.
Hyades
Ähnlich wie das IDE, stellt das Eclipse - Projekt Hyades selbst ein Framework dar, welches eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Damit soll [Sto04] folgend eine Interoperabilität zwischen Testwerkzeugen verschiedener Hersteller gewährleistet werden, wie auch eine schnellere Entwicklung innovativer Testwerkzeuge durch Wiederverwendung stets benötigter Komponenten.
Profiling
Die Grundfunktionalität des Profilings bei Hyades unterscheidet sich kaum von der kommerzieller Programme. Man kann Prozesse direkt aus Eclipse starten als sich auch nachträgliche mit laufenden Prozessen verbinden. Dabei können alle über das JVMPI erhältlichen Informationen gesammelt und analysiert werden, beispielsweise eine tabellarische Darstellung von Art und Anzahl der erzeugten sowie gerade existierenden Objekte, inklusive deren Größe im Speicher. Die Darstellung in der Notation eines UML2-Sequence-Diagramms ist ebenso möglich.
Hyades Ausführungsverlauf
Weiterhin können alle Methodenaufrufe und die Dauer ihrer Ausführung ausgewertet werden. Aus der Auswertung lässt sich der entsprechende Sourcecode anzeigen, so dass benötigte Änderungen zielgenau setztbar sind.
Log- und Trace-Analyse
Eine Besonderheit von Hyades stellt das “Logging Framework” dar, mit dem sich Ereignisse aus verschiedenen Quellen miteinander korrelieren lassen sollen. So können beispielsweise Einträge aus dem Logfile eines Applikationsservers mit der Dauer eines Requests in einem entfernt laufenden Java-Client überlagert werden. Die dabei ersichtliche Ursache - Wirkung - Beziehung erleichtert es deutlich, den Grund von Problemen zu erkennen.
Test browser-basierender Applikationen
Diese Funktionalität ist Jakarta JMeter sehr ähnlich. Allerdings bietet die Konfiguration beträchtliche Erleichterungen gegenüber JMeter. So kann ein Test einfach als Makro beim Durchsuchen der Website mit Hilfe des “Internet Explorers” aufgezeichnet werden. Durch Schliessen des Browser öffnet sich nun eine Übersicht der ausgeführten Requests, welche nachbearbeitet, in Schleifen mehrmals ausgeführt, und einem Datenpool zugeführt werden kann. Datenpools ermöglichen stochastische Zugriffe und somit die unter Kapitel 1.2 genannte Nutzeremulierung mit Ausschalten evtl. serverseitiger Caching-Methoden.
JUnit
Das bereits genannte JUnit ist ebenso vollständig in das Hyades-Framework implementiert und unterstützt eine wizardgesteuerte Test-Erstellung, die JavaCode-Generierung sowie die JUnit-Test-Auswertung.
Wie bei einem Framework üblich, lässt sich Hyades an allen Stellen durch eigene Funktionen erweitern. Dazu gehören unter anderem Parser für eigene Logfiles und Algorithmen zur Korrelation mehrerer Datenquellen.
Übersicht
Die soeben betrachteten Werkzeuge stellen einen Querschnitt durch das zurzeit verfügbare Angebot dar, besitzen jedoch auf Grund der Heterogenität des Entwicklungsumfeldes keinerlei Anspruch auf Vollständigkeit. Um einen schnellen Überblick zu ermöglichen, folgt nun nochmals eine Zusammenfassung.
| Bezeichnung | Hersteller | Plattform | Blackbox/ GreyBox | verteilte Anwend. / Multi-User/ Datenpool | grafische Auswertung | Lizenz /Kosten |
|---|---|---|---|---|---|---|
| Apache Jakarta JMeter | The Apache Foundation | Java | X / - | X/X/- | X | ASF |
| The Grinder | SourceForge | Java / Jython | X / - | X/X/- | X | GPL |
| JStress | ManAmplified | Java | X / - | X/X/- | - | GPL |
| PerfectLoad | Solnet solutions | Java / XML | X / - | -/X/X | X | ab 250 $ |
| JUnitPerf | Clarkware | Java-Decorateur | X / - | -/X/- | X | BSD-L |
| EJP | X | GPL | ||||
| Hyades | Eclipse.org | Eclipse-Framework | X / X | X/X/X | X | CPL |
| JProbe | Quest Software | - | X / X | X/X/X | X | 4255 $ |
| OptimizeIt! | Borland | Java | X / X | X/X/X | X | 2600 $ |
Zusammenfassung
Für die folgenden Arbeiten am Amacont-Projekt wird eine Kombination der vorgestellten Werkzeuge genutzt. Jakarta JMeter wird dabei mit geeigneten Testplänen die Auslösung der HTTP-Requests übernehmen, da alle Test von einer einzelnen Maschine aus stattfinden.
Der Cocoon-Watch-Transformator wird während den Requests das Zeitverhalten einzelner Komponenten festhalten und hilft somit, zeitintensive Transformatoren zu identifizieren und deren Verhalten unter verschiedenen Konfigurationen zu testen (vergleiche Kapitel 3.4).
Identifizierte Transformatoren in Java können nun durch Speicherprofiling bzw. JUnitPerf-Komponenten auf Schwachstellen abgeklopft und ggf. angepasst werden. Da Tomcat ein Java-basierender Webserver ist, kann er grundsätzlich komplett speicherprofiliert werden. Man darf eine komplette Aufschlüsselung aller Prozesse erwarten und ebenfalls das Zusammenspiel paralleler Prozesse ergründen. Dies benötigt jedoch enorme Ressourcen und bedeutet einen extremen Geschwindigkeitsverlust, weswegen es als unpraktikabel angesehen wird.
Als Schwerpunkt dieser Arbeit wird die Auswahl an Programmen, welche aus dem Bereich der GNU-Lizenz oder anderen freien Varianten stammen, vorgestellt. Ergänzend sollen zwei kommerzielle Lösungen kurz angesprochen werden, da diese in ihrem Leistungsumfang den meisten freien Tests weit überlegen sind.
[Win03] stellt die Hauptgrundlage der folgenden Recherche dar, da hier die Autoren verschiedenste Tools aufführen. Diese sind weniger im Anwendungsbereich der Whitebox-Tests angesiedelt, und können im konkreten Fall des Amacont-Projektes an zwei Stellen angelegt werden: Zum Einen sollen komplette Black-Box-Tests die durchschnittliche Webdienst-Bearbeitungszeit r einschließlich Wartezeit errechnen. Zum Zweiten zeigen Grey-Box - Tests direkt am Service die durchschnittliche Webdienst-Bearbeitungszeit s und daraus resultierend die durchschnittliche Webservice-Rate µ= 1/s an ausgewählten Beispielen.
Um diese beiden Grundprinzipien besser zu verstehen und einen Überblick über den grundlegenden Aufbau eines Performance-Testtools zu erlangen, wird folgend exemplarisch das Programm Apache Jakarta JMeter ausführlicher erläutert. Es soll dabei als kompletter Black-Box-Test auftreten, da das genutzte Server-System ohne genaue Kenntnisse des Gesamtaufbaus getestet und lediglich die Größe r, also die durchschnittliche Webbearbeitungszeit inklusive Wartezeit, untersucht wird.
Als Gegensatz dazu und vollständige Grey-Box-Test-Variante wird daraufhin auf die Decorator-Technik von JUnit und JUnitPerf zur Unterstützung der Testgetriebenen Programmierung kurz eingegangen. Sie motiviert jede Änderung des Programmverhaltens zuvor durch einen automatisierten Test und führt so die zuvor adHoc-motivierte Programmiertätigkeit zu einem methodischen Vorgehen.
Somit soll sich folgend von außen an das Projekt der Performanztestung herangetastet werden, um im späteren Verlauf den inneren Aufbau besser zu verstehen und die Geschwindigkeit an einzelnen Komponenten zu verbessern. Im Kapitel 5 wird auf diese Erkenntnisse aufbauend eine konkrete Änderung innerhalb der Amacont-Architektur erläutert werden, welche gleichzeitig den praktischen Anteil dieser Belegarbeit darstellt.
Blackbox-Tests
Apache Jakarta JMeter
Apache Jakarta JMeter
JMeter ist ein Werkzeug zum Ausführen von Lasttests in Client/Server-Anwendungen. Dabei wird mittels Zusammenstellen eines Testplanes spezifiziert, welche Teile der Anwendung durchlaufen werden sollen, um konkrete Ergebnisse über das Antwort-Zeit-Verhalten zu bekommen.
Graph-Visualizer des Apache JMeter
Mit Hilfe von Testplänen werden dabei die Testschritte beschrieben, welche JMeter durchlaufen muss. Ein kompletter Testplan besteht nach [Apa04] aus einem oder mehreren Testschritten, Logik-Komponenten, Listener, Sampler, Timer, Assertions und Konfigurationselementen.
Komponenten von JMeter
Ein jeder Testplan beginnt mit Testgruppen (ThreadGroups). Alle Elemente eines Testplans werden unter einer Testgruppe angeordnet, welche die dazugehörige Anzahl der Instanzen, welche JMeter zum Ausführen des gewünschten Tests nutzt, angibt. Es sind die folgenden Optionen anzugeben:
Als nächstes folgen in einer Testgruppe verschiedene Controller. Diese sind in 2 Arten unterteilt: Sampler und Logik-Controller.
Sampler geben dabei die Art des Requests an. Ein http-Request-Sampler sendet beispielsweise Requests unter Nutzung des HTTP-Protokolls. Requests können weiterhin durch Hinzufügen eines oder mehrerer Konfigurationselemente zu einem Sampler angepasst werden.
Über Logik-Controller kann die Logik angepasst werden, welche JMeter zur Entscheidung nutzt, wann ein Request gesendet wird. So kann beispielsweise ein Interleave Logik-Controller genutzt werden, um zwischen 2 HTTP-Request-Samplern zu wechseln. Ein weiterer Logik-Kontroller, der “Modification Manager”, erlaubt das Verändern eines Request-Ergebnisses.
Zur Veranschaulichung beziehen wir die Controller-Thematik kurz auf das Beispiel der Amacont-Architektur. Hier wird beispielsweise zunächst ein “Once-Only-Controller” zum Einsatz kommen, welcher den Login-Request (ein http-Request) an das System sendet. Nach erfolgreichem Login in das System wird durch einen weiteren Sampler auf eine zu testende Seite gewechselt werden. Dies ist ein einfacher Request, welcher durch keinerlei Logik gefiltert werden muss. Nach dem Laden dieser gewünschten Testseite können dann abwechselnd bestimmte Anfragen gestellt werden, welche ein “Interleave Controller” kontrolliert und steuert.
Während der Test-Durchläufe werden Informationen angesammelt. Listener stellen diese zur Verfügung. Der einfachste Vertreter ist dabei der “Graph Result Listener”, welcher die Antwortzeiten in einem Graphen wiedergibt. Listener stellen graphische Sichten auf die erhaltenen Daten zur Verfügung. Ebenfalls können durch sie gesammelte Daten in einer Datei für die spätere Anwendung gespeichert werden. Dafür stellt jeder Vertreter in JMeter ein Feld zur Verfügung, in welches der entsprechende Dateiname eingetragen werden kann.
Für gewöhnlich sendet JMeter Anfragen ohne entsprechende Wartezeiten. Da das Absetzen zu vieler Anfragen in einer sehr kurzen Zeit zu einer Überlastung des Servers führen kann, ist das Einfügen einer Verzögerung sinnvoll. Der Timer übernimmt diese Aufgabe und hält die definierte Wartezeit zwischen verschiedenen Requests ein. Bei mehreren in Reihe geschalteten Timern wird die Summe der Pausen gebildet und als Wartezeit definiert.
Assertions wiederum erlauben Behauptungen über bestimmte Test-Antworten des Servers. Bei der Benutzung von Assertions kann essentiell getestet werden, dass die Anwendung genau so antwortet, wie dies erwartet wird. Beispielsweise kann behauptet werden, dass eine Antwort auf eine bestimmte Anfrage einen bestimmten Textteil enthalten muss. Der zu suchende Text kann dabei als regulärer Ausdruck im Perl-Style angegeben werden, welcher entweder in der Antwort enthalten sein muss, oder ob der gesamte Response darauf passen soll. Wird eine Behauptung nicht erfüllt, so wird der betreffende Test als fehlgeschlagen gekennzeichnet. Um das Behauptungs-Ergebnis zu sehen, muss ein “Assertion-Listener” zur Testgruppe hinzugefügt werden.
Ein Konfigurationselement (configuration element) arbeitet ähnlich einem Sampler. Wenn gleich es auch (mit Ausnahme des http Proxy Servers) keinen Request sendet, so kann es Requests hinzufügen oder verändern. Auf ein Konfigurationselement ist lediglich innerhalb des eigenen Baumzweiges ein Zugriff möglich. Wenn also ein “HTTP Cookie Manager” innerhalb eines “Simple Logic Controllers” gelegt wird, so ist er nur von den “HTTP Request Controllern” innerhalb dieses “Simple Logic Controllers” abfragbar.
Testplanaufstellung unter JMeter
Im Beispiel könnten demnach “Web Page 1” und “Web Page 2” auf den “Cookie Manager” zugreifen, jedoch nicht “Web Page 3”.
Pre-Prozessoren ermöglichen die Ausführung von Aktionen, bevor der Sampler-Request beginnt. Wenn ein Pre-Prozessor an ein Sampler-Element angefügt wird, so wird es kurz vor dem Starten des Sampler-Requestes ausgeführt. Er wird daher oft verwendet, um Einstellungen am Sample Request zu ändern, bevor er startet, oder um Variablen zu aktualisieren, welche nicht aus dem Response-Text extrahiert wurden.
Ein Post-Prozessor-Element führt parallel dazu Aktionen kurz nach dem Sampler-Request aus. Der Post-Prozessor wird meistens zur Auswertung von Response-Daten genutzt, oft, um daraus Werte zu extrahieren.
Erstellen eines Web-Testplanes
Wie bereits unter 2.2.1.1 kurz angesprochen, beschreibt also ein Testplan eine Serie von Testschritten, die JMeter nacheinander ausführt. Ein kompletter Testplan wird dabei aus einem oder mehreren Testgruppen bestehen.
Der erste Schritt des Testplans ist das Hinzufügen eines Testgruppen-Elementes. Dieser gibt JMeter Informationen über die Anzahl der zu simulierenden Nutzer, wie viele Anfragen sie senden und wie oft sie das tun sollen. Dies stellt die Grundeinstellungen einer Testgruppe dar.
Hinzufuegen einer Test-Gruppen in JMeter
Nach der Eingabe eines aussagekräftigeren Namens für die Testgruppe folgt die Anzahl der Nutzer, die Anlaufzeit sowie die Wiederholungsanzahl. Über den “Scheduler” kann eine feste Start- und Ende-Zeit für den Test angegeben werden.
Nachdem die Nutzer definiert sind, folgt die Angabe der Aufträge, welche sie abarbeiten. Zunächst werden dazu Grundeinstellungen vorgenommen, auf welche später durch spezielle HTTP-Request-Elemente als Standard-Werte zurückgegriffen werden sollen.
Dies sind im Einzeln
Request-Grundeinstellungen in JMeter
An dieser Stelle wird aufgrund des Cookie-gestützten Amacont-Projekts der bereits erwähnte “HTTP Cookie Manager” in den Testplan eingefügt. Dadurch wird sichergestellt, dass jeder Thread seinen eigenen Session-Cookie bekommt, welcher über alle HTTP-Request Objekte geteilt wird.
Als nächstes folgen auf einzelne Requests spezialisierte Einstellungen.
Der Servername bzw. die IP kann hier weggelassen werden, da diese bereits bei den Voreinstellungen eingetragen wurde, ebenso die Port-Nummer. Angegeben werden können hier weiterhin das Protokoll, die Art der Parameterübergabe sowie der genaue Seitenaufruf. Ebenfalls kann eine zu übertragende Seite mit passendem MIME-Typ ausgestattet werden.
http-Request-Einstellungen in JMeter
Falls die User-Session nicht durch Cookies sondern per URL-Rewriting weitergegeben werden würde, käme der “HTTP-URL-Rewriting Modifier” zum Einsatz. Hierbei würde der Name der Session-ID eingetragen, so dass JMeter diesen finden und an jeden Request anhängen könnte. Falls dieser bereits einen Parameter besäße, würde dieser überschrieben werden.
URL-Rewrite-Veränderung in JMeter
Um die erzielten Ergebnisse in einer Datei zu speichern und graphisch darzustellen, folgt der “Graph Result Listener”. Bei diesem ist die gewünschte Datei zu spezifizieren, ebenso wie die anzuzeigenden Kurven. Dazu gibt es die Möglichkeiten der gesamten Daten-Darstellung, des Durchschnittswertes, des Mittelwertes, der Abweichung und des Datendurchsatzes.
Graph-Visualizer des Apache JMeter
Um den Testplan nun zu starten, genügt das Aufrufen des “Run”-Buttons. Falls das Ergebnis in einer Datei gespeichert wurde, kann diese nachträglich in einem Visualizer geöffnet werden. Jeder Visualizer zeigt dabei das Ergebnis in der vorher definierten Art und Weise.
The Grinder
Startseite “The Grinder”
Dieses Tool ist ein Framework, um Test-Skripte über eine bestimmte Anzahl von Maschinen arbeiten zu lassen. Es gibt damit die Möglichkeit, mit mehreren Rechnern gleichzeitig und synchronisiert auf einen zu testenden Rechner zuzugreifen und somit eine höhere Last auf diesen ausüben zu können. Er ist daher in die Gruppe der kompletten Black-Boxtests einzuordnen und JMeter sehr ähnlich.
Ein Unterschied besteht allerdings zum Einen in der Drei-Schichten-Architektur dieses Frameworks, welche sich aus den Arbeits-Prozessen, den Agenten-Prozessen und der Konsole zusammensetzt.
Funktionsweise von “The Grinder”
Die Arbeitsprozesse interpretieren dabei als weiteren Unterschied Jython-Testskripte und führen die darin beschriebenen Tests mit einer vorher definierten Anzahl von Arbeits-Threads aus. Die Agenten-Prozesse steuern die Arbeiter-Prozesse. Dazu läuft ein Agenten-Prozess auf jeder Client-Maschine. Zur Koordination dieser Prozesse nutzt der Anwender die Konsole, welche ebenso die einzelnen Prozesse vereinigt und die Statistiken präsentiert.
Da "The Grinder", wie auch JMeter, in Java geschrieben ist, stellt jeder dieser Prozesse eine "Java Virtual Machine" (JVM) dar. Für Hochleistungstest werden Agenten-Prozesse auf jedem Client-Rechner gestartet. Die durch diese gestarteten Arbeiter-Prozesse können von der Konsole aus kontrolliert und aufgezeichnet werden.
Ein "Test" ist hierbei ebenfalls eine Einheit von Tätigkeiten, von welchen Statistiken aufgezeichnet werden. Die Spezifikation der zu startenden Tests gibt das jeweilige Jython-Testskript an.
Das Skript wird, ähnlich dem Testplan unter JMeter, mehrmals in typischen Testszenarien ausgeführt. Jeder Arbeiterprozess hat dabei eine Anzahl von Arbeiter-Threads, und jeder Thread ruft das Skript mehrmals auf, wobei ein einzelner Aufruf des Skripts dabei als “run” bezeichnet wird.
JStress
JStress als architektur-unabhängiges Tools führt ebenso mittels verschiedener, verteilter Agenten, zentral gesteuert Testläufe durch. Es liegt in der Version 0.3 bereit, wird aber auf Grund der geringen Entwicklungshöhe in diesem Beleg nicht weiter betrachtet.
PerfectLoad
PerfectLoad kann mit mehreren tausend Nutzern, die konkurrierend HTTP-Requests abschicken, Belastungstests durchführen.
Ansichten von ”PerfectLoad”
Die dabei genutzten Requests werden vorher durch Live-Interaktion aufgezeichnet und als XML abgespeichtert. Es erleichtert somit im Gegensatz zum Referenzobjekt JMeter die Testplan-Einrichtung und Portabilität.
Das kleine Tool unterstützt ebenfalls Cookies und gibt die Möglichkeit, die Daten eines Requests eines jeweiligen virtuellen Nutzers mit Daten aus einem Daten-Pool zu manipulieren. JMeter kann diese stochastischen Zugriffe aktuell nicht emulieren. PerfectLoad ermittelt daraufhin anhand der Anforderungen, ob die getestete Anwendung diesen standhält.
Eine nützliche Option ist die Hilfe, ob sich ein etwaig gezeigtes Problem eher durch neue Hardware oder eine Software-Verbesserung beheben lässt.
Das Tool ist für bis zu 5 Nutzer kostenlos, bei kommerziellem Gebrauch sind entsprechende Lizenzen zu kaufen. Nähere Informationen befinden sich dabei unter [Per04]
Greybox-Tests
Da die genannten Tools nicht spezifischer auf die Server-Architektur eingehen, können entsprechende Eigenschaften nicht näher untersucht werden. Daher wird nun zunächst eine einfache Methode zur Identifizierung der benötigten Zeit innerhalb der Cocoon- Ablaufreihenfolge aufgezeigt. Mit den daraufhin vorgestellten Werkzeugen können nun einzelne Java-Transformatoren genauer überprüft und entsprechend angepasst werden.
Cocoon-Watch-Transformator
Diese einfache Methode stellt einen Java-Transformator dar, welcher die Zeit zwischen erstem und zweitem Aufruf misst. Die ermittelten Ergebnisse werden in einer externen Datei gespeichert und können am einfachsten durch ein entsprechendes Excel-Skript visualisiert werden. Bisherige Messungen an der Amacont-Architektur wurden durch dieses Tool erstellt und werden als Vergleichswerte in folgenden Kapiteln herangezogen.
Extensible Java Profiler (EJP)
JUnitPerf
Der Vorteil von JUnit-Tests besteht im Grey-Box-Ansatz. Die entsprechenden Tests werden als Dekorator-Klassen parallel zur eigentlichen Anwendung erstellt. Sie erlauben damit die sofortige Überprüfung des bearbeiteten Code-Abschnittes auf Erfüllung der Anforderungen.
JUnit im Eclipse IDE
JUnitPerf ist eine Sammlung von JUnit “Test-Dekorierer”, um die Performance und Skalierbarkeit der Funktionalität bei bereits bestehenden JUnit-Tests durchzuführen. Diese Erweiterung umfasst den “TimedTest”, einen Test-Dekorierer, welcher Tests mit Zeitbeschränkung der Durchführung ablaufen lässt, den “LoadTest”, der eine simulierten Anzahl von konkurrierenden Nutzern und Iterationen durchführt sowie den “ThreadedTest”, der einen Test in einem eigenen Thread startet, was die Zeitmessung erlaubt.
Der Einsatz von JUnit mit JUnitPerf ermöglicht bereits in frühen Entwicklungsstadien die Kontrolle der Skalierbarkeit. JUnit ist im Eclipse-IDE ab Version 3.0 integriert.
Test-Suites
Eine Neuerscheinung, welche beiden Test-Suites eine kostenfreie Alternative gegenüberstellt, ist das Hyades Framework, welches unter dem Eclipse IDE eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Aufgrund der zugrunde liegenden “Common Public Licence” wird es näher beleuchtet.
JProbe
Die JProbe-Suite (Version 5.0.1) von Quest Software beinhaltet neben der Zeitmessung eine Code-Coverage-Analyse und Deadlock-Erkennung. Die Speicheranalyse (vergleiche “EJP”) übernimmt der zur Suite gehörende Memory Debugger. Der Baum aufgerufener Klassen und Funktionen wird dabei als Call-Graph dargestellt, wo selektiv für jede Methode die Aufrufer oder aufgerufene Methode ein- und ausgeblendet oder die Anzeige auf einen bestimmten Pfad reduziert werden kann. Zu jedem Knoten im Graphen, der immer eine Methode darstellt, zeigt ein PopUp detaillierte Informationen. Weiterhin gibt es eine Liste, die alle Methoden mit ihrer Ausführungszeit und der Anzahl der Aufrufe auflistet.
Der Preis von 4255 Dollar ist bei diesem Produkt trotz großer Leistungsvielfalt nicht gerechtfertigt.
Hyades
Ähnlich wie das IDE, stellt das Eclipse - Projekt Hyades selbst ein Framework dar, welches eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Damit soll [Sto04] folgend eine Interoperabilität zwischen Testwerkzeugen verschiedener Hersteller gewährleistet werden, wie auch eine schnellere Entwicklung innovativer Testwerkzeuge durch Wiederverwendung stets benötigter Komponenten.
Profiling
Die Grundfunktionalität des Profilings bei Hyades unterscheidet sich kaum von der kommerzieller Programme. Man kann Prozesse direkt aus Eclipse starten als sich auch nachträgliche mit laufenden Prozessen verbinden. Dabei können alle über das JVMPI erhältlichen Informationen gesammelt und analysiert werden, beispielsweise eine tabellarische Darstellung von Art und Anzahl der erzeugten sowie gerade existierenden Objekte, inklusive deren Größe im Speicher. Die Darstellung in der Notation eines UML2-Sequence-Diagramms ist ebenso möglich.
Hyades Ausführungsverlauf
Weiterhin können alle Methodenaufrufe und die Dauer ihrer Ausführung ausgewertet werden. Aus der Auswertung lässt sich der entsprechende Sourcecode anzeigen, so dass benötigte Änderungen zielgenau setztbar sind.
Log- und Trace-Analyse
Eine Besonderheit von Hyades stellt das “Logging Framework” dar, mit dem sich Ereignisse aus verschiedenen Quellen miteinander korrelieren lassen sollen. So können beispielsweise Einträge aus dem Logfile eines Applikationsservers mit der Dauer eines Requests in einem entfernt laufenden Java-Client überlagert werden. Die dabei ersichtliche Ursache - Wirkung - Beziehung erleichtert es deutlich, den Grund von Problemen zu erkennen.
Test browser-basierender Applikationen
Diese Funktionalität ist Jakarta JMeter sehr ähnlich. Allerdings bietet die Konfiguration beträchtliche Erleichterungen gegenüber JMeter. So kann ein Test einfach als Makro beim Durchsuchen der Website mit Hilfe des “Internet Explorers” aufgezeichnet werden. Durch Schliessen des Browser öffnet sich nun eine Übersicht der ausgeführten Requests, welche nachbearbeitet, in Schleifen mehrmals ausgeführt, und einem Datenpool zugeführt werden kann. Datenpools ermöglichen stochastische Zugriffe und somit die unter Kapitel 1.2 genannte Nutzeremulierung mit Ausschalten evtl. serverseitiger Caching-Methoden.
JUnit
Das bereits genannte JUnit ist ebenso vollständig in das Hyades-Framework implementiert und unterstützt eine wizardgesteuerte Test-Erstellung, die JavaCode-Generierung sowie die JUnit-Test-Auswertung.
Wie bei einem Framework üblich, lässt sich Hyades an allen Stellen durch eigene Funktionen erweitern. Dazu gehören unter anderem Parser für eigene Logfiles und Algorithmen zur Korrelation mehrerer Datenquellen.
Übersicht
Die soeben betrachteten Werkzeuge stellen einen Querschnitt durch das zurzeit verfügbare Angebot dar, besitzen jedoch auf Grund der Heterogenität des Entwicklungsumfeldes keinerlei Anspruch auf Vollständigkeit. Um einen schnellen Überblick zu ermöglichen, folgt nun nochmals eine Zusammenfassung.
| Bezeichnung | Hersteller | Plattform | Blackbox/ GreyBox | verteilte Anwend. / Multi-User/ Datenpool | grafische Auswertung | Lizenz /Kosten |
|---|---|---|---|---|---|---|
| Apache Jakarta JMeter | The Apache Foundation | Java | X / - | X/X/- | X | ASF |
| The Grinder | SourceForge | Java / Jython | X / - | X/X/- | X | GPL |
| JStress | ManAmplified | Java | X / - | X/X/- | - | GPL |
| PerfectLoad | Solnet solutions | Java / XML | X / - | -/X/X | X | ab 250 $ |
| JUnitPerf | Clarkware | Java-Decorateur | X / - | -/X/- | X | BSD-L |
| EJP | X | GPL | ||||
| Hyades | Eclipse.org | Eclipse-Framework | X / X | X/X/X | X | CPL |
| JProbe | Quest Software | - | X / X | X/X/X | X | 4255 $ |
| OptimizeIt! | Borland | Java | X / X | X/X/X | X | 2600 $ |
Zusammenfassung
Für die folgenden Arbeiten am Amacont-Projekt wird eine Kombination der vorgestellten Werkzeuge genutzt. Jakarta JMeter wird dabei mit geeigneten Testplänen die Auslösung der HTTP-Requests übernehmen, da alle Test von einer einzelnen Maschine aus stattfinden.
Der Cocoon-Watch-Transformator wird während den Requests das Zeitverhalten einzelner Komponenten festhalten und hilft somit, zeitintensive Transformatoren zu identifizieren und deren Verhalten unter verschiedenen Konfigurationen zu testen (vergleiche Kapitel 3.4).
Identifizierte Transformatoren in Java können nun durch Speicherprofiling bzw. JUnitPerf-Komponenten auf Schwachstellen abgeklopft und ggf. angepasst werden. Da Tomcat ein Java-basierender Webserver ist, kann er grundsätzlich komplett speicherprofiliert werden. Man darf eine komplette Aufschlüsselung aller Prozesse erwarten und ebenfalls das Zusammenspiel paralleler Prozesse ergründen. Dies benötigt jedoch enorme Ressourcen und bedeutet einen extremen Geschwindigkeitsverlust, weswegen es als unpraktikabel angesehen wird.
Als Schwerpunkt dieser Arbeit wird die Auswahl an Programmen, welche aus dem Bereich der GNU-Lizenz oder anderen freien Varianten stammen, vorgestellt. Ergänzend sollen zwei kommerzielle Lösungen kurz angesprochen werden, da diese in ihrem Leistungsumfang den meisten freien Tests weit überlegen sind.
[Win03] stellt die Hauptgrundlage der folgenden Recherche dar, da hier die Autoren verschiedenste Tools aufführen. Diese sind weniger im Anwendungsbereich der Whitebox-Tests angesiedelt, und können im konkreten Fall des Amacont-Projektes an zwei Stellen angelegt werden: Zum Einen sollen komplette Black-Box-Tests die durchschnittliche Webdienst-Bearbeitungszeit r einschließlich Wartezeit errechnen. Zum Zweiten zeigen Grey-Box - Tests direkt am Service die durchschnittliche Webdienst-Bearbeitungszeit s und daraus resultierend die durchschnittliche Webservice-Rate µ= 1/s an ausgewählten Beispielen.
Um diese beiden Grundprinzipien besser zu verstehen und einen Überblick über den grundlegenden Aufbau eines Performance-Testtools zu erlangen, wird folgend exemplarisch das Programm Apache Jakarta JMeter ausführlicher erläutert. Es soll dabei als kompletter Black-Box-Test auftreten, da das genutzte Server-System ohne genaue Kenntnisse des Gesamtaufbaus getestet und lediglich die Größe r, also die durchschnittliche Webbearbeitungszeit inklusive Wartezeit, untersucht wird.
Als Gegensatz dazu und vollständige Grey-Box-Test-Variante wird daraufhin auf die Decorator-Technik von JUnit und JUnitPerf zur Unterstützung der Testgetriebenen Programmierung kurz eingegangen. Sie motiviert jede Änderung des Programmverhaltens zuvor durch einen automatisierten Test und führt so die zuvor adHoc-motivierte Programmiertätigkeit zu einem methodischen Vorgehen.
Somit soll sich folgend von außen an das Projekt der Performanztestung herangetastet werden, um im späteren Verlauf den inneren Aufbau besser zu verstehen und die Geschwindigkeit an einzelnen Komponenten zu verbessern. Im Kapitel 5 wird auf diese Erkenntnisse aufbauend eine konkrete Änderung innerhalb der Amacont-Architektur erläutert werden, welche gleichzeitig den praktischen Anteil dieser Belegarbeit darstellt.
Blackbox-Tests
Apache Jakarta JMeter
Apache Jakarta JMeter
JMeter ist ein Werkzeug zum Ausführen von Lasttests in Client/Server-Anwendungen. Dabei wird mittels Zusammenstellen eines Testplanes spezifiziert, welche Teile der Anwendung durchlaufen werden sollen, um konkrete Ergebnisse über das Antwort-Zeit-Verhalten zu bekommen.
Graph-Visualizer des Apache JMeter
Mit Hilfe von Testplänen werden dabei die Testschritte beschrieben, welche JMeter durchlaufen muss. Ein kompletter Testplan besteht nach [Apa04] aus einem oder mehreren Testschritten, Logik-Komponenten, Listener, Sampler, Timer, Assertions und Konfigurationselementen.
Komponenten von JMeter
Ein jeder Testplan beginnt mit Testgruppen (ThreadGroups). Alle Elemente eines Testplans werden unter einer Testgruppe angeordnet, welche die dazugehörige Anzahl der Instanzen, welche JMeter zum Ausführen des gewünschten Tests nutzt, angibt. Es sind die folgenden Optionen anzugeben:
Als nächstes folgen in einer Testgruppe verschiedene Controller. Diese sind in 2 Arten unterteilt: Sampler und Logik-Controller.
Sampler geben dabei die Art des Requests an. Ein http-Request-Sampler sendet beispielsweise Requests unter Nutzung des HTTP-Protokolls. Requests können weiterhin durch Hinzufügen eines oder mehrerer Konfigurationselemente zu einem Sampler angepasst werden.
Über Logik-Controller kann die Logik angepasst werden, welche JMeter zur Entscheidung nutzt, wann ein Request gesendet wird. So kann beispielsweise ein Interleave Logik-Controller genutzt werden, um zwischen 2 HTTP-Request-Samplern zu wechseln. Ein weiterer Logik-Kontroller, der “Modification Manager”, erlaubt das Verändern eines Request-Ergebnisses.
Zur Veranschaulichung beziehen wir die Controller-Thematik kurz auf das Beispiel der Amacont-Architektur. Hier wird beispielsweise zunächst ein “Once-Only-Controller” zum Einsatz kommen, welcher den Login-Request (ein http-Request) an das System sendet. Nach erfolgreichem Login in das System wird durch einen weiteren Sampler auf eine zu testende Seite gewechselt werden. Dies ist ein einfacher Request, welcher durch keinerlei Logik gefiltert werden muss. Nach dem Laden dieser gewünschten Testseite können dann abwechselnd bestimmte Anfragen gestellt werden, welche ein “Interleave Controller” kontrolliert und steuert.
Während der Test-Durchläufe werden Informationen angesammelt. Listener stellen diese zur Verfügung. Der einfachste Vertreter ist dabei der “Graph Result Listener”, welcher die Antwortzeiten in einem Graphen wiedergibt. Listener stellen graphische Sichten auf die erhaltenen Daten zur Verfügung. Ebenfalls können durch sie gesammelte Daten in einer Datei für die spätere Anwendung gespeichert werden. Dafür stellt jeder Vertreter in JMeter ein Feld zur Verfügung, in welches der entsprechende Dateiname eingetragen werden kann.
Für gewöhnlich sendet JMeter Anfragen ohne entsprechende Wartezeiten. Da das Absetzen zu vieler Anfragen in einer sehr kurzen Zeit zu einer Überlastung des Servers führen kann, ist das Einfügen einer Verzögerung sinnvoll. Der Timer übernimmt diese Aufgabe und hält die definierte Wartezeit zwischen verschiedenen Requests ein. Bei mehreren in Reihe geschalteten Timern wird die Summe der Pausen gebildet und als Wartezeit definiert.
Assertions wiederum erlauben Behauptungen über bestimmte Test-Antworten des Servers. Bei der Benutzung von Assertions kann essentiell getestet werden, dass die Anwendung genau so antwortet, wie dies erwartet wird. Beispielsweise kann behauptet werden, dass eine Antwort auf eine bestimmte Anfrage einen bestimmten Textteil enthalten muss. Der zu suchende Text kann dabei als regulärer Ausdruck im Perl-Style angegeben werden, welcher entweder in der Antwort enthalten sein muss, oder ob der gesamte Response darauf passen soll. Wird eine Behauptung nicht erfüllt, so wird der betreffende Test als fehlgeschlagen gekennzeichnet. Um das Behauptungs-Ergebnis zu sehen, muss ein “Assertion-Listener” zur Testgruppe hinzugefügt werden.
Ein Konfigurationselement (configuration element) arbeitet ähnlich einem Sampler. Wenn gleich es auch (mit Ausnahme des http Proxy Servers) keinen Request sendet, so kann es Requests hinzufügen oder verändern. Auf ein Konfigurationselement ist lediglich innerhalb des eigenen Baumzweiges ein Zugriff möglich. Wenn also ein “HTTP Cookie Manager” innerhalb eines “Simple Logic Controllers” gelegt wird, so ist er nur von den “HTTP Request Controllern” innerhalb dieses “Simple Logic Controllers” abfragbar.
Testplanaufstellung unter JMeter
Im Beispiel könnten demnach “Web Page 1” und “Web Page 2” auf den “Cookie Manager” zugreifen, jedoch nicht “Web Page 3”.
Pre-Prozessoren ermöglichen die Ausführung von Aktionen, bevor der Sampler-Request beginnt. Wenn ein Pre-Prozessor an ein Sampler-Element angefügt wird, so wird es kurz vor dem Starten des Sampler-Requestes ausgeführt. Er wird daher oft verwendet, um Einstellungen am Sample Request zu ändern, bevor er startet, oder um Variablen zu aktualisieren, welche nicht aus dem Response-Text extrahiert wurden.
Ein Post-Prozessor-Element führt parallel dazu Aktionen kurz nach dem Sampler-Request aus. Der Post-Prozessor wird meistens zur Auswertung von Response-Daten genutzt, oft, um daraus Werte zu extrahieren.
Erstellen eines Web-Testplanes
Wie bereits unter 2.2.1.1 kurz angesprochen, beschreibt also ein Testplan eine Serie von Testschritten, die JMeter nacheinander ausführt. Ein kompletter Testplan wird dabei aus einem oder mehreren Testgruppen bestehen.
Der erste Schritt des Testplans ist das Hinzufügen eines Testgruppen-Elementes. Dieser gibt JMeter Informationen über die Anzahl der zu simulierenden Nutzer, wie viele Anfragen sie senden und wie oft sie das tun sollen. Dies stellt die Grundeinstellungen einer Testgruppe dar.
Hinzufuegen einer Test-Gruppen in JMeter
Nach der Eingabe eines aussagekräftigeren Namens für die Testgruppe folgt die Anzahl der Nutzer, die Anlaufzeit sowie die Wiederholungsanzahl. Über den “Scheduler” kann eine feste Start- und Ende-Zeit für den Test angegeben werden.
Nachdem die Nutzer definiert sind, folgt die Angabe der Aufträge, welche sie abarbeiten. Zunächst werden dazu Grundeinstellungen vorgenommen, auf welche später durch spezielle HTTP-Request-Elemente als Standard-Werte zurückgegriffen werden sollen.
Dies sind im Einzeln
Request-Grundeinstellungen in JMeter
An dieser Stelle wird aufgrund des Cookie-gestützten Amacont-Projekts der bereits erwähnte “HTTP Cookie Manager” in den Testplan eingefügt. Dadurch wird sichergestellt, dass jeder Thread seinen eigenen Session-Cookie bekommt, welcher über alle HTTP-Request Objekte geteilt wird.
Als nächstes folgen auf einzelne Requests spezialisierte Einstellungen.
Der Servername bzw. die IP kann hier weggelassen werden, da diese bereits bei den Voreinstellungen eingetragen wurde, ebenso die Port-Nummer. Angegeben werden können hier weiterhin das Protokoll, die Art der Parameterübergabe sowie der genaue Seitenaufruf. Ebenfalls kann eine zu übertragende Seite mit passendem MIME-Typ ausgestattet werden.
http-Request-Einstellungen in JMeter
Falls die User-Session nicht durch Cookies sondern per URL-Rewriting weitergegeben werden würde, käme der “HTTP-URL-Rewriting Modifier” zum Einsatz. Hierbei würde der Name der Session-ID eingetragen, so dass JMeter diesen finden und an jeden Request anhängen könnte. Falls dieser bereits einen Parameter besäße, würde dieser überschrieben werden.
URL-Rewrite-Veränderung in JMeter
Um die erzielten Ergebnisse in einer Datei zu speichern und graphisch darzustellen, folgt der “Graph Result Listener”. Bei diesem ist die gewünschte Datei zu spezifizieren, ebenso wie die anzuzeigenden Kurven. Dazu gibt es die Möglichkeiten der gesamten Daten-Darstellung, des Durchschnittswertes, des Mittelwertes, der Abweichung und des Datendurchsatzes.
Graph-Visualizer des Apache JMeter
Um den Testplan nun zu starten, genügt das Aufrufen des “Run”-Buttons. Falls das Ergebnis in einer Datei gespeichert wurde, kann diese nachträglich in einem Visualizer geöffnet werden. Jeder Visualizer zeigt dabei das Ergebnis in der vorher definierten Art und Weise.
The Grinder
Startseite “The Grinder”
Dieses Tool ist ein Framework, um Test-Skripte über eine bestimmte Anzahl von Maschinen arbeiten zu lassen. Es gibt damit die Möglichkeit, mit mehreren Rechnern gleichzeitig und synchronisiert auf einen zu testenden Rechner zuzugreifen und somit eine höhere Last auf diesen ausüben zu können. Er ist daher in die Gruppe der kompletten Black-Boxtests einzuordnen und JMeter sehr ähnlich.
Ein Unterschied besteht allerdings zum Einen in der Drei-Schichten-Architektur dieses Frameworks, welche sich aus den Arbeits-Prozessen, den Agenten-Prozessen und der Konsole zusammensetzt.
Funktionsweise von “The Grinder”
Die Arbeitsprozesse interpretieren dabei als weiteren Unterschied Jython-Testskripte und führen die darin beschriebenen Tests mit einer vorher definierten Anzahl von Arbeits-Threads aus. Die Agenten-Prozesse steuern die Arbeiter-Prozesse. Dazu läuft ein Agenten-Prozess auf jeder Client-Maschine. Zur Koordination dieser Prozesse nutzt der Anwender die Konsole, welche ebenso die einzelnen Prozesse vereinigt und die Statistiken präsentiert.
Da "The Grinder", wie auch JMeter, in Java geschrieben ist, stellt jeder dieser Prozesse eine "Java Virtual Machine" (JVM) dar. Für Hochleistungstest werden Agenten-Prozesse auf jedem Client-Rechner gestartet. Die durch diese gestarteten Arbeiter-Prozesse können von der Konsole aus kontrolliert und aufgezeichnet werden.
Ein "Test" ist hierbei ebenfalls eine Einheit von Tätigkeiten, von welchen Statistiken aufgezeichnet werden. Die Spezifikation der zu startenden Tests gibt das jeweilige Jython-Testskript an.
Das Skript wird, ähnlich dem Testplan unter JMeter, mehrmals in typischen Testszenarien ausgeführt. Jeder Arbeiterprozess hat dabei eine Anzahl von Arbeiter-Threads, und jeder Thread ruft das Skript mehrmals auf, wobei ein einzelner Aufruf des Skripts dabei als “run” bezeichnet wird.
JStress
JStress als architektur-unabhängiges Tools führt ebenso mittels verschiedener, verteilter Agenten, zentral gesteuert Testläufe durch. Es liegt in der Version 0.3 bereit, wird aber auf Grund der geringen Entwicklungshöhe in diesem Beleg nicht weiter betrachtet.
PerfectLoad
PerfectLoad kann mit mehreren tausend Nutzern, die konkurrierend HTTP-Requests abschicken, Belastungstests durchführen.
Ansichten von ”PerfectLoad”
Die dabei genutzten Requests werden vorher durch Live-Interaktion aufgezeichnet und als XML abgespeichtert. Es erleichtert somit im Gegensatz zum Referenzobjekt JMeter die Testplan-Einrichtung und Portabilität.
Das kleine Tool unterstützt ebenfalls Cookies und gibt die Möglichkeit, die Daten eines Requests eines jeweiligen virtuellen Nutzers mit Daten aus einem Daten-Pool zu manipulieren. JMeter kann diese stochastischen Zugriffe aktuell nicht emulieren. PerfectLoad ermittelt daraufhin anhand der Anforderungen, ob die getestete Anwendung diesen standhält.
Eine nützliche Option ist die Hilfe, ob sich ein etwaig gezeigtes Problem eher durch neue Hardware oder eine Software-Verbesserung beheben lässt.
Das Tool ist für bis zu 5 Nutzer kostenlos, bei kommerziellem Gebrauch sind entsprechende Lizenzen zu kaufen. Nähere Informationen befinden sich dabei unter [Per04]
Greybox-Tests
Da die genannten Tools nicht spezifischer auf die Server-Architektur eingehen, können entsprechende Eigenschaften nicht näher untersucht werden. Daher wird nun zunächst eine einfache Methode zur Identifizierung der benötigten Zeit innerhalb der Cocoon- Ablaufreihenfolge aufgezeigt. Mit den daraufhin vorgestellten Werkzeugen können nun einzelne Java-Transformatoren genauer überprüft und entsprechend angepasst werden.
Cocoon-Watch-Transformator
Diese einfache Methode stellt einen Java-Transformator dar, welcher die Zeit zwischen erstem und zweitem Aufruf misst. Die ermittelten Ergebnisse werden in einer externen Datei gespeichert und können am einfachsten durch ein entsprechendes Excel-Skript visualisiert werden. Bisherige Messungen an der Amacont-Architektur wurden durch dieses Tool erstellt und werden als Vergleichswerte in folgenden Kapiteln herangezogen.
Extensible Java Profiler (EJP)
JUnitPerf
Der Vorteil von JUnit-Tests besteht im Grey-Box-Ansatz. Die entsprechenden Tests werden als Dekorator-Klassen parallel zur eigentlichen Anwendung erstellt. Sie erlauben damit die sofortige Überprüfung des bearbeiteten Code-Abschnittes auf Erfüllung der Anforderungen.
JUnit im Eclipse IDE
JUnitPerf ist eine Sammlung von JUnit “Test-Dekorierer”, um die Performance und Skalierbarkeit der Funktionalität bei bereits bestehenden JUnit-Tests durchzuführen. Diese Erweiterung umfasst den “TimedTest”, einen Test-Dekorierer, welcher Tests mit Zeitbeschränkung der Durchführung ablaufen lässt, den “LoadTest”, der eine simulierten Anzahl von konkurrierenden Nutzern und Iterationen durchführt sowie den “ThreadedTest”, der einen Test in einem eigenen Thread startet, was die Zeitmessung erlaubt.
Der Einsatz von JUnit mit JUnitPerf ermöglicht bereits in frühen Entwicklungsstadien die Kontrolle der Skalierbarkeit. JUnit ist im Eclipse-IDE ab Version 3.0 integriert.
Test-Suites
Eine Neuerscheinung, welche beiden Test-Suites eine kostenfreie Alternative gegenüberstellt, ist das Hyades Framework, welches unter dem Eclipse IDE eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Aufgrund der zugrunde liegenden “Common Public Licence” wird es näher beleuchtet.
JProbe
Die JProbe-Suite (Version 5.0.1) von Quest Software beinhaltet neben der Zeitmessung eine Code-Coverage-Analyse und Deadlock-Erkennung. Die Speicheranalyse (vergleiche “EJP”) übernimmt der zur Suite gehörende Memory Debugger. Der Baum aufgerufener Klassen und Funktionen wird dabei als Call-Graph dargestellt, wo selektiv für jede Methode die Aufrufer oder aufgerufene Methode ein- und ausgeblendet oder die Anzeige auf einen bestimmten Pfad reduziert werden kann. Zu jedem Knoten im Graphen, der immer eine Methode darstellt, zeigt ein PopUp detaillierte Informationen. Weiterhin gibt es eine Liste, die alle Methoden mit ihrer Ausführungszeit und der Anzahl der Aufrufe auflistet.
Der Preis von 4255 Dollar ist bei diesem Produkt trotz großer Leistungsvielfalt nicht gerechtfertigt.
Hyades
Ähnlich wie das IDE, stellt das Eclipse - Projekt Hyades selbst ein Framework dar, welches eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Damit soll [Sto04] folgend eine Interoperabilität zwischen Testwerkzeugen verschiedener Hersteller gewährleistet werden, wie auch eine schnellere Entwicklung innovativer Testwerkzeuge durch Wiederverwendung stets benötigter Komponenten.
Profiling
Die Grundfunktionalität des Profilings bei Hyades unterscheidet sich kaum von der kommerzieller Programme. Man kann Prozesse direkt aus Eclipse starten als sich auch nachträgliche mit laufenden Prozessen verbinden. Dabei können alle über das JVMPI erhältlichen Informationen gesammelt und analysiert werden, beispielsweise eine tabellarische Darstellung von Art und Anzahl der erzeugten sowie gerade existierenden Objekte, inklusive deren Größe im Speicher. Die Darstellung in der Notation eines UML2-Sequence-Diagramms ist ebenso möglich.
Hyades Ausführungsverlauf
Weiterhin können alle Methodenaufrufe und die Dauer ihrer Ausführung ausgewertet werden. Aus der Auswertung lässt sich der entsprechende Sourcecode anzeigen, so dass benötigte Änderungen zielgenau setztbar sind.
Log- und Trace-Analyse
Eine Besonderheit von Hyades stellt das “Logging Framework” dar, mit dem sich Ereignisse aus verschiedenen Quellen miteinander korrelieren lassen sollen. So können beispielsweise Einträge aus dem Logfile eines Applikationsservers mit der Dauer eines Requests in einem entfernt laufenden Java-Client überlagert werden. Die dabei ersichtliche Ursache - Wirkung - Beziehung erleichtert es deutlich, den Grund von Problemen zu erkennen.
Test browser-basierender Applikationen
Diese Funktionalität ist Jakarta JMeter sehr ähnlich. Allerdings bietet die Konfiguration beträchtliche Erleichterungen gegenüber JMeter. So kann ein Test einfach als Makro beim Durchsuchen der Website mit Hilfe des “Internet Explorers” aufgezeichnet werden. Durch Schliessen des Browser öffnet sich nun eine Übersicht der ausgeführten Requests, welche nachbearbeitet, in Schleifen mehrmals ausgeführt, und einem Datenpool zugeführt werden kann. Datenpools ermöglichen stochastische Zugriffe und somit die unter Kapitel 1.2 genannte Nutzeremulierung mit Ausschalten evtl. serverseitiger Caching-Methoden.
JUnit
Das bereits genannte JUnit ist ebenso vollständig in das Hyades-Framework implementiert und unterstützt eine wizardgesteuerte Test-Erstellung, die JavaCode-Generierung sowie die JUnit-Test-Auswertung.
Wie bei einem Framework üblich, lässt sich Hyades an allen Stellen durch eigene Funktionen erweitern. Dazu gehören unter anderem Parser für eigene Logfiles und Algorithmen zur Korrelation mehrerer Datenquellen.
Übersicht
Die soeben betrachteten Werkzeuge stellen einen Querschnitt durch das zurzeit verfügbare Angebot dar, besitzen jedoch auf Grund der Heterogenität des Entwicklungsumfeldes keinerlei Anspruch auf Vollständigkeit. Um einen schnellen Überblick zu ermöglichen, folgt nun nochmals eine Zusammenfassung.
| Bezeichnung | Hersteller | Plattform | Blackbox/ GreyBox | verteilte Anwend. / Multi-User/ Datenpool | grafische Auswertung | Lizenz /Kosten |
|---|---|---|---|---|---|---|
| Apache Jakarta JMeter | The Apache Foundation | Java | X / - | X/X/- | X | ASF |
| The Grinder | SourceForge | Java / Jython | X / - | X/X/- | X | GPL |
| JStress | ManAmplified | Java | X / - | X/X/- | - | GPL |
| PerfectLoad | Solnet solutions | Java / XML | X / - | -/X/X | X | ab 250 $ |
| JUnitPerf | Clarkware | Java-Decorateur | X / - | -/X/- | X | BSD-L |
| EJP | X | GPL | ||||
| Hyades | Eclipse.org | Eclipse-Framework | X / X | X/X/X | X | CPL |
| JProbe | Quest Software | - | X / X | X/X/X | X | 4255 $ |
| OptimizeIt! | Borland | Java | X / X | X/X/X | X | 2600 $ |
Zusammenfassung
Für die folgenden Arbeiten am Amacont-Projekt wird eine Kombination der vorgestellten Werkzeuge genutzt. Jakarta JMeter wird dabei mit geeigneten Testplänen die Auslösung der HTTP-Requests übernehmen, da alle Test von einer einzelnen Maschine aus stattfinden.
Der Cocoon-Watch-Transformator wird während den Requests das Zeitverhalten einzelner Komponenten festhalten und hilft somit, zeitintensive Transformatoren zu identifizieren und deren Verhalten unter verschiedenen Konfigurationen zu testen (vergleiche Kapitel 3.4).
Identifizierte Transformatoren in Java können nun durch Speicherprofiling bzw. JUnitPerf-Komponenten auf Schwachstellen abgeklopft und ggf. angepasst werden. Da Tomcat ein Java-basierender Webserver ist, kann er grundsätzlich komplett speicherprofiliert werden. Man darf eine komplette Aufschlüsselung aller Prozesse erwarten und ebenfalls das Zusammenspiel paralleler Prozesse ergründen. Dies benötigt jedoch enorme Ressourcen und bedeutet einen extremen Geschwindigkeitsverlust, weswegen es als unpraktikabel angesehen wird.
Als Schwerpunkt dieser Arbeit wird die Auswahl an Programmen, welche aus dem Bereich der GNU-Lizenz oder anderen freien Varianten stammen, vorgestellt. Ergänzend sollen zwei kommerzielle Lösungen kurz angesprochen werden, da diese in ihrem Leistungsumfang den meisten freien Tests weit überlegen sind.
[Win03] stellt die Hauptgrundlage der folgenden Recherche dar, da hier die Autoren verschiedenste Tools aufführen. Diese sind weniger im Anwendungsbereich der Whitebox-Tests angesiedelt, und können im konkreten Fall des Amacont-Projektes an zwei Stellen angelegt werden: Zum Einen sollen komplette Black-Box-Tests die durchschnittliche Webdienst-Bearbeitungszeit r einschließlich Wartezeit errechnen. Zum Zweiten zeigen Grey-Box - Tests direkt am Service die durchschnittliche Webdienst-Bearbeitungszeit s und daraus resultierend die durchschnittliche Webservice-Rate µ= 1/s an ausgewählten Beispielen.
Um diese beiden Grundprinzipien besser zu verstehen und einen Überblick über den grundlegenden Aufbau eines Performance-Testtools zu erlangen, wird folgend exemplarisch das Programm Apache Jakarta JMeter ausführlicher erläutert. Es soll dabei als kompletter Black-Box-Test auftreten, da das genutzte Server-System ohne genaue Kenntnisse des Gesamtaufbaus getestet und lediglich die Größe r, also die durchschnittliche Webbearbeitungszeit inklusive Wartezeit, untersucht wird.
Als Gegensatz dazu und vollständige Grey-Box-Test-Variante wird daraufhin auf die Decorator-Technik von JUnit und JUnitPerf zur Unterstützung der Testgetriebenen Programmierung kurz eingegangen. Sie motiviert jede Änderung des Programmverhaltens zuvor durch einen automatisierten Test und führt so die zuvor adHoc-motivierte Programmiertätigkeit zu einem methodischen Vorgehen.
Somit soll sich folgend von außen an das Projekt der Performanztestung herangetastet werden, um im späteren Verlauf den inneren Aufbau besser zu verstehen und die Geschwindigkeit an einzelnen Komponenten zu verbessern. Im Kapitel 5 wird auf diese Erkenntnisse aufbauend eine konkrete Änderung innerhalb der Amacont-Architektur erläutert werden, welche gleichzeitig den praktischen Anteil dieser Belegarbeit darstellt.
Blackbox-Tests
Apache Jakarta JMeter
Apache Jakarta JMeter
JMeter ist ein Werkzeug zum Ausführen von Lasttests in Client/Server-Anwendungen. Dabei wird mittels Zusammenstellen eines Testplanes spezifiziert, welche Teile der Anwendung durchlaufen werden sollen, um konkrete Ergebnisse über das Antwort-Zeit-Verhalten zu bekommen.
Graph-Visualizer des Apache JMeter
Mit Hilfe von Testplänen werden dabei die Testschritte beschrieben, welche JMeter durchlaufen muss. Ein kompletter Testplan besteht nach [Apa04] aus einem oder mehreren Testschritten, Logik-Komponenten, Listener, Sampler, Timer, Assertions und Konfigurationselementen.
Komponenten von JMeter
Ein jeder Testplan beginnt mit Testgruppen (ThreadGroups). Alle Elemente eines Testplans werden unter einer Testgruppe angeordnet, welche die dazugehörige Anzahl der Instanzen, welche JMeter zum Ausführen des gewünschten Tests nutzt, angibt. Es sind die folgenden Optionen anzugeben:
- Instanzen-Anzahl
Die Instanzen Anzahl definiert, wie viele Instanzen gleichzeitig auf das zu testende Objekt zugreifen.
- Anlauf-Zeit
Eine Anlauf-Zeit gibt an, wie lange JMeter benötigen soll, um die volle Instanzen-Anzahl auf das Testobjekt zu leiten. Wenn 10 Instanzen genutzt werden und eine Anlaufzeit von 100 Sekunden angegeben ist, so startet JMeter innerhalb dieses Zeitraums alle 10 Sekunden eine weitere Instanz.
- Wiederholungszahl des Tests
Standardmäßig läuft eine Testgruppe unbegrenzt oft durch Ihre Elemente. Alternativ dazu kann die Anzahl der Durchläufe festgelegt werden. Wird 1 angegeben, so wird JMeter die Testgruppe nur einmal durchlaufen.
Als nächstes folgen in einer Testgruppe verschiedene Controller. Diese sind in 2 Arten unterteilt: Sampler und Logik-Controller.
Sampler geben dabei die Art des Requests an. Ein http-Request-Sampler sendet beispielsweise Requests unter Nutzung des HTTP-Protokolls. Requests können weiterhin durch Hinzufügen eines oder mehrerer Konfigurationselemente zu einem Sampler angepasst werden.
Über Logik-Controller kann die Logik angepasst werden, welche JMeter zur Entscheidung nutzt, wann ein Request gesendet wird. So kann beispielsweise ein Interleave Logik-Controller genutzt werden, um zwischen 2 HTTP-Request-Samplern zu wechseln. Ein weiterer Logik-Kontroller, der “Modification Manager”, erlaubt das Verändern eines Request-Ergebnisses.
Zur Veranschaulichung beziehen wir die Controller-Thematik kurz auf das Beispiel der Amacont-Architektur. Hier wird beispielsweise zunächst ein “Once-Only-Controller” zum Einsatz kommen, welcher den Login-Request (ein http-Request) an das System sendet. Nach erfolgreichem Login in das System wird durch einen weiteren Sampler auf eine zu testende Seite gewechselt werden. Dies ist ein einfacher Request, welcher durch keinerlei Logik gefiltert werden muss. Nach dem Laden dieser gewünschten Testseite können dann abwechselnd bestimmte Anfragen gestellt werden, welche ein “Interleave Controller” kontrolliert und steuert.
Während der Test-Durchläufe werden Informationen angesammelt. Listener stellen diese zur Verfügung. Der einfachste Vertreter ist dabei der “Graph Result Listener”, welcher die Antwortzeiten in einem Graphen wiedergibt. Listener stellen graphische Sichten auf die erhaltenen Daten zur Verfügung. Ebenfalls können durch sie gesammelte Daten in einer Datei für die spätere Anwendung gespeichert werden. Dafür stellt jeder Vertreter in JMeter ein Feld zur Verfügung, in welches der entsprechende Dateiname eingetragen werden kann.
Für gewöhnlich sendet JMeter Anfragen ohne entsprechende Wartezeiten. Da das Absetzen zu vieler Anfragen in einer sehr kurzen Zeit zu einer Überlastung des Servers führen kann, ist das Einfügen einer Verzögerung sinnvoll. Der Timer übernimmt diese Aufgabe und hält die definierte Wartezeit zwischen verschiedenen Requests ein. Bei mehreren in Reihe geschalteten Timern wird die Summe der Pausen gebildet und als Wartezeit definiert.
Assertions wiederum erlauben Behauptungen über bestimmte Test-Antworten des Servers. Bei der Benutzung von Assertions kann essentiell getestet werden, dass die Anwendung genau so antwortet, wie dies erwartet wird. Beispielsweise kann behauptet werden, dass eine Antwort auf eine bestimmte Anfrage einen bestimmten Textteil enthalten muss. Der zu suchende Text kann dabei als regulärer Ausdruck im Perl-Style angegeben werden, welcher entweder in der Antwort enthalten sein muss, oder ob der gesamte Response darauf passen soll. Wird eine Behauptung nicht erfüllt, so wird der betreffende Test als fehlgeschlagen gekennzeichnet. Um das Behauptungs-Ergebnis zu sehen, muss ein “Assertion-Listener” zur Testgruppe hinzugefügt werden.
Ein Konfigurationselement (configuration element) arbeitet ähnlich einem Sampler. Wenn gleich es auch (mit Ausnahme des http Proxy Servers) keinen Request sendet, so kann es Requests hinzufügen oder verändern. Auf ein Konfigurationselement ist lediglich innerhalb des eigenen Baumzweiges ein Zugriff möglich. Wenn also ein “HTTP Cookie Manager” innerhalb eines “Simple Logic Controllers” gelegt wird, so ist er nur von den “HTTP Request Controllern” innerhalb dieses “Simple Logic Controllers” abfragbar.
Testplanaufstellung unter JMeter
Im Beispiel könnten demnach “Web Page 1” und “Web Page 2” auf den “Cookie Manager” zugreifen, jedoch nicht “Web Page 3”.
Pre-Prozessoren ermöglichen die Ausführung von Aktionen, bevor der Sampler-Request beginnt. Wenn ein Pre-Prozessor an ein Sampler-Element angefügt wird, so wird es kurz vor dem Starten des Sampler-Requestes ausgeführt. Er wird daher oft verwendet, um Einstellungen am Sample Request zu ändern, bevor er startet, oder um Variablen zu aktualisieren, welche nicht aus dem Response-Text extrahiert wurden.
Ein Post-Prozessor-Element führt parallel dazu Aktionen kurz nach dem Sampler-Request aus. Der Post-Prozessor wird meistens zur Auswertung von Response-Daten genutzt, oft, um daraus Werte zu extrahieren.
Erstellen eines Web-Testplanes
Wie bereits unter 2.2.1.1 kurz angesprochen, beschreibt also ein Testplan eine Serie von Testschritten, die JMeter nacheinander ausführt. Ein kompletter Testplan wird dabei aus einem oder mehreren Testgruppen bestehen.
Der erste Schritt des Testplans ist das Hinzufügen eines Testgruppen-Elementes. Dieser gibt JMeter Informationen über die Anzahl der zu simulierenden Nutzer, wie viele Anfragen sie senden und wie oft sie das tun sollen. Dies stellt die Grundeinstellungen einer Testgruppe dar.
Hinzufuegen einer Test-Gruppen in JMeter
Nach der Eingabe eines aussagekräftigeren Namens für die Testgruppe folgt die Anzahl der Nutzer, die Anlaufzeit sowie die Wiederholungsanzahl. Über den “Scheduler” kann eine feste Start- und Ende-Zeit für den Test angegeben werden.
Nachdem die Nutzer definiert sind, folgt die Angabe der Aufträge, welche sie abarbeiten. Zunächst werden dazu Grundeinstellungen vorgenommen, auf welche später durch spezielle HTTP-Request-Elemente als Standard-Werte zurückgegriffen werden sollen.
Dies sind im Einzeln
- ein frei wählbarer Name
- der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
- die Portnummer, auf welcher der Server getestet werden soll.
- der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.
Request-Grundeinstellungen in JMeter
An dieser Stelle wird aufgrund des Cookie-gestützten Amacont-Projekts der bereits erwähnte “HTTP Cookie Manager” in den Testplan eingefügt. Dadurch wird sichergestellt, dass jeder Thread seinen eigenen Session-Cookie bekommt, welcher über alle HTTP-Request Objekte geteilt wird.
Als nächstes folgen auf einzelne Requests spezialisierte Einstellungen.
Der Servername bzw. die IP kann hier weggelassen werden, da diese bereits bei den Voreinstellungen eingetragen wurde, ebenso die Port-Nummer. Angegeben werden können hier weiterhin das Protokoll, die Art der Parameterübergabe sowie der genaue Seitenaufruf. Ebenfalls kann eine zu übertragende Seite mit passendem MIME-Typ ausgestattet werden.
http-Request-Einstellungen in JMeter
Falls die User-Session nicht durch Cookies sondern per URL-Rewriting weitergegeben werden würde, käme der “HTTP-URL-Rewriting Modifier” zum Einsatz. Hierbei würde der Name der Session-ID eingetragen, so dass JMeter diesen finden und an jeden Request anhängen könnte. Falls dieser bereits einen Parameter besäße, würde dieser überschrieben werden.
URL-Rewrite-Veränderung in JMeter
Um die erzielten Ergebnisse in einer Datei zu speichern und graphisch darzustellen, folgt der “Graph Result Listener”. Bei diesem ist die gewünschte Datei zu spezifizieren, ebenso wie die anzuzeigenden Kurven. Dazu gibt es die Möglichkeiten der gesamten Daten-Darstellung, des Durchschnittswertes, des Mittelwertes, der Abweichung und des Datendurchsatzes.
Graph-Visualizer des Apache JMeter
Um den Testplan nun zu starten, genügt das Aufrufen des “Run”-Buttons. Falls das Ergebnis in einer Datei gespeichert wurde, kann diese nachträglich in einem Visualizer geöffnet werden. Jeder Visualizer zeigt dabei das Ergebnis in der vorher definierten Art und Weise.
The Grinder
Startseite “The Grinder”
Dieses Tool ist ein Framework, um Test-Skripte über eine bestimmte Anzahl von Maschinen arbeiten zu lassen. Es gibt damit die Möglichkeit, mit mehreren Rechnern gleichzeitig und synchronisiert auf einen zu testenden Rechner zuzugreifen und somit eine höhere Last auf diesen ausüben zu können. Er ist daher in die Gruppe der kompletten Black-Boxtests einzuordnen und JMeter sehr ähnlich.
Ein Unterschied besteht allerdings zum Einen in der Drei-Schichten-Architektur dieses Frameworks, welche sich aus den Arbeits-Prozessen, den Agenten-Prozessen und der Konsole zusammensetzt.
Funktionsweise von “The Grinder”
Die Arbeitsprozesse interpretieren dabei als weiteren Unterschied Jython-Testskripte und führen die darin beschriebenen Tests mit einer vorher definierten Anzahl von Arbeits-Threads aus. Die Agenten-Prozesse steuern die Arbeiter-Prozesse. Dazu läuft ein Agenten-Prozess auf jeder Client-Maschine. Zur Koordination dieser Prozesse nutzt der Anwender die Konsole, welche ebenso die einzelnen Prozesse vereinigt und die Statistiken präsentiert.
Da "The Grinder", wie auch JMeter, in Java geschrieben ist, stellt jeder dieser Prozesse eine "Java Virtual Machine" (JVM) dar. Für Hochleistungstest werden Agenten-Prozesse auf jedem Client-Rechner gestartet. Die durch diese gestarteten Arbeiter-Prozesse können von der Konsole aus kontrolliert und aufgezeichnet werden.
Ein "Test" ist hierbei ebenfalls eine Einheit von Tätigkeiten, von welchen Statistiken aufgezeichnet werden. Die Spezifikation der zu startenden Tests gibt das jeweilige Jython-Testskript an.
Das Skript wird, ähnlich dem Testplan unter JMeter, mehrmals in typischen Testszenarien ausgeführt. Jeder Arbeiterprozess hat dabei eine Anzahl von Arbeiter-Threads, und jeder Thread ruft das Skript mehrmals auf, wobei ein einzelner Aufruf des Skripts dabei als “run” bezeichnet wird.
JStress
JStress als architektur-unabhängiges Tools führt ebenso mittels verschiedener, verteilter Agenten, zentral gesteuert Testläufe durch. Es liegt in der Version 0.3 bereit, wird aber auf Grund der geringen Entwicklungshöhe in diesem Beleg nicht weiter betrachtet.
PerfectLoad
PerfectLoad kann mit mehreren tausend Nutzern, die konkurrierend HTTP-Requests abschicken, Belastungstests durchführen.
Ansichten von ”PerfectLoad”
Die dabei genutzten Requests werden vorher durch Live-Interaktion aufgezeichnet und als XML abgespeichtert. Es erleichtert somit im Gegensatz zum Referenzobjekt JMeter die Testplan-Einrichtung und Portabilität.
Das kleine Tool unterstützt ebenfalls Cookies und gibt die Möglichkeit, die Daten eines Requests eines jeweiligen virtuellen Nutzers mit Daten aus einem Daten-Pool zu manipulieren. JMeter kann diese stochastischen Zugriffe aktuell nicht emulieren. PerfectLoad ermittelt daraufhin anhand der Anforderungen, ob die getestete Anwendung diesen standhält.
Eine nützliche Option ist die Hilfe, ob sich ein etwaig gezeigtes Problem eher durch neue Hardware oder eine Software-Verbesserung beheben lässt.
Das Tool ist für bis zu 5 Nutzer kostenlos, bei kommerziellem Gebrauch sind entsprechende Lizenzen zu kaufen. Nähere Informationen befinden sich dabei unter [Per04]
Greybox-Tests
Da die genannten Tools nicht spezifischer auf die Server-Architektur eingehen, können entsprechende Eigenschaften nicht näher untersucht werden. Daher wird nun zunächst eine einfache Methode zur Identifizierung der benötigten Zeit innerhalb der Cocoon- Ablaufreihenfolge aufgezeigt. Mit den daraufhin vorgestellten Werkzeugen können nun einzelne Java-Transformatoren genauer überprüft und entsprechend angepasst werden.
Cocoon-Watch-Transformator
Diese einfache Methode stellt einen Java-Transformator dar, welcher die Zeit zwischen erstem und zweitem Aufruf misst. Die ermittelten Ergebnisse werden in einer externen Datei gespeichert und können am einfachsten durch ein entsprechendes Excel-Skript visualisiert werden. Bisherige Messungen an der Amacont-Architektur wurden durch dieses Tool erstellt und werden als Vergleichswerte in folgenden Kapiteln herangezogen.
Extensible Java Profiler (EJP)
JUnitPerf
Der Vorteil von JUnit-Tests besteht im Grey-Box-Ansatz. Die entsprechenden Tests werden als Dekorator-Klassen parallel zur eigentlichen Anwendung erstellt. Sie erlauben damit die sofortige Überprüfung des bearbeiteten Code-Abschnittes auf Erfüllung der Anforderungen.
JUnit im Eclipse IDE
JUnitPerf ist eine Sammlung von JUnit “Test-Dekorierer”, um die Performance und Skalierbarkeit der Funktionalität bei bereits bestehenden JUnit-Tests durchzuführen. Diese Erweiterung umfasst den “TimedTest”, einen Test-Dekorierer, welcher Tests mit Zeitbeschränkung der Durchführung ablaufen lässt, den “LoadTest”, der eine simulierten Anzahl von konkurrierenden Nutzern und Iterationen durchführt sowie den “ThreadedTest”, der einen Test in einem eigenen Thread startet, was die Zeitmessung erlaubt.
Der Einsatz von JUnit mit JUnitPerf ermöglicht bereits in frühen Entwicklungsstadien die Kontrolle der Skalierbarkeit. JUnit ist im Eclipse-IDE ab Version 3.0 integriert.
Test-Suites
Eine Neuerscheinung, welche beiden Test-Suites eine kostenfreie Alternative gegenüberstellt, ist das Hyades Framework, welches unter dem Eclipse IDE eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Aufgrund der zugrunde liegenden “Common Public Licence” wird es näher beleuchtet.
JProbe
Die JProbe-Suite (Version 5.0.1) von Quest Software beinhaltet neben der Zeitmessung eine Code-Coverage-Analyse und Deadlock-Erkennung. Die Speicheranalyse (vergleiche “EJP”) übernimmt der zur Suite gehörende Memory Debugger. Der Baum aufgerufener Klassen und Funktionen wird dabei als Call-Graph dargestellt, wo selektiv für jede Methode die Aufrufer oder aufgerufene Methode ein- und ausgeblendet oder die Anzeige auf einen bestimmten Pfad reduziert werden kann. Zu jedem Knoten im Graphen, der immer eine Methode darstellt, zeigt ein PopUp detaillierte Informationen. Weiterhin gibt es eine Liste, die alle Methoden mit ihrer Ausführungszeit und der Anzahl der Aufrufe auflistet.
Der Preis von 4255 Dollar ist bei diesem Produkt trotz großer Leistungsvielfalt nicht gerechtfertigt.
Hyades
Ähnlich wie das IDE, stellt das Eclipse - Projekt Hyades selbst ein Framework dar, welches eine herstellerunabhängige Infrastruktur zur Erstellung von automatischen Testwerkzeugen bietet. Damit soll [Sto04] folgend eine Interoperabilität zwischen Testwerkzeugen verschiedener Hersteller gewährleistet werden, wie auch eine schnellere Entwicklung innovativer Testwerkzeuge durch Wiederverwendung stets benötigter Komponenten.
Profiling
Die Grundfunktionalität des Profilings bei Hyades unterscheidet sich kaum von der kommerzieller Programme. Man kann Prozesse direkt aus Eclipse starten als sich auch nachträgliche mit laufenden Prozessen verbinden. Dabei können alle über das JVMPI erhältlichen Informationen gesammelt und analysiert werden, beispielsweise eine tabellarische Darstellung von Art und Anzahl der erzeugten sowie gerade existierenden Objekte, inklusive deren Größe im Speicher. Die Darstellung in der Notation eines UML2-Sequence-Diagramms ist ebenso möglich.
Hyades Ausführungsverlauf
Weiterhin können alle Methodenaufrufe und die Dauer ihrer Ausführung ausgewertet werden. Aus der Auswertung lässt sich der entsprechende Sourcecode anzeigen, so dass benötigte Änderungen zielgenau setztbar sind.
Log- und Trace-Analyse
Eine Besonderheit von Hyades stellt das “Logging Framework” dar, mit dem sich Ereignisse aus verschiedenen Quellen miteinander korrelieren lassen sollen. So können beispielsweise Einträge aus dem Logfile eines Applikationsservers mit der Dauer eines Requests in einem entfernt laufenden Java-Client überlagert werden. Die dabei ersichtliche Ursache - Wirkung - Beziehung erleichtert es deutlich, den Grund von Problemen zu erkennen.
Test browser-basierender Applikationen
Diese Funktionalität ist Jakarta JMeter sehr ähnlich. Allerdings bietet die Konfiguration beträchtliche Erleichterungen gegenüber JMeter. So kann ein Test einfach als Makro beim Durchsuchen der Website mit Hilfe des “Internet Explorers” aufgezeichnet werden. Durch Schliessen des Browser öffnet sich nun eine Übersicht der ausgeführten Requests, welche nachbearbeitet, in Schleifen mehrmals ausgeführt, und einem Datenpool zugeführt werden kann. Datenpools ermöglichen stochastische Zugriffe und somit die unter Kapitel 1.2 genannte Nutzeremulierung mit Ausschalten evtl. serverseitiger Caching-Methoden.
JUnit
Das bereits genannte JUnit ist ebenso vollständig in das Hyades-Framework implementiert und unterstützt eine wizardgesteuerte Test-Erstellung, die JavaCode-Generierung sowie die JUnit-Test-Auswertung.
Wie bei einem Framework üblich, lässt sich Hyades an allen Stellen durch eigene Funktionen erweitern. Dazu gehören unter anderem Parser für eigene Logfiles und Algorithmen zur Korrelation mehrerer Datenquellen.
Übersicht
Die soeben betrachteten Werkzeuge stellen einen Querschnitt durch das zurzeit verfügbare Angebot dar, besitzen jedoch auf Grund der Heterogenität des Entwicklungsumfeldes keinerlei Anspruch auf Vollständigkeit. Um einen schnellen Überblick zu ermöglichen, folgt nun nochmals eine Zusammenfassung.
| Bezeichnung | Hersteller | Plattform | Blackbox/ GreyBox | verteilte Anwend. / Multi-User/ Datenpool | grafische Auswertung | Lizenz /Kosten |
|---|---|---|---|---|---|---|
| Apache Jakarta JMeter | The Apache Foundation | Java | X / - | X/X/- | X | ASF |
| The Grinder | SourceForge | Java / Jython | X / - | X/X/- | X | GPL |
| JStress | ManAmplified | Java | X / - | X/X/- | - | GPL |
| PerfectLoad | Solnet solutions | Java / XML | X / - | -/X/X | X | ab 250 $ |
| JUnitPerf | Clarkware | Java-Decorateur | X / - | -/X/- | X | BSD-L |
| EJP | X | GPL | ||||
| Hyades | Eclipse.org | Eclipse-Framework | X / X | X/X/X | X | CPL |
| JProbe | Quest Software | - | X / X | X/X/X | X | 4255 $ |
| OptimizeIt! | Borland | Java | X / X | X/X/X | X | 2600 $ |
Zusammenfassung
Für die folgenden Arbeiten am Amacont-Projekt wird eine Kombination der vorgestellten Werkzeuge genutzt. Jakarta JMeter wird dabei mit geeigneten Testplänen die Auslösung der HTTP-Requests übernehmen, da alle Test von einer einzelnen Maschine aus stattfinden.
Der Cocoon-Watch-Transformator wird während den Requests das Zeitverhalten einzelner Komponenten festhalten und hilft somit, zeitintensive Transformatoren zu identifizieren und deren Verhalten unter verschiedenen Konfigurationen zu testen (vergleiche Kapitel 3.4).
Identifizierte Transformatoren in Java können nun durch Speicherprofiling bzw. JUnitPerf-Komponenten auf Schwachstellen abgeklopft und ggf. angepasst werden. Da Tomcat ein Java-basierender Webserver ist, kann er grundsätzlich komplett speicherprofiliert werden. Man darf eine komplette Aufschlüsselung aller Prozesse erwarten und ebenfalls das Zusammenspiel paralleler Prozesse ergründen. Dies benötigt jedoch enorme Ressourcen und bedeutet einen extremen Geschwindigkeitsverlust, weswegen es als unpraktikabel angesehen wird.