Performance-Analyse und -Optimierung in der Softwareentwicklung

Transkript

1 HAUPTBEITRAG / PERFORMANCE-ANALYSE UND -OPTIMIERUNG } Performance-Analyse und -Optimierung in der Softwareentwicklung Niklas Schlimm Mirko Novakovic Robert Spielmann Tobias Knierim Nicht-funktionale Anforderungen an ein Softwaresystem beschreiben Aspekte, die nicht direkt die Funktionalität, wie sie der Benutzer sieht, betreffen. Die Verarbeitungsgeschwindigkeit oder die,,performance eines Softwaresystems stellt dabei eine der bedeutendsten nicht-funktionalen Eigenschaften dar. Eine träge Anwendung, die zu langsam reagiert, führt schnell zu Verärgerung bei den Benutzern. Es geht aber nicht nur um die Zufriedenheit der Endbenutzer. Eine schlechte Performance kann Einfluss auf die Länge von Arbeitsabläufen nehmen und damit das Verhältnis der Unternehmung zu ihren Kunden negativ beeinflussen. Die Entwicklung neuerer Standards und Architekturformen wie Serviceorientierte Architekturen (SOA) verleiht dem Thema Performance darüber hinaus eine zunehmende Bedeutung, weil komfortablere und leistungsstärkere Technologien immer höhere Anforderungen an die einzuplanende Ressourcenkapazität stellen. Einführung Trotz der Komplexität des Themas wird in der Projektpraxis häufig auf eine systematische Herangehensweise an das Thema Performance verzichtet. Wir stellen deswegen in diesem Beitrag eine allgemeine Vorgehensweise zur Performance-Analyse und -Optimierung vor, die bereits mehrfach erfolgreich im Großprojekt eingesetzt wurde. Sie soll das Performance-Risiko in Projekten reduzieren, den Aufbau und die Integration des Themas in die jeweiligen Softwareprozesse erleichtern und Anhaltspunkte für die Aufwandsschätzung liefern. Der Beitrag legt einen Schwerpunkt auf die Betrachtung von Performance-Problemen in Online-Anwendungen. Das dargestellte Vorgehensmodell kann jedoch ebenfalls für die Performance-Analyse und -Optimierung im Bereich der Stapelverarbeitung (engl.,,batch ) eingesetzt werden. Zum Begriff Performance Auf eine ausgiebige Diskussion des Begriffs,,Performance wird an dieser Stelle verzichtet. Stattdessen verweisen wir auf die einschlägigen Literaturquellen und verwenden hier folgende Definition [1]:,,Performance is the degree to which a software system or component meets its objectives for timeliness. Unter,timeliness versteht man dabei primär das Antwortzeitverhalten sowie sekundär den Durchsatz und die Kapazität eines Anwendungssystems [2]. Das Antwortzeitverhalten beschreibt die Geschwindigkeit des Systems aus Endbenutzersicht [3]. Der Durchsatz gibt an, wie viele Transaktionen oder Daten ein System pro Zeiteinheit verarbeiten kann [4]. Die Kapazität eines Systems beschreibt den Umfang der Ressourcen, die ein System zur Verfügung hat (Anzahl der Prozessoren, Prozessorgeschwindigkeit, Festplattenkapazität, Netzwerkbandbreite) [5]. Der Durchsatz und die Kapazität sind sekundäre Performance-Eigenschaften, weil sie bereits die DOI /s Springer-Verlag 2007 Niklas Schlimm, Mirko Novakovic, Robert Spielmann, Tobias Knierim codecentric GmbH, Grünewalder Str , Solingen {schlimm,novakovic,spielmann,knierim}@codecentric.de Informatik_Spektrum_30_4_

2 { PERFORMANCE-ANALYSE UND -OPTIMIERUNG Ursache für schlechte Antwortzeiten sein können. Ferner bemisst sich die Qualität einer Anwendung aus Endbenutzersicht am individuellen Antwortzeitverhalten. Endbenutzer sind verärgert, weil das System auf Benutzeraktionen nicht in der gewünschten Geschwindigkeit reagiert. Eine Rechtfertigung, dass der Durchsatz oder die Kapazität das eigentliche Problem sind, dürfte beim Kunden hingegen auf Desinteresse stoßen. Problemkategorien im Bereich Performance Wenn eine Anwendung auf Benutzeraktionen inakzeptabel langsam reagiert, dann können hierfür verschiedene Gründe vorliegen. Eine Analyse der in mehreren großen Neuentwicklungsprojekten und Performance-Analysen aufgetretenen Probleme ergab acht Problemkategorien, die in Tabelle 1 dargestellt werden. Die vorgeschlagene Einteilung ist empfehlenswert, weil sich auf diese Weise einzelne Maßnahmen in einer Performance-Analyse auf ausgewählte Problemkategorien beschränken können. Das System wird schrittweise auf Probleme in den einzelnen Kategorien durchsucht. Als Folge jeder Problemkategorie kann im Alltagsbetrieb ein Systemabsturz eintreten. Die Stabilität des Betriebs wird also unter Umständen erheblich gestört. Intermittierende Probleme und Speicherlecks treten üblicherweise erst bei längerer Laufzeit der Anwendung auf. Das Reinitialisierungsproblem, Flaschenhälse, Ressourcenauslastung und Ressourcenkonflikte treten dagegen während der Erhöhung der Last auf. Ineffiziente Algorithmenoder Zugriffspfade werden zumeist schon bei geringer Systemlast identifiziert. Performance-Analyse und -Optimierung Ziel der Performance-Analyse ist es, die vorliegende Anwendung in mehreren Testreihen sukzessive nach Problemen in den oben eingeführten Kategorien zu durchsuchen und die entdeckten Probleme zu eliminieren. Das hier vorgestellte Verfahren unterscheidet sich also ganz wesentlich von anderen Ansätzen zur Performance-Analyse, in denen Performance-Modelle, Simulation und Vorhersage eine elementare Rolle spielen [6 8]. Diese Verfahren eignen sich insbesondere dafür, die notwendige Kapazität des Systems zu bestimmen bzw. vorher- Performance-Problemkategorien Problemkategorie Beschreibung Tabelle 1 Ineffiziente Algorithmen Ineffiziente Zugriffspfade Speicherleck (engl.,,memory leak ) Reinitialisierungsproblem Flaschenhälse Intermittierende Probleme Ressourcenauslastung Ressourcenkonflikte (engl.,,deadlocks ) Es kommt schon bei geringer Last zu schlechtem Antwortzeitverhalten, weil umständliche Algorithmen implementiert wurden. Ein Spezialfall ineffizienter Algorithmen, bei dem der Datenspeicher eine suboptimalelösung für die Durchführung einer Datenabfrage ermittelt. Es kommt zu einer Verschlechterung des Antwortzeitverhaltens bei längerer Laufzeit, verursacht durch mangelhaftes Speichermanagement. Das System verhält sich bei zunehmender Last unberechenbar, weil Speicherbereiche vor der Verwendung nicht sauber initialisiert werden. Es kommt zu exponentiell steigenden Antwortzeiten, weil an bestimmten Systemstellen eine Warteschlange entsteht. Dabei werden pro Zeiteinheit mehr Anfragen an die Systemstelle herangetragen als verarbeitet werden können. Das System reagiert plötzlich mit sehr schlechten Antwortzeiten, weil zum Beispiel die Netzwerkverfügbarkeit durch andere Prozesse gestört wird. Es kommt zu einer exponentiellen Verschlechterung des Antwortzeitverhaltens bei Erhöhung der Last, weil sich die CPU-Auslastung an bestimmten Systemknoten der Auslastungsgrenze nähert. Es kommt bei zunehmender Last zu Konfliktsituationen durch parallelen Zugriff auf gemeinsame Ressourcen wie Datenbanktabellen. 252 Informatik_Spektrum_30_4_2007

3 zusagen. Der Schwerpunkt des hier vorgestellten Verfahrens liegt darin, in Messreihen konkrete Performance-Probleme zu identifizieren, zu diagnostizieren und später in der Optimierung durch konkrete Gegenmaßnahmen zu eliminieren. Die Identifikation von Performance-Problemen erfolgt in Zeittests und Lasttests. Der Zeittest betrachtet das Performance-Verhalten der Anwendung im Einzelbenutzerbetrieb, aber mit realistischem Datenvolumen im Datenspeicher. Es wird genau ein Benutzer simuliert, der die Benutzeroberfläche bedient und auf einem realistisch befüllten Datenspeicher arbeitet. Der Lasttest betrachtet das Performance-Verhalten der Anwendung unter Alltagsbedingungen [9]. Das heißt: es wird eine repräsentative Menge paralleler Benutzer simuliert, die die Anwendung zugleich über einen längeren Zeitraum bedienen. Sind im Rahmen der Zeittests und Lasttests Probleme erkannt worden, so beginnt der Optimierungsprozess. Die Optimierung (engl.,,performance tuning ) soll das Antwortzeitverhalten der Anwendung verbessern [10, 11]. Die Optimierung bedient sich ebenfalls spezieller Techniken. Beim Memory-Debugging wird der Speicherverbrauch genau untersucht. So werden Speicherlecks lokalisiert und eliminiert. Beim Profiling werden detaillierte Informationen von Systemkomponenten ausgewertet um zum Beispiel ineffiziente Algorithmen und Zugriffspfade zu verbessern. Beziehung zu angrenzenden Prozessen Die Performance-Analyse und -Optimierung kann in verschiedenen übergeordneten Prozessen angewendet werden. Performance-Management ist eine Teildisziplin des System-Management, die sich auf die Beobachtung in Produktion befindlicher Anwendungen und Netzwerke konzentriert [12, 13]. Hier werden in regelmäßigen Abständen Performance- Analysen und -Optimierungen durchgeführt. In einem Neuentwicklungsprojekt ist die Performance- Analyse und -Optimierung Teil der Betriebstests. Im Performance-Engineering [14], welches eine integrierte Performance-Optimierung über den gesamten Softwareentwicklungsprozess vorschlägt, ist die Performance-Analyse Teil der Qualitätssicherung. Die Optimierung ist Teil des Performance-Tuning. Das Vorgehensmodell Einführung Es gibt sicher verschiedene Herangehensweisen an das Thema Performance in einem Projekt. In vielen Projekten wird das Thema praktisch nicht beachtet in der Hoffnung, dass die Anwendung auch im Betrieb stabil funktioniert. Andere Projekte versuchen sporadisch manuell Messungen vorzunehmen oder testen, wie sich die Anwendung verhält, wenn mehrere Personen auf der Anwendung arbeiten. Bei nicht unternehmenskritischen Anwendungen mit wenigen Benutzern ist das möglicherweise ein vertretbares Vorgehen. Bei jeder unternehmenskritischen Anwendung empfiehlt sich jedoch eine systematischere Herangehensweise, um das Risiko von Produktionsausfällen zu reduzieren. Abbildung 1 zeigt die Übersicht über ein systematisches Vorgehensmodell zur Performance- Analyse und -Optimierung. Das Vorgehensmodell verläuft zyklisch in mehreren Iterationen. Die An- Abb. 1 Vorgehensmodell zur Performance-Analyse und -Optimierung Informatik_Spektrum_30_4_

4 { PERFORMANCE-ANALYSE UND -OPTIMIERUNG zahl der Zyklen hängt im Wesentlichen von der Größe der Anwendung und den Analysezielen ab. Jede Iteration hat dabei einen speziellen Untersuchungsgegenstand. Zu Beginn eines Zyklus wird ein neues Release in die Testumgebung oder in die Produktion eingespielt. Anschließend kann mit den Last- und Zeittests begonnen werden. Dabei werden als Teilphasen die Vorbereitung, Durchführung und Nachbereitung unterschieden. In diesen Teilphasen werden spezielle Ergebnistypen erarbeitet (vgl. Tabelle 4). Dazu gehören in der Vorbereitung eines Lasttests zum Beispiel die Lasttestskripte zur Simulation der Benutzer oder die Festlegung und Konfiguration von zu erstellenden Protokolldateien der einzelnen Systemknoten (Tracespezifikation). Im Rahmen der Durchführung von Zeit- und Lasttests werden dann Probleme identifiziert. Diese werden im Profiling genauer untersucht und letztendlich durch Hardware- oder Softwareänderungen im Rahmen der Optimierung eliminiert. Das Ergebnis jeder Lasttest- und Zeittestreihe sollte aufgearbeitet und an das Projektund Kundenmanagement berichtet werden. Der Memory-Debugging-Prozess kann grundsätzlich parallel zu Zeittests und Lasttests in separaten Testreihen durchgeführt werden. Es ist dabei sinnvoll, Speicherprobleme vor dem Profiling zu diagnostizieren, da sich Speicherprobleme auf die Ergebnisse im Profiling auswirken können. Identifizierte Speicherlecks werden dann ebenfalls im Rahmen der Optimierung eliminiert. Konfiguration und Durchführung von Lasttests Für Zeittests und Lasttests müssen im Rahmen der Vorbereitung Testszenarien [15] festgelegt werden, die das Ziel der jeweiligen Tests und deren Konfiguration und Reihenfolge genauer beschreiben. Die konkrete Ausgestaltung der Testszenarien ist sehr projektspezifisch. Dennoch wird hier aufgrund der übergeordneten Bedeutung ein bewährtes Verfahren zur Konfiguration von Lasttests vorgestellt (Tabelle 2). Die unterschiedlichen Konfigurationen der Testszenarien haben zum Ziel, das Softwaresystem iterativ nach Problemen in den eingeführten Problemkategorien zu durchsuchen. Dabei wird sich auf unterschiedliche Systemkomponenten konzentriert. Die Testszenarien werden in Anlehnung an das Vorgehensmodell in separaten Zyklen durchgeführt. Im ersten Zyklus wird im Infrastruktur-Lasttest das Netzwerk und die Middleware mit einer trivialen Transaktion und der maximalen Anzahl Benutzer Lasttest-Szenarien (A = Alle / M = Maximal / R = Repräsentativ) Konfiguration Fokussierte Fokussierte Problemkategorien Systemkomponenten Tabelle 2 Testszenario Name Zeitbereich Anzahl Geschäftsvorfälle Anzahl parallele Benutzer Ineffiziente Algorithmen Ineffiziente Zugriffspfade Speicherleck Reinitialisierungsproblem Flaschenhälse Intermittierende Probleme Ressourcenauslastung Ressourcenkonflikte Client Netzwerk Server Middleware Backend Infrastruktur-Lasttest 1 Stunde - M x x x x GV-Exklusivtest 1 Stunde 1 R x x x x x x GV-Dualbetrieb 1 Stunde 2 R x x x GV-Alltagslast 1 Stunde A R x x x x x x x GV-Alltagslast 8 Stunden A R x x x x x x GV-Spitzenlast 8 Stunden A M x x x x x x 254 Informatik_Spektrum_30_4_2007

5 belastet. Die maximale Anzahl Benutzer entspricht der Anzahl registrierter Benutzernamen für die Anwendung. Im Infrastruktur-Lasttest können schon die ersten Instabilitäten in Form von Flaschenhälsen und Ressourcenengpässen aufgedeckt werden. Anschließend werden in mehreren Zyklen unterschiedlich konfigurierte Lasttests auf ganzen Geschäftsvorfällen durchgeführt. Geschäftsvorfälle sollten dabei mit der zu erwartenden, oder anders formuliert, einer repräsentativen Menge parallel arbeitender Benutzer zunächst exklusiv und dann in Kombination getestet werden. Die Testszenarien nähern sich stufenweise der zu erwartenden Alltagslast. Zuletzt wird in einem Spitzenlast-Szenario die Auslastungsgrenze des Systems ermittelt. Dabei wird die Systemlast auf allen Geschäftsvorfällen auf die maximale Anzahl paralleler Benutzer erhöht. Das entspricht der Annahme, dass alle registrierten Benutzer zugleich mit dem System arbeiten. Wenn Probleme in den skizzierten Testszenarien auftreten, dann sollten die Testszenarien im Rahmen von Diagnoseläufen wiederholt werden. Dabei wird die Ursache des Performance-Problems anhand spezieller Diagnosewerkzeuge (vgl. Tabelle 5) genauer eingegrenzt oder identifiziert. Wenn die Anwendung zuletzt in allen Testszenarien stabil bleibt, ist die Wahrscheinlichkeit sehr gering, dass während der Produktion Performance-Probleme auftreten. Organisation des Performance-Teams Die Organisation des Performance-Teams ist für eine erfolgreiche Performance-Analyse und -Optimierung von besonderer Bedeutung. In einem größeren Projekt sind zahlreiche Personen an der Performance-Analyse und -Optimierung beteiligt (Tabelle 3). Es ist nicht zwingend notwendig, dass alle Personen in einem Team vereinigt werden. Es hat sich jedoch im Sinne einer effizienten Kommunikation als zweckmäßig erwiesen, dass möglichst viele der dargestellten Rollen in einem Team zusammengefasst werden. Je nach Arbeitsaufwand können zwei oder mehrere Rollen von einer Person übernommen werden. Die Zuweisung der Anzahl von Rollen auf Personen hängt im Wesentlichen vom Umfang der betrachteten Anwendung ab. Ergebnistypen Im Rahmen der einzelnen Phasen des Vorgehensmodells werden spezielle Ergebnistypen erarbeitet. Dabei gibt es übergreifende Ergebnistypen und Ergebnistypen, die speziell zur Vorbereitung, Durchführung oder Nachbereitung der Zeittests oder Lasttests erstellt werden. Eine vollständige Darstellung aller Ergebnistypen ist hier aus Platzgründen nicht möglich. Wir beschränken uns in Tabelle 4 deswegen auf die Darstellung der für einen Lasttest notwendigen Ergebnistypen. Rollen im Performance-Team Rollenbezeichnung Hauptaufgaben Tabelle 3 Projektleiter Performance Performance-Architekt Projektleiter Anwendungsentwicklung Release-Manager Zeittest-Spezialist Lasttest-Spezialist Profiling- und Memory-Debugging-Spezialist Infrastruktur-Spezialisten Testprodukt-Spezialisten Kosten- und Terminverantwortung, Kommunikation Fachliche Gesamtverantwortung, Gewährleistung der Einhaltung nicht-funktionaler Anforderungen Optimierung der Anwendung gem. Vorgaben des Performance-Teams Bereitstellung neuer Releases, Sicherstellung einer stabilen Umgebung während der Zeit- und Lasttests Vorbereitung, Durchführung und Nachbereitung der Zeittests Vorbereitung, Durchführung und Nachbereitung der Lasttests Analyse von identifizierten Problemen durch Profiling- und Memory-Debugging, Erstellung von Optimierungsvorschlägen Analyse und Optimierung der Infrastruktur (Datenbank, Netzwerk, Middleware, Backend) Installation, Konfiguration und Ausbau der Testwerkzeuge Informatik_Spektrum_30_4_

6 { PERFORMANCE-ANALYSE UND -OPTIMIERUNG Ergebnistypen für einen Lasttest Ergebnistyp Teilphase Beschreibung Tabelle 4 Performance-Konzept Übergreifend Beschreibt das Vorgehen und den Inhalt der Performance-Analyse und -Optimierung im konkreten Projekt, Enthält auch die nicht-funktionalen Anforderungen Messarchitektur Übergreifend Beschreibung der Architekturschichten und der integrierten Messpunkte inkl. Protokollformate Testkalender Übergreifend Übersicht über die Terminierung von Zeit- und Lasttests Performance-Budgets Übergreifend Festlegung der Zeitbudgets für die einzelnen Architekturschichten Tracespezifikation Übergreifend Beschreibung welche Protokolldateien bei welchem Testszenario von wem und in welcher Umgebung anzuschalten sind Testszenarien Vorbereitung Beschreibung der genauen Ziele und Konfiguration der geplanten Lasttestreihen Volumenvorgaben Vorbereitung Beschreibung der Volumen für die einzelnen Geschäftsvorfälle zur Konfiguration der Szenarien im Lastgenerator Lasttestskripte Vorbereitung Skripte für die Simulation virtueller Benutzer Ansprechpartner Vorbereitung Liste der Ansprechpartner im Betrieb und für Infrastrukturteile Checkliste Lasttest Vorbereitung Checkliste für die Aufgaben, die vor, während und nach dem Lasttest erledigt werden müssen Testergebnisberichte Durchführung Ergebnisdokumentation der einzelnen Testläufe inklusive Problembeschreibungen und Ergebnisberichten der Lasttest Werkzeuge Problemliste Nachbereitung Konsolidierte Liste der identifizierten Performance-Probleme in allen Testreihen Management-Bericht Nachbereitung Ergebnis der Lasttests, aufbereitet für das Management Auslastungsmatrix Nachbereitung Darstellung der Auslastung der Systemknoten in den einzelnen Lasttests zur Ableitung notwendiger Kapazitätserweiterungen Problemeintrag Nachbereitung Eintrag des Performance-Problems und Optimierungsvorschlag in das Problemmanagement-Werkzeug, damit der Optimierungsauftrag erteilt wird Hervorzuheben ist das Performance-Konzept, in dem die projektspezifische Anpassung des hier vorgestellten generischen Vorgehensmodells erfolgt und die Testobjekte der Performance-Analyse und -Optimierung beschrieben werden. Darüber hinaus werden im Performance-Konzept auch die Performance-Ziele in Form von Performance- Budgets definiert. Performance-Budgets legen fest, wie viel Zeit in den einzelnen Systemkomponenten maximal verbraucht werden darf. Performance-Werkzeuge Im Rahmen einer Performance-Analyse und -Optimierung wird eine Vielzahl verschiedener Werkzeuge eingesetzt. Bei der Auswahl der Werkzeuge stehen die Stabilität und ein zweckmäßiger Funktionsumfang im Vordergrund. Es sollte genau betrachtet werden, welche Werkzeuge die Anforderungen des konkreten Projektes am besten erfüllen. Es ist nicht entscheidend, das Werkzeug mit den meisten Funktionen zu erwerben. Die Stabilität und Zweckmäßigkeit des verwendeten Werkzeugs sind hier aus Erfahrung die wichtigeren Eigenschaften. In Tabelle 5 werden die verschiedenen Werkzeugarten mit Produktbeispielen für verteilte Java-Umgebungen vorgestellt. Für eine umfangreiche und aktuelle Liste von konkreten Werkzeugen siehe [16 18]. Zusammenfassung und Ausblick Eine systematische Herangehensweise an das Thema Performance ist in der Praxis nicht besonders weit verbreitet, empfiehlt sich aber insbesondere für unternehmenskritische Geschäftsanwendungen. Die Performance-Analyse und -Optimierung kann dabei in den Testprozess eines Neuentwicklungsprojektes, in den Performance-Engineering-Prozess und später in den System-Management-Prozess der jeweiligen Anwendung eingebettet werden. Eine Einbettung in den Performance Engineering Prozess in Kombination mit Verfahren aus dem Bereich der Performance-Modellierung für die 256 Informatik_Spektrum_30_4_2007

7 Werkzeuge für die Performance-Analyse und -Optimierung Werkzeugtyp Beschreibung Beispiel Produkte Tabelle 5 Automatisierungswerkzeuge Für die Zeittests wird ein Werkzeug benötigt, das Borland SilkTest IBM Abläufe über die Benutzeroberfläche der Anwendung Rational Functional Tester automatisieren kann. Mercury WinnRunner Lastgeneratoren Für Lasttests werden spezielle Werkzeuge benötigt, die Borland SilkPerformer eine Vielzahl von Benutzern simulieren können. Häufig Mercury LoadRunner müssen diese Werkzeuge erweitert werden, weil bestimmte Apache Jakarta JMeter Netzwerkprotokolle nur rudimentär unterstützt werden. Performance- Diese Werkzeuge werden üblicherweise bei in Produktion Quest Foglight Service Monitoring-Werkzeuge befindlichen Anwendungen eingesetzt, um das Management Zeitverhalten kontinuierlich zu kontrollieren. CA Wily Introscope IBM Tivoli Composite Application Manager (ITCAM) Diagnosewerkzeuge Diagnosewerkzeuge werden während Lasttests eingesetzt, Quest PerformaSURE um die Ursache eines festgestellten Performance- dynatrace Diagnostics Problems genauer einzugrenzen und zu identifizieren. Profiling-Werkzeuge Für die verschiedenen Infrastrukturkomponenten und Quest JProbe Suite Programmiersprachen werden spezielle Profiling-Tools ej-technologies JProfiler angeboten. Die Auswahl hängt dabei stark von den YourKit Profiler eingesetzten Technologien ab. Die Profiling-Werkzeuge eignen sich zur Analyse und Optimierung des Zeitverhaltens kleinster Programmkomponenten. Memory-Debugging- Zur Identifikation und Eliminierung von Speicherlecks Quest JProbe Suite Werkzeuge werden Memory-Debugging-Werkzeuge eingesetzt. ej-technologies JProfiler YourKit Profiler Datenbankanalyse- Für die Analyse von Datenbankzugriffen und Ressourcen- Quest Central werkzeuge konflikten werden spezielle Werkzeuge verwendet. Auswertungswerkzeuge Im Rahmen von Zeittests und Lasttests werden diverse Nicht kommerziell verfügbar für Protokolldateien Protokolldateien durch Anwendungen und Infrastruktur Komponenten geschrieben. Diese Protokolldateien können von Werkzeugen ausgewertet werden, sodass eine integrierte Ergebnisübersicht ermöglicht wird. Problemdatenbank Zur Erteilung von Optimierungsaufträgen an die Atlassian JIRA Bugzilla Entwicklung kann eine Problemdatenbank verwendet Mercury TestDirector werden. IBM Rational ClearQuest Kapazitätsplanung erscheint besonders empfehlenswert. Dadurch können das Performance-Risiko und etwaige Optimierungskosten zum Ende eines Entwicklungsprojektes minimiert werden. Die praktische Bedeutung des Themas Performance ist schon seit Beginn der elektronischen Datenverarbeitung hoch und wird seit Jahren entsprechend gewürdigt durch Einbeziehung in die Lehre an Universitäten oder durch Bemühungen, das Thema einer Standardisierung zuzuführen [19 21]. Wünschenswert wäre eine Projektion von Normen und hier angesprochenen Verfahren auf konkretere technologische Standards wie Serviceorientierte Architekturen (SOA) und moderne Internet- Anwendungen im Open-Source oder J2EE Bereich. Dadurch würde den jeweiligen IT-Verantwortlichen ein professionelles Herangehen an das Thema Performance für ihre konkrete Problemstellung erleichtert. Literatur 1. Smith, C.U.: Performance Solutions: A Practical Guide To Creating Responsive, Scalable Software. Addison-Wesley (2002) 2. Pressman, R.S.: Software Engineering A Practitioner s Approach. McGraw-Hill, Inc. (1992) Informatik_Spektrum_30_4_

8 { PERFORMANCE-ANALYSE UND -OPTIMIERUNG 3. Smith, C.U., Williams, L.G: Introduction to Software Performance Engineering. Addison-Wesley (2001) 4. Woodside, C.M.: Throughput calculation for basic stochastic rendesvous networks. Perform. Eval. 9, (1988) 5. Firesmith, D.G.: Common concepts underlying safety, security, and survivability engineering. Carnegie Mellon Software Engineering Institute Technical Note CMU/SEI-2003-TN-033 (2003) 03.reports/pdf/03tn033.pdf 6. Marzolla, M.: Simulation-Based Performance Modeling of UML Software Architectures. PhD thesis, Università Ca Foscari di Venezia (2004) 7. Menasce, D.A., Almeida, V.A.F., Dowdy, L.W.: Capacity Planning and Performance Modeling: from mainframes to client-server systems. Prentice Hall (1994) 8. Smith, C.U.: Performance Engineering of Software Systems. Addision-Wesley (1990) 9. Asböck, S.: Load Testing for econfidence. Hamburg: Segue Software Deutschland GmbH (2001) 10. Killelea, P.: Web Performance Tuning, 2. Auflage. O Reilly Media (2002) 11. Loukides, M., Musumeci, G.-P.: System Performance Tuning, 2. Auflage. Sebastopol: O Reilly & Associates (2002) 12. Burke R.: Network Management. Concepts and Practice: A Hands-on Approach. Pearson Education, Inc. (2004) 13. Haines, S.: Pro Java EE 5 Performance Management and Optimization, friends of ED (2006) 14. Schmietendorf, A., Scholz, A.: Aspects of performance engineering an overview. In: Performance Engineering: State of the Art and Current Trends. Springer Verlag (2001) 15. Spiller, A., Linz, T.: Basiswissen Softwaretest. Heidelberg: dpunkt-verlag (2003) 16. Software QA/Test Resource Center: (2007) 17. opensourcetesting.org: (2007) 18. Applied Testing and Technology, Inc.: (2007) 19. Internationale Norm ISO 14756: Measurement and Rating of Performance of Computer-Based Software Systems (1999/2000) 20. Dirlewanger, W.: Messung und Bewertung der DV-Leistung auf Basis der Norm DIN Heidelberg: Hüthig Verlag (1994) 21. Nationale Norm DIN 66273, Teile 1 4 (Leistungsmessverfahren und Normlasten) ( ) 22. Blum, R.: Network Performance Toolkit: Using Open Source Testing Tools. Wiley (2003) 23. Crawford, I., Wadleigh, K.: Software Optimization for High Performance Computing: Creating Faster Applications. Prentice Hall (2000) 24. Eigenmann, R.: Performance Evaluation and Benchmarking with Realistic Applications. The MIT Press (2001) 25. Gerber, R.: Software Optimization Cookbook: High-Performance Recipes for the Intel Architecture. Intel Press (2002) 26. Jain, R.K.: The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling. Wiley (2001) 27. Lilja, D.J.: Measuring Computer Performance: A Practitioner s Guide. Cambridge University Press (2000) 28. Menasce, D., Almeida, V.A.F.: Capacity Planning for Web Performance: Metrics, Models, and Methods. Prentice Hall (1998) 29. Menasce, D.A., Dowdy, L.W., Almeida, V.A.F.: Performance by Design: Computer Capacity Planning By Example. Prentice Hall PTR (2004) 30. Smith, C.U., Williams, L.G.: Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software. Boston, MA: Addison-Wesley (2002) 31. Stoll, C., Pommerening, T.: Evaluation von Lasttest-Tools und Performance Studie, (2004) 258 Informatik_Spektrum_30_4_2007