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

                          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 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 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 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

                              1. ein frei wählbarer Name
                              2. der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
                              3. die Portnummer, auf welcher der Server getestet werden soll.
                              4. der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.

                              Request-Grundeinstellungen in JMeter 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 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 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 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” 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” 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” 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 Extensible Java Profiler (EJP) ist ein open-source profiling Tool für Java mit einer skalierbaren und erweiterbaren Architektur. Er ist ein Entwicklungswerkzeug um die Performance von Javakomponenten zu steigern, indem er hilft, ressourcenverbrauchende Prozesse zu finden und anzupassen.

                              Im Gegensatz zu reinen Black-Box-Test mit dem gesamten Server, erlaubt er mit Hilfe des Speicherprofiling direkt im Java-Quellcode anzugreifen und einzelne Klassen auf ihre Performanz zu testen und deren Hierarchie-Baum anzuzeigen, wobei bestimmte Elemente versteckt oder hervorgehoben werden können. Über das “JVMPI” werden Speicherstatistiken erstellt, aus denen das Speicherverhalten während des Ausführens einer Anwendung analysiert und eine Anzahl von Ausführungszeiten bestimmter Methoden gespeichert werden kann.

                              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 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.

                              Die vorgestellten Testkategorien, also der reinen Black-Box-Test, der durch Speicherprofiling erstellte Greybox-Test und der Dekorator-Test, werden von Herstellern kommerzieller Lösungen in Test-Suiten gebündelt. Die wichtigsten Vertreter hierbei stammen aus dem Hause Quest Software (JProbe), sowie Borland (OptimizeIT!).

                              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.

                              Günstiger ist OptimizeIt 6.0 von Borland mit 2600 Dollar. Es enthält ebenfalls Code-Coverage-Analyse sowie Deadlock-Erkennug und besitzt eine gut durchdachte Ansicht der Performance-Daten. Für den Call-Tree bietet das Produkt eine Baum- sowie eine Graph-Ansicht mit zusätzlich ermittelten HotSpots. Per Schieberegler passt man den Graph schnell auf die performance-relevanten Ausführungspfade an, indem einfach alle Methoden mit geringem Zeitverbrauch ausgeblendet werden.

                              Ä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

                              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.

                              Übersicht Testmethoden adaptiver Websysteme
                              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 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 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 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

                          1. ein frei wählbarer Name
                          2. der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
                          3. die Portnummer, auf welcher der Server getestet werden soll.
                          4. der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.

                          Request-Grundeinstellungen in JMeter 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 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 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 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” 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” 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” 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.

                          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 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.

                          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

                          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.

                          Übersicht Testmethoden adaptiver Websysteme
                          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 $

                      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 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 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 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

                      1. ein frei wählbarer Name
                      2. der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
                      3. die Portnummer, auf welcher der Server getestet werden soll.
                      4. der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.

                      Request-Grundeinstellungen in JMeter 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 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 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 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” 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” 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” 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.

                      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 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.

                      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

                      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.

                  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 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 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 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

                  1. ein frei wählbarer Name
                  2. der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
                  3. die Portnummer, auf welcher der Server getestet werden soll.
                  4. der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.

                  Request-Grundeinstellungen in JMeter 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 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 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 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” 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” 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” 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.

                  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 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.

                  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

                  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.

              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 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 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 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

              1. ein frei wählbarer Name
              2. der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
              3. die Portnummer, auf welcher der Server getestet werden soll.
              4. der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.

              Request-Grundeinstellungen in JMeter 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 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 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 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” 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” 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” 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.

              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 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.

              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.

          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 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 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 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

          1. ein frei wählbarer Name
          2. der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
          3. die Portnummer, auf welcher der Server getestet werden soll.
          4. der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.

          Request-Grundeinstellungen in JMeter 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 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 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 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” 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” 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” 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.

          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 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.

          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.

      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 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 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 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

      1. ein frei wählbarer Name
      2. der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
      3. die Portnummer, auf welcher der Server getestet werden soll.
      4. der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.

      Request-Grundeinstellungen in JMeter 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 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 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 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” 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” 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” 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.

      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 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.

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 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 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 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

  1. ein frei wählbarer Name
  2. der Server Name / die IP des zu testenden Servers. Alle http-Requests werden an denselben Webserver gesendet.
  3. die Portnummer, auf welcher der Server getestet werden soll.
  4. der Default-Pfad, beispielsweise das Verzeichnis des Cocoon-Servers.

Request-Grundeinstellungen in JMeter 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 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 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 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” 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” 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” 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.

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 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.

top