Neue Ansätze der Qualitätssicherung: Diagnose von Performance-Problemen

Transkript

1 Neue Ansätze der Qualitätssicherung: Diagnose von Performance-Problemen André Kemena Tribenstraße 10, Herford, Nordrhein-Westfalen, Deutschland Universität Paderborn, Paderborn, Nordrhein-Westfalen, Deutschland Zusammenfassung Sommersemester 2009 Performance von Software wird in DIN ISO 9126 durch das Qualitätsmerkmal Effizienz und dessen Charakteristiken Zeitverhalten und Verbrauchsverhalten repräsentiert, wird aber dennoch oft im Bereich der Qualitätssicherung nicht oder erst in späten Entwicklungsphasen berücksichtig. Analog zur Vernachlässigung anderer Qualitätsmerkmale birgt dies das Risiko erhöhter Kosten bei spätem Auffinden und Beheben von Problemen. In dieser Seminararbeit soll eine Einführung und erste Übersicht über die Thematik der Software-Performance-Tests und -Diagnose gegeben und anhand eines Beispiels der aktuelle Stand von Test-Tools mit dessen Chancen und Risiken bzgl. der Diagnose gegeben werden. Keywords: Software Performace Test, Software Performance Diagnose, Leistung, Leistungsbewertung, Leistungstest, Testtool 1 Einleitung Performance (engl. für Durchführung, Leistung) wird im Allgemeinen als Leistungsfähigkeit verstanden. In der Datenverarbeitung und Kommunikationstechnik wird Performance häufig auch etwas spezieller mit Übertragungsgeschwindigkeit, Echtzeitverhalten, Gütemerkmal, Verfügbarkeit, Durchsatz oder ähnlichen Leistungsparametern gleichgesetzt. Bezogen auf Software im Sinne von Benutzeranwendungen trifft der Ausdruck Echtzeitverhalten wohl am ehesten zu. Ein gutes Echtzeitverhalten entspricht dabei einer subjektiven Wahrnehmung des Benutzers bzgl. einer gefühlt angemessenen Bearbeitungsdauer durch die Software. Der Benutzer darf sich also in Arbeitsabläufen nicht durch übermäßig lange, wahrgenommene Unterbrechungen gestört oder aufgehalten fühlen. Das bedeutet z.b., dass Benutzer keine Wartepausen ohne eine Anzeige der aktuell durch die Software durchgeführten Operationen abwarten muss, oder auch, dass er zeitnahe (Fehler-) Rückmeldungen zu durchgeführten Aktionen erhält. Warum Performance-Tests Die Entwicklungen der letzten Jahre zeigt eindrucksvoll, dass Software in nahezu allen Bereichen, insbesondere auch Geschäftsprozessen, eine immer wichtigere und umfassendere Rolle einnimmt. So werden häufig ganze Geschäftsprozesse

2 2 bzw. Geschäftsprozessketten automatisiert und, weitestgehend automatisch, über Software abgewickelt. Als Beispiele können Onlineshops mit angebundenen Warenwirtschaftssystemen, Flugreservierungen, Online-Routenplaner, Banking-Portale, Bilderservices, Callcenter-Software und viele mehr angeführt werden. Gerade bei Online-Systemen stellt Überlastung von Diensten ein Risiko dar: so wird ein eventueller Kunde eines Online-Shops zu Alternativen und damit zu Angeboten der Konkurrenz wechseln, wenn inakzeptable Ladezeiten Kaufvorgänge behindert. Als Extrema stellen hier zeitweise Ausfälle von Diensten durch Überlastung einen sofortigen Einbruch von Geschäftsprozessen und damit Umsätzen dar. Zudem ist der PC aus heutigen Firmen-Büros kaum noch wegzudenken. Software wird dort genutzt, um Mitarbeiter durch z.b. Office-Software, Dokumentenmanagementsysteme und spezielle Softwareentwicklungen zu unterstützen, indem wiederkehrende Prozesse vereinfacht, optimiert, und Informationen bzw. Inhalte für spätere Aufgaben bereitgestelt werden. Auch hier stellen durch Überlastung verursachte Funktionseinschränkungen von Diensten geschäftsgefährdende Risiken dar. Die Qualität von eingesetzter Software ist somit oft ein kritischer Faktor für einen ordnungsgemäßen und optimalen Geschäftsbetrieb. Die Beanspruchung von Zeit- und Systemressourcen der eingesetzten Software wird jedoch oft recht stiefmütterlich im Kontext von Qualität betrachtet. Ist im Bereich eingebetteter Systeme dieser Faktor seit jeher durch z.b. feste Angaben von Zeitschranken für Komponenten ein essentieller Bestandteil von Qualitätsprüfungen, so wird er außerhalb dieses Bereichs oft vernachlässigt. Die Qualität von Software wird allgemein meist weniger an zeit- und ressourcensparender Umsetzung, sondern vielmehr an Gestaltungsrichtlinien, aufgeführt z.b. in der Norm DIN [Referenz?], festgemacht: Aufgabenangemessenheit Selbstbeschreibungsfähigkeit Steuerbarkeit Erwartungskonformität Fehlerrobustheit Es fällt auf, dass Gestaltungsrichtlinien mit direktem Bezug auf Performance nahezu fehlen. So lässt sich zwar in die Richtlinien Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit und Erwartungskonformität eine zeitnahe Umsetzung, Reaktion bzw. Rückmeldung von Software hineininterpretieren, konkrete Vorgaben sucht man jedoch vergebens. Weiter wird in der Norm DIN ISO 9126 das Qualitätsmerkmal Effizienz durch die Eigenschaften Zeitverhalten und Verbrauchsverhalten charakterisiert, direkte Vorgaben für die Praxis fehlen aber auch hier. Dies begründet sich vermutlich vor allem durch die Schwierigkeit, Performanz von Software allgemein zu definieren bzw. zu beurteilen. Sucht man heute nach allgemeinen, durch die Industrie entwickelte und anerkannten Richtlinien bzw. Performance-Standards, welche Ausgangspunkte zur Bewertung von guter bzw. schlechter Performance liefern, so ist dies vergebens: es gibt derzeit keine solchen Standards! Ausnahme stellen derzeit erste, informelle Ansätze im

3 3 Kontext von Browser-Applikationen dar, z.b. für die maximale bzw. minimale Zeit, die eine Seite zum Laden und für die Darstellung braucht. 2 Grundlagen für Messungen Um im Folgenden über Performance von Software diskutieren zu können, benötigen wir ein gewisses Vokabular, wie zum Beispiel Metriken und Kennzahlen. Es stellt sich in diesem Zusammenhang auch die Frage: Wie lässt sich Performance von Software beschreiben, messen und bewerten? 2.1 Indikatoren Um Messungen von Performance durchführen zu können, ist es zunächst wichtig festzulegen, was und wie gemessen werden soll. Weiter muss entschieden werden, welche Werte zur Messung herangezogen, und wie diese in späteren Bewertungen genutzt werden (wofür). Diese Werte werden in der Literatur, ähnlich zu den Fachbegriffen aus der Betriebswirtschaftslehre, oft als sogenannte Maßzahlen, Kennzahlen, oder auch Indikatoren, englisch Indicators oder Key Performance Indicators (KPI) bezeichnet. Bezüglich der Fokussierung der Performance- Betrachtung auf Dienstverfügbarkeit bzw. effizienter Ausführung lassen sich diese Indikatoren nach Ian Molyneaux [1] wie folgt gruppieren und charakterisieren: effizienz-orientierte Indikatoren Datendurchsatz Ressourcennutzung service-orientierte Indikatoren Verfügbarkeit Antwort- bzw. Reaktionszeit (System-bezogen) Effizienz-orientierte Indikatoren charakterisieren die Art und Weise der Nutzung und des Bedarfs von Ressourcen durch die Anwendung. Service-orientierte Indikatoren hingegen fokussieren die Problematik der effektiven Verfügbarkeit von Anwendungen oder Diensten für den Endbenutzer. Sie bewerten Performance also anhand von Maßzahlen bezüglich der Zeit, die der Benutzer warten muss und keine weiteren Aktionen in der Anwendung durchführen kann. Idealerweise sollten all diese Indikatoren zusammen genutzt werden, um Performance- Eigenschaften zu analysieren. In der Praxis wird jedoch oft gerade der Indikator Antwortzeit vernachlässig. Dies kann Ergebnisse von Performance-Test erheblich verfälschen. Um nun eine möglichst genaue Bewertung und ggf. Optimierung der Benutzer-Produktivität vornehmen zu können ist zunächst zu klären, wann systembezogenene Antwort- bzw. Reaktionszeiten als gut oder schlecht zu bewerten sind, also wie gewonnene Maßzahlen zu interpretieren sind. Hierzu lassen sich die Ergebnisse der Untersuchungen von Martin [?] anhand von textbasierten Anwendungen als Faustregeln zur Bewertung von Antwortzeiten t heranziehen:

4 4 Antwortzeit t > 15 Sekunden Nicht zumutbar bei oft wiederkehrenden, kleinen und insbesondere konversationsartigen Arbeitsvorgängen. Antwortzeit 4 < t 15 Sekunden Bei konversationsartigen Arbeitsvorgängen wird durch Beanspruchung des Kurzzeitgedächtnisses der Benutzer im Arbeitsfluss gestört, bei Anwendungen mit weniger zeitabhängigen und weniger Konzentration erfordernden Arbeitsschritten ggf. noch vertretbar. Antwortzeit 2 < t < 4 Sekunden Benutzer wird bei Arbeitsvorgängen, die hohe Konzentration erfordern, im Arbeitsfluss gestört. Abhängig von der Art des Vorgangs ggf. noch tolerierbar. Antwortzeit t < 2 Sekunden Allgemein als obere Zeitschranke zur Förderung mentaler Rückkopplung anzustreben. Keil [15] führt in seinen Ausführungen zwar hierzu keine Zeitschranken an, betont aber die Relevanz der Kopplung von Wahrnehmungs- und Handlungsraum mit Handlungsabschluß und Systemzuständen. Antwortzeit t < 1 Sekunde Anzustreben für Gedanken-intensive Arbeitsabläufe wie Text- oder Bildverarbeitung. Antwortzeit t < 1 Sekunde Besonders im Bereich Simulation und Steuerung, aber auch für essentielle Interaktionen wie Eingabe über Tastatur- und 10 Maus sind Reaktionszeiten dieser Größenordnung anzustreben. Mit Hilfe dieser Richtlinien und der Summe der oben angeführten Indikatoren ist es nun möglich, Performance-kritische Faktoren zu erkennen und für gemessene bzw. gegebene Maßzahlen Bewertungen durchzuführen. Ist Software zu testen, so ist nun das Kernproblem, festzustellen, welche Faktoren entscheidenden Einfluss auf das jeweilige Leistungsverhalten ausüben. Hierzu sind Kriterien bzw. Ziele zu benennen, die als Test- und Entscheidungsgrundlage für Code-Änderungen dienen sollen. Diese Ziele werden auch als Key Performace Targets bezeichnet. Eine Gruppierung dieser KPI kann nach Molyneaux[1] beispielsweise wie folgt vorgenommen werden: Leistung im Sinne von Schnelligkeit Verfügbarkeit (availability / uptime) Verhalten bei Nebenläufigkeit (concurrency) Anwortzeit (response time)

5 5 Leistung im Sinne von Kapazität- / Ressourcen-Nutzung Netzwerk-Nutzung Server-Nutzung Doch wie erhebt man nun in der Praxis die notwendigen Messdaten? Die Erstellung und Auswertung einzig anhand von anwendungspezifischen Log-Dateien kann ein erster Schritt zur Analyse sein. In der Praxis wird dies jedoch im Allgemeinen in Softwareentwicklungsplänen nicht oder nur am Rande berücksichtigt, und damit in Hinblick auf aussagekräftige Daten oft nicht konsequent genug betrieben. Weiter stellt die Auswertung der Log-Dateien ohne weitere Hilfsmittel einen nicht zu unterschätzenden Arbeitsaufwand dar. Es gibt jedoch eine Vielzahl an, mitunter frei verfügbaren, Testtools, die sich bzgl. der verwendeten Test-Architekturen und ihrer Zielsetzung unterscheiden 1. Da die Eigenschaften der zu testenden Software ausschlaggebend für die Wahl eines oder mehrerer Testtools sind, fällt oft bereits anhand der, in den Tools verfügbaren, Testarten die Entscheidung. Die am meisten verbeiteten Testarten werden nun kurz beschrieben. 2.2 Testarten In der Praxis haben sich, abhängig von der jeweils zu testenden Software, verschiedene Arten von Tests profiliert, von denen die bekanntesten und am häufigsten angewandten an dieser Stelle kurz beschrieben werden. Baseseline Test Der Baseline Test ist als erster Einstiegspunkt und als Grundlage für Vergleiche mit weiteren Testarten anzusehen. So wird je Durchlauf in einem gewissen Zeitrahmen mit jeweils nur einem (virtuellen) Anwender ein festgelegter Arbeitsablauf bearbeitet und gemessen. Dieser Ablauf setzt sich aus einer oder mehreren Transaktionen (engl. transactions) zusammen. Transaktionen sind in diesem Zusammenhang bei sogenannten fat clients Prozesse oder Abläufe, die eine Speicherung oder Änderung der Daten ausführen. Bei thin clients liegt der Fokus hierbei eher auf der Übertragung und Speicherung auf Server-Seite. In späteren Vergleichen mit Messdaten, beispielsweise aus Load-Tests, können dann Aussagen über das Leistungsverhalten der Software mit steigender (paralleler) Anwenderzahl und Transaktionszahl getroffen werden. Load Test Der sogenannte Load Test ist der klassische Performance-Test. Bei diesem Test wird die zu testende Software sukzessive bis zu einem festgelegten Ziel, meist eine gewisse Zahl gleichzeitiger Anwender, getestet. Der Unterschied zu Tests wie dem Soak Test ist, dass beim erreichen des vorgegebenen Ziels nicht darüber hinaus getestet wird. Dieser Test bedingt daher eine gute Schätzung der später im realen Anwendungsfall vorhandenen Anwenderzahlen. In diesem Test 1 Eine beispielhafte Liste von Testtools ist im Anhang zu finden

6 6 werden auch besonders die Antwortzeiten der Benutzer und des bzw. der Anwendungssysteme (i.e. Server) betrachtet. Die Last wird bei diesem Test entweder durch ein oder mehrere virtuelle Maschinen, Server oder Arbeitsplatzrechner erzeugt, indem z.b. Anwender mit typischen Arbeitsschritten simuliert werden. Bei der späteren Analyse ist in diesem Zusammenhang insbesondere bei höherer erzeugter Last darauf zu achten, dass Stress Test Der Unterschied des Stress Test zum Load Test ist die Zielsetzung, Software und Infrastruktur derart zu belasten, dass es zu fehlerhaftem Verhalten, Nicht-Verfügbarkeit von Diensten oder Absturz von Komponenten bzw. Diensten kommt. Dieser Test wird u.a. besonders in Zusammenhang mit Netzwerk-abhängiger Software angewand, um maximale Anwenderzahlen, maximale Netzwerklast und ähnliches zu ermitteln. Diese Art von Test zeichnet sich dadurch aus, dass durch sie sowohl die Leistung im Sinne von Geschwindigkeit gemessen als auch die Kapazitätsgrenzen der Testumgebung ermittelt werden. Gerade für Software, die in grossen Netzwerken (insbesondere dem Internet) Verwendung findet, ist dieses Wissen um Kapazitätslimits unverzichtbar, da eine realitätsnahe Einschätzung der Anwenderzahlen hier oft misslingt. Weiter können in der Startphase des Softwareeinsatzes durch Beobachtung von Nutzungszahlen und der durch Stress Tests vorliegenden Kapazitätslimits ggf. rechzeitig Vorkehrungen getroffen und Ausfallzeiten verringert bzw. vermieden werden. Soak / stability test Das Ziel von Soak Tests (soak: engl. für aufweichen) ist, Problemfälle zu erkennen, die durch Kummulation einzelner Effekte und erst nach einer gewissen Laufzeit auftreten. Mit ihrer Hilfe ist es beispielsweise möglich, Speicherlecks (engl.: memory leak) zu entdecken, also eine Reservierung von Speicher durch Prozesse, die aber weder rückgangig gemacht noch genutzt werden kann. Diese Art von Fehlern wird häufig nur durch Kummulation entdeckt, also wenn eine Summe von Prozessen eben diese fehlerhaften Software-Stati erzeugt. Symptome während bzw. am Ende der Tests sind auch hier eine Verlangsamung der Reaktionszeit bzw. ein Ausfall der Software. Bei Client-Server-Architekturen sind Diagnosen sowohl von Seiten des bzw. der Clients als auch auf Seite des oder der Server notwendig. Smoke test Smoke Tests werden typischerweise nach Code-Änderungen durchgeführt, also auch im Anschluss an vorrausgegangene Performance-Tests. Diese Art von Test bezieht sich nur auf die geänderten Fragmente bzw. Komponenten des Codes, die durch die Code-Änderungen direkt oder indirekt betroffen sind. Isolation test Isolation Tests werden zur tieferen bzw. wiederholten Analyse von Code-Fragmenten genutzt, die bekanntermaßen Performance-Probleme hervorrufen.

7 7 Aufbauend auf diese Tests kann es sinnvoll sein, in der Testphase je nach Software-Anforderungen bzw. Art die Tests einerseits mehrmals für gleichartige Testprofile (engl.: injection profiles) und Daten durchzuführen. Der Vorteil hierbei liegt ganz klar bei der direkten Vergleichbarkeit des Leistungsverhaltens nach Korrekturen. Andererseits kann es interessant sein, die Veränderungen von Testergebnissen anhand kontrolliert modifizierter Daten- bzw. Testprofile zu ermitteln. Die wichtigsten Injection profiles sind: Big Bang / Constant In diesem Test starten alle (ggf. virtuellen) Benutzer zur gleichen Zeit und arbeiten simultan, aber nicht zwingenderweise synchron, Transaktionen ab. Hierdurch wird eine realitätsnähere Situation erreicht. Ramp-up (with step)/ Ramp-down (with step) Diese Variante startet mit einem (virtuellen) Benutzer und fügt nach und nach weitere hinzu (Ramp up). Sollen Leistungsdaten für gewisse Zahlen aktiver Benutzer genauer getestet werden, so wird bei festgelegten Benutzerzahlen das Hinzufügen weiterer Nutzer pausiert(ramp up with step) und mit der jeweils aktuellen Benutzerzahl eine vorgegebene Zeit gemessen und protokolliert. Dies ist zum Beispiel sinnvoll, wenn sich später alle Mitarbeiter einer Firma zu Beginn eines Arbeitstages einloggen und eingeloggt bleiben. Anschließend wird entweder die Richtlinie Ramp-up weiter verfolgt und somit weitere Benutzer hinzugefügt, oder es wird eine Kombination aus Ramp-up(with step) und Ramp-down (with step) fortgeführt. Ramp-down verringert analog die Benutzerzahlen und simuliert Benutzer, die sich beliebig am System an und abmelden. Peaks Dieser Test ist eine leichte Abwandlung des ConstantTest, bei dem periodisch entweder mit einer maximalen virtuellen Nutzerzahl gleichzeitig oder einer vorgegebenen Minimalzahl getestet wird. Delayed start Delayed start wird mit einer der vorherigen Varianten von Injection profiles kombiniert. Der Unterschied besteht einzig in der Verzögerung des Starts von Test-Scripten oder Teilen dieser. Hierdurch wird die dynamik der Simulation weiter verbessert. 2.3 Testtool-Architekturen Automatische Testtools, sogenannte Profiler, besitzen meist eine Vielzahl Komponenten, die auf einzelne Test-Zielsetzungen zugeschnitten sind. Üblicherweise

8 8 werden Profiler genutzt, um durch Zählen bzw. Messen mit Hilfe der zuvor beschriebenen Test-Arten Zahlen bzw. Maße bezüglich der Aufrufe oder Durchläufe von Codebereichen wie Funktionen oder Klassen zu erheben. Zu den bekanntesten zählen hierbei: Scripting Modul Test Management Modul Load Injector(s) Analysis Modul Scripting Module werden typischerweise zur Erzeugung von zu simulierendem Nutzerverhalten genutzt. Dies kann einerseits durch manuelle Erzeugung des Testers oder auch unter Verwendung von Makro-ähnlichen Aufzeichnungsassistenten erfolgen 2. Mit ihrer Hilfe werden hauptsächlich verschiedenste Granularitätsstufen von Reaktions- bzw. Antwortzeittest durchgeführt. Test Management Module dienen der Erzeugung und Simulation von Load-Test-Session unter Verwendung von Scipts und/oder ein oder mehr Load Injector(s). Load Injectors erzeugen, wie der Name suggeriert, eine bestimmte Last, unter der das Verhalten der zu testenden Software dann analysiert wird. Analysis Module schliesslich bieten Möglichkeiten zur Analyse der in Test erzeugten Informationen. Diese verwenden Module generieren meist Reports, die dann zusätzlich tabellarische oder graphische Reports visualisiert werden. 3 Diagnose Mit den zuvor genannten Indikatoren, Test-Arten und Testtool-Architekturen stehen nun die wichtigsten Grundlagen und Tool-Arten zur Messung von Performance zur Verfügung. Im Folgenden wird von dem Fall ausgegangen, dass eine Software bzgl. ihrer Performance-Eigenschaften getestet werden soll. Ein Analyse-Tool wurde bereits gewählt bzw. ist fest vorgegeben (z.b. durch vorhandene Lizenzen der ausführenden Firma). Diverse Tests werden bzw. wurden durchgeführt und protokolliert bzw. werden live zur Laufzeit analysiert. Hierzu bieten eine Vielzahl der Tools Visualisierung, z.b. Tabellen oder Graphen, an. Es gilt nun, anhand der gewonnenen Daten Performance-Probleme zu identifizieren und zu lokalisieren. Die Schwierigkeit bei der Diagnose von Performanceproblemen stellt sich an dieser Stelle durch die Lokalisierung der Problemstellen(engl.: bottlenecks) im Code dar (engl.: root-cause analysis). So erleichtern die Visualisierungen der Test-Tools zwar das Auffinden eventueller Problemstellen, die Abhängigkeit der Messdaten von den Eigenschaften und der Struktur der Test-Daten (und damit der vorrausgehenden Bestimmgung der KPI) und der Test-Art sowie der durch den Tester vorgegebenen Checkpoints und damit der Betrachtungsausschnitte erschwert jedoch eine vollautomatisierte Identifizierung. 2 Beispiel: NeoLoad [2]

9 9 3.1 Interpretation von Testergebnissen Abbildung 1 zeigt in einer typischen Visualisierung die Ergebnisse eines Performancetests. Getestet wurden hier die System-Antwortzeiten bei Ausführung Abbildung 1. Molyneaux: Testvisualisierung mit Korrelation von (Checkpoint- ) Transaktionen-Anwortzeit und Anzahl gleichzeitiger Benutzer eines Load-Test mit Ramp-Up. Die x-achse bezeichnet die verstrichene Zeit in Sekunden mit Zeitpunkt 0 als Test-Start, während die y-achse in Korrelation mit der Zahl der virtuellen Benutzer (rechts) die Zeit darstellt, die das System zum Antworten benötigt. Wie erwartet erhöht sich mit steigender Benutzerzahl die Anwortzeit des Systems. Bei etwas genauerer Betrachtung fällt der Zeitpunkt nahe 1500 Sekunden auf, bei dem eine deutliche Spitze der transaction response time zu erkennen ist, die auf einen Performance-Einbruch hindeutet. Ohne weitere Informationen wäre davon auszugehen, dass das System bei einer Nutzerzahl von ca. 400 gleichzeitigen Benutzern das maximale Potential erreicht hat. Es müssten also entweder Optimierungen in der Software vorgenommen werden, z.b. durch genauer Analyse einzelner Transaktionen der Benutzer und Identifizierung kleinerer Last-Extrema, oder nach Möglichkeit Infrastruktur- bzw. Hardwareaufrüstung vorgenommen werden. Generell würde man jedoch erwarten, dass mit gleichmäßig steigender Benutzerzahl die transaction response time ebenfalls relativ gleichmäßig ansteigt. Wird zusätzlich zu den bisherigen Informationen eine Maßzahl bzgl. der Antwortzeiten einzelner, durchlaufener Checkpoints hinzugezogen (in der Graphik Checkpoint response times ), so deutet dies entgegen der vorherigen Folgerungen nicht auf eine Ursache seitens der Anzahl virtueller Nutzer, sondern vielmehr auf eine erhöhte Anzahl durchlaufener Checkpoints und damit erhöhten Aufwand durch Änderung der Art der Testdaten hin. In

10 10 diesem Fall war die Ursache laut Molyneaux eine Reihe ungültiger virtueller Benutzer-Logins in den injection profiles, die erhöhte Serverlast erzeugt haben. Dieses Beispiel verdeutlicht die Relevanz der in Tests genutzten Konfigurationen, der Qualität und Art der Test-Daten, der Plazierung von Checkpoints und im Allgemein die Problematik der Interpretation von Ergebnissen. Eine konkretere Beschreibung einer möglichen Vorgehensweise zur Identifizierung von Bottlenecks wird nun in einem analogen Testfall mit dem Test-Tool NeoLoad der Firma Neosys 3 beschrieben. Beispiel: Load-Test mit NeoLoad Getestet wird wie bei Molyneaux ein thin-clientsoftwareprodukt, in diesem Fall eine Webshop-Applikation, die auf der Client-Seite nur einen üblichen Browser vorraussetzt. Auf Server-Seite wird ein Linux-System mit einem Apache-Serverdienst in Kombination mit Tomcat und einer MySQL-Datenbank genutzt. Zu diesem Zweck werden als Profile für die virtuellen Benutzer zum einen ein Profil, dass als Transaktionen den Login- Vorgang, das Ablegen von Artikeln im Warenkorb sowie den Bestellvorgang mit anschließendem Logout beinhaltet erzeugt. Als ein weiteres Profil wird ein Standard-Besucher des Shops erstellt. Beides wird in dem integrierten Scriptingbzw. load injector Modul konfiguriert. Die Transaktionen für dieses Profil beinhalten lediglich den Besuch diverser Shop-Seiten. Diese Profile werden insofern dynamisiert, als für Erzeugung von Profil-Instanzen die Login-Profile, die zu besuchenden Seiten sowie die zu kaufenden Produkte durch Variablen ersetzt werden. Dies ist wie bereits erwähnt ein entscheidender Faktor für eine möglichst realitätsnahe Simulation. Um in der Auswertungsphase später eine einfache Möglichkeit zur Lokalisierung von Performance-kritischem Code zu ermöglichen, bietet NeoLoad hier zusätzlich die Möglichkeit, in dem Scripting Modul Code-Bereiche mit sogenannten Container zu gruppieren. Diese Container werden dann später angezeigt, wenn Seiten bzw. Code in ihnen durch Monitore beobachtete Schwellwerte überschreiten bzw. wenn in ihnen Fehler auftreten. Für diesen Test werden die Ressourcen, welche für den Login zuständig sind, bei dem Profil des sich einloggenden und kaufenden virtuellen Benutzers in einen Container Login gelegt. NeoLoad bietet wie die meisten Test-Tools die Verwendung eines Test-Managers an, der die Möglichkeit zur einfachen Erzeugung von Test-Szenarios ermöglicht. In diesem Szenario wird als Test-Art ein Load-Test mit Ramp-up definiert. Weiter können hier diverse Monitor-Komponenten aktiviert werden, beispielsweise ein Tomcat memory usage monitor. Dieser erlaubt das Überwachen des von der Java Virtual Machine maximal, durchschnittlich und aktuell genutzten Speichers. Diese Überwachung wird aktiviert, um später Aussagen über die Kapazitätsauslastung treffen und Speicherlecks ggf. lokalisieren zu können. Während der Ausführung des Load-Test ist es bereits möglich, die Entwicklung der beobachteten Daten zu verfolgen. An dieser Stelle betrachten wir jedoch das Endergebnis des kompletten Testlaufs. Schon in der ersten Test- Zusammenfassung fällt in der unteren grafischen Übersicht (s.h. Abbildung 2) 3 Tutorial-Videos zur Erstellung, Durchführung und Auswertung von Tests:[2]

11 11 Abbildung 2. NeoLoad: Test-Zusammenfassung über Response Times in Korrelation zu Benutzerzahlen im zeitlichen Verlauf auf, dass ca. 1 Stunde und 5 Minuten nach Testbeginn die Hits per second (Seitenaufrufe pro Sekunde) drastisch abfielen und zeitgleich die response time stark anstieg. In der oberen grafischen Darstellung ist kurz nach diesem Zeipunkt ein erstes Auftreten und Ansteigen von Fehlern zu erkennen. Hieraus lässt sich bereits auf ein Performance-Problem schließen. NeoLoad unterstützt den Tester an dieser Stelle durch eine Auflistung der fünf am häufigsten aufgetretenen Fehler ( Hot Spots ), average response times und top response times inklusive der verursachenden Seiten. Darüber hinaus wird eine komplette Liste der aufgetretenen Fehler zur Verfügung gestellt. In diesem Beispiel tritt ein sogenannter interner Server-Fehler (Fehlercode 500) auf, der häufig aus dem Erreichen von Speicherlimits resultiert (Hintergrundwissen Statuscodes 4 ). In NeoLoad lässt sich die Ursache von Fehlern und Problemen durch die zuvor angelegten Container (ähnlich den sonst so genannten Checkpoints) näher eingrenzen, hier also durch den Login-Container. NeoLoad zeigt für diese ebenfalls in der Zusammenfassung eine Übersicht über minimal, average und maximal response times, Fehler usw. Wir betrachten nun unter dem Tab values die Protokollierten Werte (s.h. Abbildung 3). Hier fällt wieder die in der Test- Zusammenfassung bereits erkannte Problemstelle nach Ablauf von ca. 1 Stunde und 5 Minuten auf. Ab diesem Zeitpunkt treten erste Fehler für den Container Login auf. Um der Ursache weiter auf den Grund zu gehen, wird auf die Schaltfläche Graphs gewechselt. Aktiviert man die Anzeige für die aufgetretenen Fehler, so bestätigt dies die Vermutung eines Speicherlecks. Der Java Virtual 4 HTTP-Statuscodes sind definiert durch RFC 2616[5] (sowie RFC 2518, RFC 2817, RFC 2295, RFC 2774, RFC 4918) [4]

12 12 Abbildung 3. NeoLoad: Fehler-Anzeige für Container Login Machine Garbage Collector benötigt in diesem Fall zuviel Zeit, um alte Speichereinträge durch neue, durch Anfragen benötigte Einträge zu ersetzen. (s.h. Abbildung 4).

13 13 Abbildung 4. NeoLoad: Monitor-Ergebnisse inkl. Tomcat (Java Virtual Machine-Lastanzeige) In diesem Fall wäre als Maßnahme eine Vergrößerung des auf dem Server durch Tomcat maximal reservierbaren Speichers ein sinnvoller Lösungsansatz. Dieses Beispiel zeigt wie jenes von Molyneaux, wie gravierend sich ein gutes Test-Design auf Testergebnisse auswirkt. Hier führte eine feingranulare Auswahl von Containern (Checkpoints) in Kombination mit einer realitätsnahen Simulation von Benutzern (mit und ohne Berücksichtigung von Login und verschiedenen Benutzerinteressen) zum Ziel. Weiter zeigt dieses Beispiel, wie wichtig im eigentlichen Diagnose-Schritt immernoch der Faktor Tester ist. Nur durch genaue Analyse der durch das Test-Tool gemessenen und protokillierten Daten konnte Anhand der Visualisierung ein Performance-Problem identifiziert werden.

14 14 4 Zusammenfassung Das Ziel dieser Arbeit war es, einen ersten Einblick in das Problemfeld der Diagnose von Software-Performance zu geben. Nach einer grundlegenden Einführung wurde die Sensibilität von Performance-Tests und deren Diagnosen bezüglich des Testdesigns, der Testarchitektur, der Auswahl des Testtools und insbesondere auch der Testdaten und -durchführung herausgearbeitet. Hierzu wurde beispielhaft für Server-orientierte Anwendungen praxisnah anhand des repräsentativ ausgewählten Tools NeoLoad ein Lasttest mit anschließender Diagnose der Protokolle und Meßdaten durchgeführt. Dabei wurde gezeigt, dass aktuelle Werkzeuge eine Vielzahl hilfreicher Funktionen und Möglichkeiten zur Messung von Performance, der Aufbereitung von Messdaten sowie das Auffinden von Performance- Problemen bieten. Durch unterschiedliche Definitionsmöglichkeiten von Performance und die Abhängigkeit der Performance-Tests von Durchführungszeitpunkt im Entwicklungsprozess, Eigenschaften der zu testenden Software und eingesetzten Hardware können diese Werkzeuge aber nur unterstützen. Zu groß ist noch der Faktor Mensch in Form des durchführenden Testers, der seine gesammelten Erfahrungen durch gute Testdaten-Wahl, ein gutes Testdesigns, konsequente Test-Wiederholungen und ein solides Hintergrundwissen in die Diagnose einbringen muss. Es ist jedoch zu erwarten, dass Testwerkzeuge in Zukunft weitere Fortschritte gerade in der Auswertung und Diagnose von Performance-Problemen machen werden. Aufgrund des Umfangs der Problemstellung kann diese Arbeit nur einen Einstieg in diese Thematik darstellen. Der interessierte Leser findet im Literaturverzeichnis Einstieg in weiterführende Literatur[3] und zu Werkzeugen zu diesem Thema.

15 15 Literatur 1. Ian Molyneaux, The Art of Performace Testing, O Reilly, ISBN , Januar 2009, Edition 1 2. NeoLoad Load-Testing-Tool, Tool-Demo und Advanced Demo Video, URL 3. SoftwareQATest.com, Allgemeine Tool-Übersicht URL: Web Test Tools URL: 4. Definition HTTP-Statuscodes URL Statuscode 5. Hypertext Transfer Protocol HTTP/1.1 URL 6. Andreas Spillner, Thomas Roßner, Mario Winter, Tilo Linz, Praxiswissen Softwaretest - Testmanagement, dpunkt.verlag, ISBN , Christof Ebert, Best practices in software measurement, Martin Shepperd, Foundations of software measurement, Jirk Stolze, Diplomarbeit: Performancetests und Bottleneck-Analyse in Multischichtarchitekturen, URL: Connie U. Smith, Introduction to Software Performance Engineering: Origins and Outstanding Problems, 7th International School on Formal Methods for the Design of Computer, Communication and Software Systems, SFM 2007, Bertinoro, Italy, May 28-June 2, 2007,LNCS Marcel Alper, Professionelle Softwaretests, Boris Beizer, Software system testing and quality assurance 13. Martin, Forrester Research, Keil, Vorlesung Softwareergonomie, hyperskript 1999, Universität Paderborn