Informatik Spektrum 06/08

Performance-Analyse und Optimierung in der Softwareentwicklung

Autoren: ,

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 diesemBeitrag 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 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 dieseWeise 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 dagegenwährend der Erhöhung der Last auf. Ineffiziente Algorithmen oder Zugriffspfade werden zumeist schon bei geringer Systemlast identifiziert.

Problemkategorien

Performance-Analyse und -Optimierung

Ziel der Performance-Analyse ist es, die vorliegende Anwendung inmehreren 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]. DieseVerfahren eignen sich insbesondere dafür, die notwendige Kapazität des Systems zu bestimmen bzw. vorher- 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äsentativeMenge 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 Abb. 1 Vorgehensmodell zur Performance-Analyse und -Optimierung 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 verschiedeneHerangehensweisen 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 manuelle 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- 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.

Vorgehensmodell

Konfiguration und Durchführung von Lasttests

Für Zeittests und Lasttests müssen imRahmen 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.

Lasttest-Szenarien

Im ersten Zyklus wird im Infrastruktur-Lasttest das Netzwerk und die Middleware mit einer trivialen Transaktion und der maximalen Anzahl Benutzer 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 Formvon 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 imRahmen 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. Tabelle 3 Rollen imPerformance-Team Rollenbezeichnung Hauptaufgaben Projektleiter Performance Kosten- und Terminverantwortung, Kommunikation Performance-Architekt Fachliche Gesamtverantwortung, Gewährleistung der Einhaltung nicht-funktionaler Anforderungen Projektleiter Optimierung der Anwendung gem. Vorgaben des Performance-Teams Anwendungsentwicklung Release-Manager Bereitstellung neuer Releases, Sicherstellung einer stabilen Umgebung während der Zeit- und Lasttests Zeittest-Spezialist Vorbereitung, Durchführung und Nachbereitung der Zeittests Lasttest-Spezialist Vorbereitung, Durchführung und Nachbereitung der Lasttests Profiling- und Analyse von identifizierten Problemen durch Profiling- und Memory-Debugging, Erstellung von Memory-Debugging-Spezialist Optimierungsvorschlägen Infrastruktur-Spezialisten Analyse und Optimierung der Infrastruktur (Datenbank, Netzwerk, Middleware, Backend) Testprodukt-Spezialisten Installation, Konfiguration und Ausbau der Testwerkzeuge.

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 odermehrere Rollen von einer Person übernommen werden. Die Zuweisung der Anzahl von Rollen auf Personen hängt imWesentlichen 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.

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 ImRahmen einer Performance-Analyse und -Optimierung wird eine Vielzahl verschiedenerWerkzeuge eingesetzt. Bei der Auswahl derWerkzeuge stehen die Stabilität und ein zweckmäßiger Funktionsumfang im Vordergrund. Es sollte genau betrachtet werden, welcheWerkzeuge die Anforderungen des konkreten Projektes ambesten erfüllen. Es ist nicht entscheidend, das Werkzeug mit den meisten Funktionen zu erwerben. Die Stabilität und Zweckmäßigkeit des verwendetenWerkzeugs 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].

Rollen im Performance-Team

Ereignistypen für einen Lasttest

Zusammenfassung und Ausblick

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

Werkzeuge für die Performanceanalyse

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)
  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, 143–160 (1988)
  5. Firesmith, D.G.: Common concepts underlying safety, security, and survivability engineering.
  6. Carnegie Mellon Software Engineering Institute – Technical Note CMU/SEI-2003-TN-033 (2003) http://www.sei.cmu.edu/pub/documents/ 03.reports/pdf/03tn033.pdf
  7. Marzolla, M.: Simulation-Based Performance Modeling of UML Software Architectures. PhD thesis, Università Ca Foscari di Venezia (2004)
  8. Menasce, D.A., Almeida, V.A.F., Dowdy, L.W.: Capacity Planning and Performance Modeling: from mainframes to client-server systems. Prentice Hall (1994)
  9. Smith, C.U.: Performance Engineering of Software Systems. Addision-Wesley (1990)
  10. Asböck, S.: Load Testing for eConfidence. Hamburg: Segue Software Deutschland GmbH (2001)
  11. Killelea, P.: Web Performance Tuning, 2. Auflage. O’Reilly Media (2002)
  12. Loukides, M., Musumeci, G.-P.: System Performance Tuning, 2. Auflage. Sebastopol: O’Reilly & Associates (2002)
  13. Burke R.: Network Management. Concepts and Practice: A Hands-on Approach. Pearson Education, Inc. (2004)
  14. Haines, S.: Pro Java EE 5 Performance Management and Optimization, friends of ED (2006)
  15. Schmietendorf, A., Scholz, A.: Aspects of performance engineering – an overview. In: Performance Engineering: State of the Art and Current Trends. Springer Verlag (2001)
  16. Spiller, A., Linz, T.: Basiswissen Softwaretest. Heidelberg: dpunkt-Verlag (2003)
  17. Software QA/Test Resource Center: http://www.softwareqatest.com/qatweb1.html (2007)
  18. Applied Testing and Technology, Inc.: http://www.aptest.com/resources.html (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 66273. Heidelberg: Hüthig Verlag (1994)
  21. Nationale Norm DIN 66273, Teile 1–4 (Leistungsmessverfahren und Normlasten) (1992–2001)
  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, http://www.tyranus.de/downloads/papers/lasttesttool_evaluation.pdf (2004) 258 Informatik_

Vollständiger Artikel

Artikel von Tobias Knierim

Konferenzen

JavaOne 2010