Ausarbeitung Performance Testing

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Performance Testing im Rahmen des Seminars Software Engineering Hanns-Alexander Dietrich Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Prof. Dr. Herbert Kuchen Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung Grundlagen Definitionen Software Performance Engineering Leistungsdatenerhebung Vorgehensmodell Performance Testing-Programme IBM Rational Performance Tester Software-Architektur Eclipse Test & Performance Tools Platform Performance Testing von Webanwendungen Ressourcen-Monitoring Bewertung Fazit und Ausblick Literaturverzeichnis II

3 Kapitel 1: Einleitung 1 Einleitung "Nach massiven Verkäufen ist in Tokio der Aktienhandel vorzeitig beendet worden - zum ersten Mal in der 56-jährigen Geschichte der Börse.... Die Zahl der Transaktionen hatte die Marke von vier Millionen erreicht und war damit an die Grenze der Kapazität des Computersystems der Börse gestoßen."[sc07, S. 179; Ze06] Kritische Software-Anwendungen müssen im Normalbetrieb sowie unter Ausnahmesituationen ein normales Laufzeitverhalten aufweisen und zuverlässig weiterarbeiten. Performance Testing kann zur Vermeidung von Situationen wie an der Börse von Tokio dienen. Die Performance wird nicht nur von der Software selbst beeinflusst, sondern auch von allen darunterliegenden Ebenen wie dem Betriebssystem, der Middleware, der Hardware und der Kommunikationsnetzwerke. Nach einer Studie aus dem Jahr 2006 hatte die Hälfte der befragten IT-Führungskräfte Performance- Probleme mit mindestens 20% der neu eingesetzten Anwendungen [MGD07]. Dabei ist das Performance Testing kein neuer Ansatz wie der Gartner Hype Cycle aus 2007 in Abbildung 1 zeigt. Die Gartner Analysten hatten Performance Testing in die Phase Pfad der Erleuchtung (Slope of Enlightment) eingeteilt und meinten damals, dass es in weniger als zwei Jahren allgemein anerkannt und akzeptiert sein wird.[dsit07;sc07] Im zweiten Kapitel werden die grundlegenden Definitionen des Performance Testings dargelegt und anschließend wird eine Einordnung des Performance Testings in eine Phase des Software Performance Engineerings vorgenommen. Des Weiteren werden die grundlegenden Begriffe Profiling und Monitoring voneinander abgegrenzt und die verwendeten Mechanismen zur Erhebung von Leistungsdaten (Performancedaten) erläutert. Im Anschluss wird ein allgemeines Vorgehensmodell von den Autoren Gao, Tsao und Wu zum Performance Testing dargestellt und eine Kategorisierung von aktuellen Performance Testing-Programmen vorgenommen. Das dritte Kapitel dient der Vorstellung des Performance Testing Programms IBM Rational Performance Tester. Hierzu wird zuerst die Software-Architektur des Programms dargestellt und danach die Eclipse Test & Performance Tools Plattform erläutert, auf der das Programm aufbaut. Darauf folgt eine Erklärung der einzelnen 1

4 Kapitel 2: Grundlagen Schritte um Performance Tests von Webanwendungen im Performance Tester durchzuführen. Des Weiteren werden die verschiedenen Technologien zum Ressourcen Monitoring im Programm vorgestellt. Abschließend findet eine Bewertung des IBM Rational Performance Testers statt. Kapitel vier gibt ein Fazit und einen Ausblick. visibility Model-Driven Architectures Globally Sourced Testing SOA Governance Technologies Application Testing Services RIA Platforms Metadata Repositories Event-Driven Architecture Application Quality Dashboards Enterprise Information Management Collaborative Tools for the Software Development Life Cycle SOA Testing SDLC Security Methodologies Information-Centric Infrastructure Scriptless Testing Technology Trigger Agile Development Methodology Unit Testing Metadata Ontology Management Data Service Architectures Peak of Inflated Expectations Years to mainstream adoption: Architected, Model-Driven SODA Enterprise Architecture Tools Application Security Testing Project and Portfolio Management Business Application Package Testing ARAD SODA Trough of Disillusionment time Java Platform, Enterprise Edition Open-Source Development Tools Slope of Enlightenment less than 2 years 2 to 5 years 5 to 10 years more than 10 years SOA Automated Testing Business Process Analysis Performance Testing Linux as a Mission-Critical DBMS Platform OOA&D Methodologies Microsoft.NET Application Platform Enterprise Portals Enterprise Software Change and Configuration Management As of June 2007 Plateau of Productivity obsolete before plateau Abbildung 1: Gartner Hype Cycle for Application Development 2007 [DSIT07] 2 Grundlagen 2.1 Definitionen IBM definiert im Rational Unified Process Performance Testing als eine Klasse von Tests, die implementiert und ausgeführt werden, um vom getesteten System die leistungsrelevanten Eigenschaften wie z. B. Laufzeitprofile, Ausführungsablaufprofile, Antwortzeiten und operative Zuverlässigkeit bzw. Grenzen zu beurteilen. Die IEEE beschreibt Performance Testing etwas allgemeiner als einen Test, der ausgeführt wird, um die Einhaltung von spezifizierten Leistungsanforderungen eines Systems oder einer Komponente zu beurteilen. Ein Performance Test wird im Deutschen als Leistungstest bezeichnet.[br04; Ba98, S. 539 f] 2

5 Kapitel 2: Grundlagen Ein Test wird definiert als Aktivität, die ein Objekt unter Anwendung einer geeigneten Methode statisch überprüft oder dynamisch ausführt, um Fehler aufzuspüren und die funktionalen und nicht-funktionalen Anforderungen des Objekts zu überprüfen. Bei dem Testobjekt handelt es sich um eine Klasse, eine Komponente, ein System oder ein Dokument, das geprüft wird. Testmethoden werden in dynamische und statische Kategorien eingeteilt. Das Performance Testing gehört der Kategorie der dynamischen Testmethoden an, bei der das Testobjekt im Gegensatz zu statischen Testmethoden während der Ausführung getestet wird. Funktionale Anforderungen definieren die Verarbeitung der Daten und deren Ein- und Ausgabe. Beim Performance Testing wird davon ausgegangen, dass die funktionalen Anforderungen des Testobjektes bereits erfüllt sind und daraufhin die nicht-funktionalen Anforderungen getestet werden können. Die nicht-funktionalen Anforderungen spezifizieren das allgemeine Verhalten des Testobjektes. Dazu gehören die eingangs erwähnten Leistungsanforderungen und beispielsweise die Benutzerfreundlichkeit. Nicht-funktionale Anforderungen setzen sich aus einem Qualitätsmerkmal und einem Qualitätsmaß zusammen. Ein Beispiel für das Qualitätsmerkmal Performance ist, dass der Seitenaufruf einer Webseite von einem ISDN-Anschluss mit 64 kbit/s innerhalb von 3 Sekunden abgeschlossen sein muss. Das Qualitätsmaß ist in diesem Beispiel also die Zeit. Wenn diese Anforderung in einem Test implementiert wurde, tritt ein Fehler auf, wenn die Forderung nicht erfüllt wurde. Um Aussagen über die Anforderungen zu machen, müssen die Ressourcen überwacht werden. Eine Ressource ist ein Systemelement, das Dienste anbietet, die von anderen Systemelementen benötigt werden. Beispielsweise ist die CPU eine Hardware- Ressource, die ihre Rechenzeit anbietet.[fr07; MGD07] 2.2 Software Performance Engineering Wie die in Kapitel 1 erwähnte Studie zeigt, treten immer wieder Probleme mit der Performance in Anwendungen auf, obwohl Methoden des Software Engineerings eingesetzt werden. Die Gründe, die dafür angeführt werden, sind der Mangel an wissenschaftlichen Richtlinien und Modellen, fehlende Ausbildung über Performance und IT-Personalknappheit. Des Weiteren führt die falsche Annahme, dass die Anwendung für Einzelbenutzer und kleine Datenbanken gedacht ist, beispielsweise dazu, dass die Antwortzeiten der Anwendung mit steigender Benutzerlast schlecht skalieren [Me02]. Weitere Ursachen für Performance-Probleme sind, dass die 3

6 Kapitel 2: Grundlagen Performanceanforderungen vom Auftraggeber nicht genau spezifiziert wurden und es keine klar festgelegten Verantwortlichkeiten und Rollen gibt [Sc07]. Software Performance Engineering (SPE) legt daher während des gesamten Softwareentwicklungszyklus' besonderen Wert auf die Performance. SPE repräsentiert die Gesamtheit von Software Engineering-Aktivitäten und verwandten Analysen, die während des Softwareentwicklungszyklus' darauf abzielen, die Performanceanforderungen zu erfüllen [MGD07]. Performance wird dabei als Qualitätsmerkmal angesehen. Nach der ISO 9126-Norm ist "Software-Qualität die Gesamtheit von Eigenschaften und Merkmalen eines Software-Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht."[fr07] Die aus der ISO 9126 Norm hervorgegangene DIN definiert für die Software-Entwicklung die sechs Hauptqualitätsmerkmale Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit. Durch eine Performanceoptimierung werden die Hauptqualitätsmerkmale Effizienz und Benutzbarkeit positiv beeinflusst, dagegen können durch die Optimierung die Qualitätsmerkmale Änderbarkeit und Übertragbarkeit negativ verändert werden. Daher ist eine Priorisierung der einzelnen Qualitätsmerkmale durch den Auftraggeber notwendig.[fr07] Beim SPE existieren zwei Ansätze: der weit verbreitete messungsbasierte Ansatz und der modellbasierte Ansatz. Beim messungsbasierten Ansatz werden Tests und Diagnosen angewendet, wenn das entwickelte System ausgeführt werden kann. Dies bedeutet, dass erst eine ausführbare Version des Systems existieren muss. Zu diesen Tests und Diagnosen gehört auch das Performance Testing. Im modellbasierten Ansatz hingegen werden in einem frühen Entwicklungszyklus Performance-Modelle erstellt und die quantitativen Ergebnisse dieser Modelle benutzt, um die Architektur und das Design an die Leistungsanforderungen anzupassen.[mgd07] 2.3 Leistungsdatenerhebung Der messungsbasierte Ansatz beim SPE erfordert eine Erhebung von Leistungsdaten. Dies geschieht über Profiling oder Monitoring. Die bedeutungsverschiedenen Begriffe Profiling und Monitoring werden oft als Synonyme benutzt und werden deshalb im Folgenden voneinander abgegrenzt. Beim Profiling wird ein Testobjekt während der Entwicklung untersucht, um Fehler im Laufzeitverhalten, der Nebenläufigkeit, dem 4

7 Kapitel 2: Grundlagen Speicherverhalten und falls vorhanden in der Garbage Collection einer Anwendung zu analysieren. Dazu werden viele Daten erhoben, die einen enormen Overhead erzeugen und damit das Testobjekt ausbremsen. Deshalb findet ein Profiling nur während der Entwicklung statt. Das Monitoring eines Testobjektes findet hingegen in einer Produktivumgebung statt um Fehler festzustellen. Dabei werden nur vorher definierte und notwendige Daten erhoben wie z. B. die CPU-Auslastung oder die Transaktionen pro Sekunde.[Sc07] Die sowohl beim Profiling als auch beim Monitoring notwendige Datenerhebung kann auf verschiedenen Ebenen eines Systems stattfinden, wie z. B. auf der Ebene der Hardware, des Betriebssystems, der virtuellen Maschine, des Anwendungsservers oder der Anwendung selbst. Für die Datenerhebung bei Software-Systemen ohne manuelle Quellcodeanpassung gibt es zwei Ansätze: Instrumentierung und Statistical Sampling. Bei der Instrumentierung wird neuer Code, die sogenannte Probe, in das Programm eingebracht, der das Programm unterbricht und die Payload ausführt. Die Payload führt die tatsächliche Aktivität, wie z. B. die Erhebung der Leistungsdaten, durch. Die Programm-Repräsentation ist dabei unerheblich. Das bedeutet, dass durch Instrumentierung neuer Code in den Source Code, Object Code, Byte Code oder in den ausführbaren Code eingebracht werden kann. Das Einschleusen des neuen Codes kann vor oder während der Ausführung des Programms geschehen. Des Weiteren können die notwendigen Stellen für die Einbringung des Codes sowohl manuell als auch automatisch ermittelt werden.[krs05; Wh00] Beim Statistical Sampling hingegen werden Momentaufnahmen einer Anwendung gespeichert und aus der Vielzahl an Momentaufnahmen ergibt sich ein hinreichend genaues Bild der Performance. Die einfachste Art des Samplings benötigt keine Softwareanpassung und liest einfach bestimmte Prozessorregister aus. Hinzu kommt, dass die Software dabei nicht aktiv angehalten werden muss, was aber bei komplexeren Datenerhebungen notwendig wird. Die Momentaufnahme der Anwendung kann entweder periodisch oder zufällig geschehen. Der Vorteil von Sampling ist, dass es sehr schnell ist. Von Nachteil ist, dass Vorgänge nicht aufgezeichnet werden, wenn sie nicht von einer Momentaufnahme erfasst wurden.[ert05; NB08; Wh00] Des Weiteren wird die Application Response Measurement (ARM) API für die Messung der Verfügbarkeit und Performance einer lokalen oder verteilten Anwendung verwendet. Der ARM-Standard sowie die API wurden von der The Open Group 5

8 Kapitel 2: Grundlagen entwickelt. Mit Hilfe dieser API werden Transaktionen, die aus beliebigen Arbeitseinheiten bestehen, im Source Code definiert oder über Instrumentierung automatisch eingefügt. Dadurch ist es mit Hilfe der API möglich, die Laufzeit und die Verfügbarkeit der Transaktionen zu messen.[arm04] Die Leistungsdatenerhebung beim Performance Testing findet über Monitoring statt, da sonst die Leistung zu stark negativ beeinflusst würde. Dabei wird sowohl Instrumentierung als auch Statistical Sampling verwendet, da diese Methoden keine Anpassung der Software erfordern. Des Weiteren wird die ARM API sowohl manuell als auch in Verbindung mit Instrumentierung zur Datenerhebung eingesetzt. Dies wird in Kapitel 3.4 näher erläutert.[cddj08] 2.4 Vorgehensmodell Zum Performance Testing gibt es eine Vielzahl von Vorgehensmodellen, die z. B. in [DSP08; Sc07, S ] beschrieben werden. Im Folgenden wird das allgemeine Modell von Gao, Tsao und Wu vorgestellt, das aus fünf Schritten besteht: 1. Verstehen und Erweitern der Performanceanforderungen 2. Performance Test-Planung 3. Performance Test-Entwicklung 4. Performance Test-Ausführung 5. Performance Test-Analyse und -Bericht Im ersten Schritt werden die nicht-funktionalen Leistungsanforderungen analysiert und ggf. erweitert. Häufig sind die Leistungsanforderungen nicht klar definiert und müssen deshalb überarbeitet werden. Die Anforderungen sollten sich dabei an den SMART- Kriterien orientieren. Diese verlangen, dass die Anforderungen spezifisch, messbar, erreichbar (attainable), realisierbar und nachvollziehbar (traceable) sind. Spezifisch drückt dabei aus, dass sie eindeutig und widerspruchsfrei sind. Die Messbarkeit bezieht sich auf die Existenz eines angemessenen Messverfahrens sowie quantifizierbare Größen. Die Anforderung ist erreichbar, wenn sie in der Theorie erfüllt werden kann. Realisierbarkeit bedeutet, dass die Anforderungen auch in der Praxis gefordert werden können und nicht unmöglich umzusetzen sind. Des Weiteren ist eine Anforderung nachvollziehbar, wenn sie auch durch ein Testverfahren überprüft werden kann. Wenn die einzelnen Leistungsanforderungen sich gegenseitig beeinflussen, ist eine Priorisierung notwendig.[sc07] 6

9 Kapitel 2: Grundlagen Der zweite Schritt beginnt mit der Ermittlung der Hauptbereiche für das Performance Testing und der Priorisierung der Bereiche. Darauf folgt eine Auswahl bzw. Definition der Performance-Maße und Messverfahren. Abhängig von den Verfahren und der Software-Architektur findet eine Auswahl eines Performance Testing-Programms statt. Dies schließt auch die Eigenentwicklung mit ein. Des Weiteren werden die verschiedenen Arbeitsbelastungen, wie beispielsweise die simultane Benutzeranzahl und deren Anzahl an Transaktionen in einer bestimmten Zeit, in Lastprofilen definiert. Als letztes wird ein Performance-Testplan erstellt, der die vorangegangen Aktivitäten zusammenfasst und eine Terminplanung mit Aufgaben und Verantwortlichen beinhaltet. Im darauffolgenden Schritt werden die einzelnen nicht-funktionalen Anforderungen aus dem Testplan in Performance-Tests implementiert und selbst getestet. Der vierte Schritt ist die Ausführung dieser Performance-Tests und die Sammlung der notwendigen Leistungsdaten. Der fünfte und letzte Schritt besteht aus der Analyse der gesammelten Daten und dem daraus resultierenden Performancetestbericht. Aus diesem werden die weiteren notwendigen Schritte zur Performanceoptimierung abgeleitet, wenn die Leistungsanforderungen nicht erfüllt wurden.[gtw03] Die Ausführung des Performance Testings am Ende eines Softwareentwicklungsprozesses, wie es im V-Modell beschrieben ist, wird in [GAW04; St06; MGD07; Ba06] abgelehnt. Die Gründe, die dafür angeführt werden, sind, dass das Auffinden und die Korrektur der Probleme am Ende des Entwicklungsprozesses mehr Zeit in Anspruch nehmen als während der Entwicklung. Dadurch werden die Fehler nicht mehr rechtzeitig behoben oder die Entwicklungszeit verlängert sich. Die einheitliche Forderung der Autoren ist daher, mit dem Performance Testing so früh wie möglich zu beginnen. Bei agilen Softwareentwicklungsprozessen, die versuchen, möglichst früh zu ausführbarer Software zu gelangen, besteht jedoch das Problem der genauen Terminierung des Performance Testings. Das Durchlaufen des gesamten Vorgehensmodells bei jeder ausführbaren Version erscheint aus Zeit- und Kostenaspekten nicht sinnvoll. Zudem ist der Performancetestbericht nur für die getestete Version gültig und somit nicht unmittelbar auf spätere Versionen übertragbar. Für den Ansatz des wiederholenden Performance Testings spricht, dass nichtfunktionale Anforderungen, wie z. B. die Antwortzeit von einer bestimmten Funktion, gleich nach der Implementierung getestet werden können. Des Weiteren werden 7

10 Kapitel 2: Grundlagen während der Entwicklung bestimmte Komponenten, wie z. B. ein XML-Parser eines Drittanbieters, getestet und dadurch wird ein späteres und teureres Austauschen der Komponenten verhindert. Deshalb muss die genaue Terminierung des Performance Testings für jedes Projekt so vorgenommen werden, dass sie aus Zeit- und Kostenaspekten vertretbar ist.[gaw04; St06; MGD07] 2.5 Performance Testing-Programme Um das Performance Testing an einer Software durchführen zu können, werden verschiedene Hilfsprogramme benötigt. Diese werden in sechs Kategorien unterteilt: Performance Daten-Generatoren dienen dem Erzeugen von Testdaten. Die Testdaten sind Eingabedaten, Events, Signale oder Nachrichten, die benötigt werden, um den Test auszuführen. Um diese Testdaten zu erzeugen, gibt es zwei gebräuchliche Methoden. Entweder werden Zufallsdaten generiert oder aus vordefinierten Mustern Testdaten erzeugt. Die Daten unterscheiden sich von den Daten für funktionale Tests dadurch, dass sie weniger Extremfälle beinhalten und aus einer großen Menge an variierenden Eingaben bestehen. Komponenten- und System-Simulatoren werden benötigt, wenn Komponenten oder Systeme während des Tests nicht zur Verfügung stehen. Bei einer Webanwendung ist das z. B. der Fall, wenn in einem Java Applet eine Sitzplatznummer fürs Theater ausgewählt werden muss. Beim Performance Testing der Anwendung wird das Java Applet auf Grund der fehlenden Ablaufumgebung oder der fehlenden Benutzereingaben nicht ausgeführt und muss somit simuliert werden. Performance Monitoring-Programme werden benötigt, um die Leistung der Systeme zu protokollieren. Dies geschieht z. B. über die in Kapitel 2.3 vorgestellten Methoden. Performance Daten-Kollektoren sammeln die zur Analyse und Kennzahlenbildung benötigten Daten. Ein typisches Beispiel dafür sind Logdateien und Monitoring- Aufzeichnungen. Bei großen Anwendungen mit vielen getrennten Systemen ist eine effiziente Sammlung der Daten notwendig, die dadurch erreicht wird, dass die Kollektoren die Daten in einem zentralen System zusammenführen. Einige Systeme bieten die Möglichkeit, die Zusammenführung schon während des Tests vorzunehmen. Performance Analyse-Programme erstellen die Kennzahlen aus den gesammelten Leistungsdaten. Performance Berichterstellungsprogramme generieren Berichte aus den analysierten Leistungsdaten und sind für die grafische Aufbereitung zuständig. [GTW03] 8

11 Kapitel 2: Grundlagen In diese Kategorien werden zur besseren Übersicht die kommerziellen Softwareprodukte, die in verschiedenen Gartner-Studien untersucht wurden, anhand ihrer Dokumentationen eingeordnet [DSIT07; Mu08]: Kategorie Performance Komponenten Performance Performance Performance Performance Daten- und System- Monitoring- Daten- Analyse- Bericht- Generatoren Simulatoren Programme Kollektoren Programme erstattungs- Software programme IBM Rational Performance Tester X X X X X X IBM Tivoli Composite Application Manager X HP LoadRunner X Keine Angaben X X X X AutomatedQA Test Complete X X X X X X AutomatedQA AQtime X Borland SilkPerformer X X X X X X Compuware QACenter Performance Edition X Keine Angaben X X X X Oracle Load Testing for Web Applications (früher Empirix) X Keine Angaben X X X X Original Software TestLoad X Keine Angaben X X X X Tabelle 1: Einteilung der kommerziellen Performance Testing-Programme Die untersuchten Performance Testing-Programme bieten Hilfsprogramme oder beinhalten Funktionen um alle vorgestellten Kategorien abzudecken. Zusätzlich bieten einige Anbieter eigenständige Performance Monitoring-Programme an, die eine genauere und einfachere Erfassung der Leistungsdaten erlauben. Eine Bewertung für Performance Testing-Programme ist in der einschlägigen Literatur nicht erhältlich, jedoch findet sich bei IBM eine Gartner Studie zu Application Quality Management Solutions. Diese betrachtet auch Performance Testing-Programme. Wie die Ergebnisse der Gartner-Studie in Abbildung 2 zeigen, sind die führenden kommerziellen Hersteller HP und IBM. Das Performance Testing-Programm von IBM, 9

12 Kapitel 3: IBM Rational Performance Tester Rational Performance Tester, das in die Ergebnisse der Studie mit eingeflossen ist, wird im nächsten Kapitel vorgestellt. Abbildung 2: In Anlehnung an MarketScope für Application Quality Management Solutions [Mu08] 3 IBM Rational Performance Tester 3.1 Software-Architektur Die Software IBM Rational Performance Tester (PT) Version 7 ist in Java geschrieben und baut auf der Eclipse Plattform auf. Deshalb ist das Produkt plattformunabhängig und kann durch Produkte, die ebenfalls auf der Eclipse Plattform aufbauen, erweitert werden. Außerdem baut PT auf dem Eclipse Test & Performance Tools Platform (TPTP) Projekt auf (vgl. Abbildung 3). IBM Rational Performance Tester TPTP Eclipse Java Abbildung 3: IBM Rational Performance Tester Software-Architektur Die primären Einsatzgebiete des PT sind das Performance Testing von Webanwendungen, Webservices, SAP, Siebel, Citrix, dem Session Initiation Protocol 10

13 Kapitel 3: IBM Rational Performance Tester (SIP) und der Socket API von Java. Für die Generierung der Arbeitslast wird das Programm Rational Performance Tester Agent Controller eingesetzt. Dieses stellt eine Ausführungsumgebung für die Tests zur Verfügung und sammelt gleichzeitig die Leistungsdaten, wie z. B. Antwortzeiten von Webseiten. Um auf den Systemen, die getestet werden, weitere anwendungsspezifische Leistungsdaten zu erheben, wird die Data Collection Infrastructure (DCI) eingesetzt. Diese übermittelt die über ARM erhobenen Leistungsdaten an den PT. Eine nähere Erläuterung des Vorgangs findet sich in Kapitel 3.4. Zur Verdeutlichung ist in Abbildung 4 die Architektur eines Performance-Tests einer Webanwendung mit den zuvor vorgestellten Technologien dargestellt. Die Generierung der Arbeitslast findet auf den Lasttreibersystemen statt, auf denen der PT Agent Controller die Ausführungsumgebung dafür bereitstellt. Dieser Agent Controller übermittelt z. B. die gesammelten Antwortzeiten zurück an den PT. Gleichzeitig werden Leistungsdaten, wie beispielsweise Funktionslaufzeiten, auf den Servern über die DCI erhoben und an den PT gesendet. DCI Lasttreiber mit dem PT Agent Controller Anwendungsserver Server DCI DCI Datenbank Server IBM Rational Performance Tester Abbildung 4: Software-Architektur beim Performance-Test einer Webanwendung 11

14 Kapitel 3: IBM Rational Performance Tester 3.2 Eclipse Test & Performance Tools Platform Das Eclipse Test & Performance Tools Platform (TPTP) Projekt baut auf Eclipse auf und bietet verschiedene Grundfunktionen, die ein Performance Testing Programm benötigt. Das TPTP Projekt ist selbst wieder in vier Unterprojekte gegliedert, wie es in Abbildung 5 dargestellt ist. Nur die Reports werden über ein selbstständiges Projekt erzeugt und sind somit nicht Teil des TPTP Projekts. Abbildung 5: In Anlehnung an TPTP Projekt Architektur [Ec08] Das TPTP Platform Project bietet das Kern-Framework, auf dem die Entwicklung der Monitoring-, Test- und Profiling-Programme aufbaut. Dazu stellt es sowohl allgemeine GUIs, Datenmodelle und Datenkollektoren als auch Remote Execution Environments zur Verfügung. Für das Monitoring der Anwendungen ist das TPTP Monitoring Tools Project zuständig. Es bietet Funktionen für das Messen, Sammeln und Analysieren des Ressourcenverbrauchs der Systeme oder Anwendungen. Um Application Server oder die Systemleistung, wie z. B. die CPU-Auslastung, zu überwachen, werden 12

15 Kapitel 3: IBM Rational Performance Tester exemplarische Programme angeboten. Des Weiteren unterstützt das Projekt die Sammlung von Log-Dateien, und das Analyseprogramm kann in Log-Dateien aus verschiedenen Systemen Korrelationen aufspüren. Das TPTP Testing Tools Project beinhaltet Testeditoren und unterstützt das Deployment und die Ausführung von Tests sowie eine Ausführungsumgebung für Tests. Für JUnit basierte Komponenten-Tests, Performance Testing von Webanwendungen und manuelle Tests werden exemplarische Tools angeboten. Für die Tracing und Profiling Phase bietet das TPTP Tracing and Profiling Tools Project einen Agenten an. Dieser Agent benutzt das Java Virtual Machine Profiler Interface (JVMPI), um für lokale und verteilte Anwendungen die Profiling Daten zu sammeln.[ec08] 3.3 Performance Testing von Webanwendungen Dieses Kapitel stellt die notwendigen Schritte für das Performance Testing einer Webanwendung in PT 7 vor. Anlegen eines Leistungstestprojekts Die notwendigen Tests, Eingabedaten und Zeitpläne für das Performance Testing werden in einem Leistungstestprojekt organisiert. Ein Test stellt dabei einen oder mehrere aufeinander folgende Aufrufe von Webseiten dar. Die Tests werden über einen Zeitplan in eine beliebige Reihenfolge gebracht und ausgeführt. Zudem wird über einen Zeitplan definiert, von wie vielen emulierten Benutzern ein Test ausgeführt wird. Erstellung von Tests Tests lassen sich im PT automatisch erzeugen, indem zuerst eine Aufzeichnung eines Testvorgangs angelegt wird. Die von PT unterstützten Aufzeichnungstypen sind in Abbildung 6 aufgelistet. 13

16 Kapitel 3: IBM Rational Performance Tester Abbildung 6: Aufzeichnungsdialog Tests für Webanwendungen lassen sich über den Typ HTTP-Aufzeichnung erstellen. Hierbei startet PT einen Socks Proxy sowie einen definierbaren Browser, dessen Anfragen automatisch über den bereitgestellten Proxy umgeleitet werden. Dies ist in Abbildung 7 dargestellt. Die atomaren Performance-Tests, die im Rahmen der PT- Entwicklung definiert wurden, werden über den Browser durchgespielt und einzeln erstellt. Des Weiteren ist es möglich, über einen Zeitplan die atomaren Performance- Tests zu einem größeren Performance-Test zusammenzufassen. Normale Sitzung: Web Browser Webserver Umgeleitete Sitzung: Protokolldatei Web Browser Socks Proxy Webserver Abbildung 7: Umleitung der Websitzung Beim Erstellen des Tests findet eine automatische Zuordnung der Anforderungs- und Antwortdaten des HTTP-Mitschnitts statt. Dadurch werden die übergebenen Argumente 14

17 Kapitel 3: IBM Rational Performance Tester einer Webseite in Beziehung zu den vorherigen Webseiten gesetzt. Wird z. B. bei einer Bestellung in einer Webanwendung eine Bestätigungsseite mit Bestellnummer generiert und die Bestellnummer geht in die Anfrage der nächsten Webseite mit ein, erkennt PT diesen Zusammenhang. Die Bestellnummer wird also dynamisch für jeden Testdurchlauf aus den Antwortdaten ermittelt und in die Anfrage der nächsten Webseite gesetzt. Diese automatische Datenkorrelation ist eine enorme Arbeitserleichterung. Test bearbeiten und überprüfen Über den HTTP-Leistungseditor lassen sich erstellte Tests bearbeiten und überprüfen. Der Editor ist in zwei Bereiche eingeteilt: Der linke Bereich mit dem Namen Testinhalte beinhaltet den Test, die Testvariablen und eine Hierarchie der Webseiten. Auf der rechten Seite, Testelementdetails, werden weitere Details dieser Elemente angezeigt. Für den Test können in dem Bereich Testelementdetails Datenpools angegeben, digitale Zertifikate verwaltet und globale HTTP-Optionen festgelegt werden. Die Datenpools bestehen aus verschiedenen Eingabedaten und dienen der Variation dieser bei der Testausführung. Die Variation wird benötigt, um z. B. Caching- Mechanismen auszuschalten, die sonst die Ergebnisse des Tests verfälschen würden. Zur Unterstützung von clientseitiger Authentifizierung von Benutzern können die benötigten digitalen Zertifikate hinterlegt werden. Unter den HTTP-Optionen werden das Zeitlimit und die Aktion bei einer Zeitlimitüberschreitung definiert. Des Weiteren gibt es eine Option, um den Cookie-Cache beim Start des Tests zu löschen. Dadurch verhält sich der Test bei jedem Durchlauf wie ein neuer Benutzer. Über einen Schieberegler kann die Wiedergabegeschwindigkeit des Tests von keiner Verzögerung bis hin zur doppelten aufgezeichneten Geschwindigkeit angepasst werden. Die Testvariablen sind keine frei definierbaren Variablen, sondern dienen zum Speichern des Hostnamens und der Port-Nummer. Sie ermöglichen das schnelle Anpassen eines Tests auf einen anderen Hostnamen und Port und werden bei einer Testaufzeichnung automatisch erstellt. 15

18 Kapitel 3: IBM Rational Performance Tester Abbildung 8: HTTP-Leistungstesteditor Die einzelnen Webseiten beinhalten die HTTP-Anforderungen, wie z. B. die von Bildern oder CSS-Dateien. Die fett formatierte HTTP-Anforderung ist die Primäranforderung, von der sich der Seitentitel ableitet. Die gelbe Hinterlegung gibt an, wenn Anforderungen Testvariablen, Datenpools oder korrelierte Daten nutzen. Da die Testvariablen bei einer Testaufzeichnung automatisch erzeugt werden, sind alle Anforderungen hinterlegt. Diese Hinterlegung hat erst Sinn, wenn neue Anforderungen hinzugefügt werden. Da in einer neuen Anforderung keine Ersetzung des Hosts stattfindet, ist diese nicht gelb hinterlegt und sticht hervor. Leistungszeitplan erstellen Mit Hilfe von Leistungszeitplänen werden die einzelnen Tests ausgeführt und dadurch Benutzer emuliert. Der Leitungszeitplan-Editor stellt im linken Zeitplaninhalte - Bereich eine Hierarchie dar, deren Wurzel der Leistungszeitplan ist. Auf der zweiten Ebene befinden sich die Benutzergruppen und die nächsten Ebenen bestehen aus Tests und Steuerungskommandos. Die Benutzergruppen dienen der Einteilung der emulierten Benutzer sowie zur Gruppierung und parallelen Ausführung der Tests. Die Einteilung findet entweder prozentual oder absolut statt. Die Benutzeranzahl kann im Zeitablauf variiert werden, um die Benutzerlast des Produktivsystems besser nachzubilden. Um die Tests nicht einfach nur nacheinander ausführen zu können, gibt es Steuerkommandos wie Schleife, Zufallsselektor, Verzögerung und Synchronisationspunkt. Durch 16

19 Kapitel 3: IBM Rational Performance Tester einen Synchronisationspunkt werden die Aktivitäten der emulierten Benutzer angehalten und durch das Erreichen des letzten emulierten Benutzers wieder fortgesetzt. Abbildung 9: Leistungszeitplan-Editor Zeitplan ausführen Durch die Ausführung eines Leistungszeitplans werden dieser und alle abhängigen Tests in Java-Quellcode übersetzt und anschließend kompiliert. Bei einer Ausführung des Zeitplans auf mehreren Systemen wird der kompilierte Zeitplan an alle Systeme übermittelt und eine Synchronisierung der Systeme findet statt. Erst danach wird der Zeitplan ausgeführt und die Antwortzeiten protokolliert. Daher wird auch der Einsatz vom Network Time Protocol (NTP) auf allen am Test beteiligten Systemen empfohlen, um die Uhrzeiten zu synchronisieren und damit eine möglichst genaue Zeitmessung und Zeitübereinstimmung für den Test zu erreichen. Ergebnisse auswerten Die Ergebnisse eines HTTP-Leistungstests werden standardmäßig in einem HTTP- Leistungstestbericht zusammengestellt. Der Bericht wird während der Testausführung zeitnah aktualisiert, um dem Tester sofort eine Rückmeldung über die Testergebnisse zu geben. Dadurch wird vermieden, dass Fehler in einem Testdurchlauf unentdeckt bleiben und erst bei der Auswertung - nach dem Test, der mehrere Stunden dauern kann - 17

20 Kapitel 3: IBM Rational Performance Tester auffallen. Der Bericht besteht aus zehn Seiten, die wiederum aus verschiedenen Tabellen und Diagrammen bestehen. Die in Abbildung 10 exemplarisch dargestellte Seite Seitenleistung zeigt die zehn langsamsten Webseiten im Balkendiagramm an. Des Weiteren werden zu diesen Seiten die statistischen Werte in Bezug auf die Reaktionszeit angezeigt. Die Reaktionszeit ist dabei die Zeit zwischen dem Senden der ersten Zeichen der Anforderung bis zum Empfang des letzten Zeichens der Antwort. Die Reaktionszeiten der Seiten lassen sich weiter in die Reaktionszeiten der Seitenelemente aufschlüsseln, um ggf. die Anforderung zu identifizieren, die die hohe Reaktionszeit verursacht. Über diese Seite wird auch die Statistik zur Aufschlüsselung der Reaktionszeiten geöffnet, die in Kapitel 3.4 näher erläutert wird. Abbildung 10: Seite Seitenleistung vom HTTP-Leistungstestbericht Eine Erläuterung einiger Diagramme des Berichts findet sich in Tabelle 2. 18

21 Kapitel 3: IBM Rational Performance Tester Name Gesamt Seitenreaktion und Zeit Seitenstatus Seitentrefferquote Benutzerlast Byte Übertragungsrate Beschreibung Ein Balkendiagramm mit den Balken Statuscodeerfolg: Seiten und Statuscodeerfolg: Seitenelemente, die den Prozentsatz der erwarteten HTTP-Statuscode-Antworten darstellen. Dies ermöglicht einen schnellen Überblick über die Testergebnisse. Zeigt die durchschnittliche Reaktionszeit für alle Webseiten im Zeitablauf an. Besteht aus drei Säulen und stellt die Anzahl der Primäranforderungen (Seitenversuch-Säule), der empfangen Antworten (Seitentreffer-Säule) und der erwarteten Statuscodes (Statuscodeerfolg-Säule) dar. Visualisiert die Seitentrefferquote im Zeitablauf. Visualisiert die aktiven und inaktiven Benutzer im Zeitablauf Stellt die gesendeten und empfangen Bytes während der Testausführung dar. Tabelle 2: Erläuterung einiger Diagramme des HTTP-Leistungstestberichts Abhängig von den im Testplan definierten nicht-funktionalen Anforderungen sind bestimmte Diagramme oder Tabellen des Standardberichts besonders wichtig. Auch ist es möglich den Bericht um bestimmte Diagramme oder Daten zu erweitern. Eine Visualisierung der Erfüllung oder Nichterfüllung der Anforderungen ist hingegen nicht durchführbar. Es können nur Diagramme und Tabellen aus den erhobenen Leistungsdaten erstellt, diese aber nicht mit eigener Logik erweitert werden. Die Analyse und Interpretation der aufbereiteten Leistungsdaten wird dem Anwender überlassen. Es besteht aber die Möglichkeit verschiedene Ergebnisse miteinander zu vergleichen.[cddj08] 3.4 Ressourcen-Monitoring Das Programm PT unterscheidet Ressourcen in Hardware- und Softwareressourcen. Eine Hardwareressource ist beispielsweise die CPU, eine Softwareressource ein Buffer oder ein Funktionsaufruf. Die Leistungsdaten der Hardwareressourcen werden über Monitoring-Programme in den jeweiligen Betriebssystemen erhoben. Unterstützt wird für Windows der Windows 19

22 Kapitel 3: IBM Rational Performance Tester Performance Monitor, für Linux rstatd und IBM Tivoli Monitoring für verschiedene Betriebssysteme. Diese Programme werden über Daten-Kollektoren in die generische Ressource Monitoring Plattform des TPTP-Projekts integriert. Dafür werden die Daten der Monitoring-Programme in ein gemeinsames Format, das auf dem Eclipse Modeling Framework (EMF) basiert, überführt. Die Integration eigener Monitoringoder auch Profiling-Programme ist möglich, indem ein passender Daten-Kollektor implementiert und eingebunden wird. Dieser stellt die Transformation der von den Programmen erhobenen Daten sicher. Die Leistungsdatenerfassung der Hardwareressourcen wird über die Option Ressourcenüberwachung aktivieren in den Zeitplanoptionen aktiviert. Anschließend wird das System, auf dem die Erfassung stattfindet, hinzugefügt und der Daten- Kollektor ausgewählt. PT bietet drei Daten-Kollektoren für die oben beschriebenen Programme an. Die Abbildung 11 zeigt die Auswahl des Daten-Kollektors und der Leistungsdaten, die in PT Ressourcendaten heißen. Beim Windows Performance Monitor stehen z. B. ungefähr 1000 Ressourcendaten zur Auswahl. Abbildung 11: Ressourcenüberwachungseditor 20