Performancemanagement für serviceorientierte Java-Anwendungen GERMAN

Xpert.press

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Christof Schmalenbach

Performancemanagement für serviceorientierte JAVA-Anwendungen Werkzeug- und Methodenunterstützung im Spannungsfeld von Entwicklung und Betrieb

Mit 50 Abbildungen und 16 Tabellen

123

Christof Schmalenbach IBM Deutschland GmbH Karl-Arnold-Platz 1a D-40474 Düsseldorf [email protected]

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISSN 1439-5428 ISBN 978-3-540-36631-7 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2007 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: ptp, Berlin Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3180 YL – 5 4 3 2 1 0

Für Kerstin und unsere Tochter Laura

Vorwort

Der Markt für Systemsoftware, welche die Entwicklung und den Betrieb von performanten Anwendungen zu unterstützen verspricht, ist nahezu unübersichtlich geworden. Und das nicht ohne Grund. Denn mit dem wachsenden Grad der Verteilung von Komponenten auf physisch und geographisch entfernten Servern und Netzwerken werden die bedarfsgerechte Planung von Kapazitäten und die Gewährleistung zugesagter Qualitätsmerkmale im Hinblick auf Antwortzeiten und Durchsatz zunehmend schwieriger. Dies kann bereits beobachtet werden, seit durch Java die Programmierung von Anwendungen, die über Prozessgrenzen hinweg miteinander kommunizieren, deutlich vereinfacht wurde und J2EE als eine der Schlüsseltechnologien zur Entwicklung kritischer Geschäftsanwendungen eingesetzt wird. Mit der Verbreitung serviceorientierter Technologien wird sich dieser Trend noch verstärken, da die bisher noch häufig vorzufindende enge Bindung zwischen einzelnen Applikationen durch solche Architekturen zurückgedrängt werden wird, in denen Services in vielfältiger Weise zu Anwendungen gebündelt werden können (composite applications). Damit Entwickler und Anwendungsarchitekten bereits in frühen Entwicklungsphasen mögliche Performancerisiken erkennen oder Systemadministratoren das Laufzeitverhalten produktiver Anwendungen kontrollieren können, sind selbstverständlich auch angemessene Werkzeuge erforderlich. Allzu oft besteht aber die Neigung, den Performanceherausforderungen durch einen inflationären Einsatz von Systemsoftware und Profilingtools begegnen zu wollen. Häufig wird auch gerne die Aussage formuliert, dass Last- und Performancetest nur dann eine sinnvolle Qualitätssicherung darstellen, wenn sie unter dem Einsatz produktionsidentischer Hardware erfolgen. In den Projekten, in denen der Autor bislang als Performancearchitekt hat wirken können, war es aus Zeit- oder Kostengründen fast nie möglich, diese Voraussetzungen zu erfüllen. Und je weiter die Verwendung von Services über Unternehmensgrenzen hinweg in einer Vielzahl von Anwendungskonstellationen fortschreitet und Infrastrukturen virtualisiert werden, desto weniger kann von der Produktionsumgebung überhaupt noch gesprochen werden.

VIII

Vorwort

Serviceorientierte Architekturen werden nicht zum Selbstzweck betrieben. Wechselnde Anforderungen an das Business sollen durch die IT flexibel und schnell umgesetzt werden können. Mit kürzeren Produktionszyklen schwinden aber auch die Zeiten, die für qualitätssichernde Maßnahmen im Allgemeinen und das Performancemanagement im Besonderen verbleiben. Zukünftig wird es daher immer mehr darauf ankommen, auch unter vagen Annahmen und mit dem Einsatz geringer Ressourcen, Performanceprobleme vermeiden oder deren Ursachen schnell identifizieren und beheben zu können. Die Frage, wie und mit welchen Mitteln dies gelingen kann, ist Gegenstand des vorliegenden Buches. Es wendet sich vornehmlich an Vertreter jener beiden IT-Bereiche, die auf technischer Ebene für die Performanz von Anwendungen verantwortlich sind: Auf der Entwicklungsseite die Anwendungsarchitekten und auf Betriebsseite die Systemadministratoren. Es sind im Wesentlichen die drei folgenden Leitgedanken, die zum Verfassen des Buches motiviert haben und den Rahmen festlegen, in dem es sich bewegt: 1. Planung und Kontrolle sind auch unter restriktiven Bedingungen und Unsicherheit möglich. Unternehmen und Staaten beweisen dies immer wieder, wenn sie umfangreiche Projekte durchführen. Und noch nie hat jemand die Forderung erhoben, ein Staudamm müsse als Prototyp gebaut und unter realen Bedingungen getestet werden, bevor an einen produktiven Betrieb überhaupt zu denken sei. 2. Es gibt einfache Mittel und Verfahren, mit denen ein großer Teil der Planungs- und Kontrollaufgaben gemeistert werden kann. Einfach soll nicht im Sinne von intellektuell wenig herausfordernd, sondern als anspruchslos im Hinblick auf die notwendigen technischen Ressourcen verstanden werden. Bei diesen Mittel handelt es sich u.a. um das klassische Werkzeug schlechthin – die Mathematik. 3. Viele große Open-Source-Projekte sind im Umfeld der J2EE-Entwicklung außerordentlich populär. Hingegen gibt es zahlreiche kleinere Entwicklungsinitiativen, die wenig bekannt sind, aber durchaus nennenswerte Beiträge für das Performancemanagement leisten können. Von beiden Varianten wird das Buch reichlich Gebrauch machen.

Die Struktur des Buches Im ersten Kapitel wird anhand eines fiktiven Szenarios verdeutlicht, warum Performancemanagement oftmals so schwierig ist und dass diese

Die Struktur des Buches

IX

Schwierigkeiten nicht nur technologisch bedingt sind, sondern sich auch aufgrund des unterschiedlichen Selbstverständnisses verschiedener ITKulturen ergeben. Das zweite Kapitel widmet sich dem Entwicklungsprozess und dem Aufbau eines Performanceteams. Die dort vertretenen Rollen und die von den Mitgliedern zu leistenden Aufgaben werden erläutert. Ausführlich wird auf die Gestaltung von Performancetests eingegangen. Im dritten und vierten Kapitel wird eine Einführung in zwei Theorien gegeben, die für das Verständnis des Buches unabdingbar sind, die aber in der IT-Ausbildung üblicherweise allenfalls am Rande behandelt werden. In Kapitel 3 handelt es sich um quantitative Methoden und die Verwendung der Warteschlangentheorie und in Kapitel 4 um die diskrete EreignisSimulation. Das fünfte Kapitel befasst sich mit den wichtigen Themen der Dokumentation von Performanceanforderungen und der vertraglich garantierten Serviceeigenschaften. Kapitel 6 ist als Fortsetzung von Kapitel 3 zu verstehen. Hier wird am Beispiel einer Software, welche IBM zur Performance- und Kapazitätsplanung einsetzt, die praktische Verwendung der quantitativen Methoden und der aus diesen entwickelten Algorithmen erläutert. In Kapitel 7 wird die Simulation von Geschäftsprozessen an einem fiktiven, aber praxisbezogenen Beispiel aus der Versicherungsindustrie vorgestellt. Auch Geschäftsprozesse müssen gewissen Performancekriterien genügen. Selbst wenn diese weniger technisch als fachlich definiert sind, so ist doch die Methodik an vielen Stellen vergleichbar. Sowohl bei der Durchführung von Performancetests als auch im produktiven Betrieb besteht das Bedürfnis, die Laufzeiten bestimmter Methoden oder der von diesen geforderten Rechenleistungen zu ermitteln. Hierfür gibt es eine Reihe kommerzieller Produkte. Im Umfeld von Java nutzen diese häufig ein von der Java Virtual Machine unterstütztes API. In dieses API führt Kapitel 8 ein. Dies geschieht anhand der Entwicklung eines Performancemonitors, den der Autor mitentwickelt und bereits in mehreren Projekten eingesetzt hat. Wer sich für den Einsatz dieses Monitors oder anderer frei verfügbarer Software zur Erhebung von Performancemetriken entscheidet, sieht sich mit dem Problem konfrontiert, geeignete Darstellungsformen für die rohen Performancedaten festzulegen und Diagramme zu erstellen. Mit dem Thema der Datenvisualisierung setzt sich Kapitel 9 auseinander. In Kapitel 10 werden alle bislang vorgestellten Techniken am Beispiel eines Webservices im Zusammenhang genutzt. Die Performance dieses Webservices wird durch quantitative Modelle prognostiziert und die Qualität dieser Prognose durch einen Lasttest überprüft. Dann wird erneut das Thema der diskreten Ereignissimulation aufgegriffen, um das reale Verhalten des Webservices

X

Vorwort

in einer wenige Sekunden dauernden Simulation nachzustellen. Auch wenn Simulationsverfahren heute nur eine bescheidene Rolle bei der Planung von komplexen IT-Infrastrukturen spielen und in diesem Buch auch nur anhand eines überschaubaren Beispiels verwendet werden können, steckt in dieser Methodik nach Überzeugung des Autors ein enormes Potential.

Danksagungen Nachdem mein Entschluss feststand, meine Erfahrungen und Kenntnisse, die ich in den vergangenen Jahren in der Rolle als Performancearchitekt sammeln durfte, in einem Buch darzulegen, hatte ich eine relativ konkrete Vorstellung davon, welche Themen ich darin aufnehmen wollte. Und obgleich ich von diesem Themenkatalog nur geringfügig abgewichen bin, musste ich mit Erstaunen feststellen, dass zu vielen Inhalten, die ich zu beherrschen glaubte, doch noch ein intensiver Informationsaustausch notwendig ist. Wie ich erfahren habe, ist das Verfassen eines Buches mit vielen administrativen Tätigkeiten verbunden. Ohne entsprechende Hilfe hätte ich diese Aufgaben wohl kaum meistern können. Daher möchte ich allen Dank aussprechen, die mir in der unterschiedlichsten Art und Weise ihre Unterstützung gewährt haben. Dem HiPODS (High Peformance On Demand Solutions)-Team der IBM Software Strategy Group und hier ganz persönlich dem Kollegen Noshir Wadia für die Genehmigung, ein Kapitel über den On Demand Performance Advisor aufnehmen zu dürfen, und die Bereitschaft, dieses Kapitel einem Review zu unterziehen. Dem Gründungsdirektor des Human Computer Interaction Laboratory, Professor Shneiderman, für die Nutzungsrechte an der Software Treemap 4.1 im Kapitel Visualisierungstechniken. Herrn Professor Page vom Department Informatik der Universität Hamburg für die Klärung offener Fragen bei der Benutzung des von ihm und seinen Mitarbeitern betreuten Simulationsframeworks Desmo-J. In den vergangenen drei Jahren habe ich bei der DEVK-Versicherung in Köln einige Performanceaktivitäten begleitet. Herrn Geisel vom Vorstand der DEVK möchte ich für die Bereitschaft danken, einige der dort bearbeiteten Themen im Buch aufnehmen zu dürfen. Die in Kapitel 9 aufgeworfenen Fragen im Hinblick auf Internetanwendungen unter Verwendung von Mobilfunk beruhen auf diesen Tätigkeiten. Ohne die angenehme Arbeitsatmosphäre in der von Frau Bauer verantworteten Anwendungsentwicklung und dem von Michael Porschen betreuten Architekturprojekt wären diese Untersuchungen so nicht möglich gewesen. An beide geht stellvertretend für das gesamte DEVK-Team mein herzlichster Dank.

Danksagungen

XI

Natürlich haben auch zahlreiche Einzelpersonen wichtige Beiträge zu dem Buch geleistet. Hier gilt mein erster Dank den Kollegen Norbert Pich, Dr. Joachim Rawolle und Gunther Schichl. Die Idee zu dem in Kapitel 7 simulierten Geschäftsprozess stammt von ihnen und sie haben mir mit Geduld meine Fragen zum versicherungsfachlichen Hintergrund beantwortet. Mit Christian Höfig habe ich die erste Version des in Kapitel 8 vorgestellten Java-Monitors implementiert und 2004 im Dr. Dobb’s Journal veröffentlicht. Mit Freude denke ich an unsere Java- und C-Entwicklung in den Berliner Biergärten zurück. Ohne seine fundierten Unix- und GCCKenntnisse hätte der Monitor wohl niemals „über den Tellerrand von Windows hinausgeschaut“. In diesem Zusammenhang geht auch mein Dank an Jonathan Erickson, den Chefredakteur des DDJ. Er hat meiner Bitte, den Artikel für das Buch in einem größeren Zusammenhang darstellen zu dürfen, spontan und unbürokratisch entsprochen. Dave Jewell hat mich mit umfangreichem Informationsmaterial von IBM zum Thema Performance ausgestattet. Damit war eine bessere Beurteilung des Einsatzgebietes von Simulationstechniken im Bereich des Performancemanagements möglich. Aus den Büchern von Daniel Menasce und denen von Neil Gunther habe ich ein sehr gutes Verständnis für formale Methoden der Kapazitätsplanung gewinnen können. Beide waren mir auch hinsichtlich rechtlicher Fragen bei der Aufnahme von Zitaten im Buch behilflich. Herr Professor Dueck von IBM war der erste, dem ich meine Buchidee unterbreitet habe. Er hat mir meine anfängliche Scheu genommen und damit quasi den Startschuss zur Veröffentlichung gegeben. Mit Dr. Volker Mull habe ich gemeinsam so manche Performanceschlacht geschlagen, manche gewonnen, einige auch verloren. Ich hoffe, wir halten an unserem Plan fest und verfolgen das Thema Simulation weiter. Rat und ständiger Zuspruch meiner beiden Kollegen und Freunde Cemal Cömert und Steffen Fischer waren mir über Monate hinweg ein wichtiger Ansporn. Wenn mir nachts um zwei die Augen fast zufielen, so hatte ich doch gute Chancen, einen von ihnen im internen IBM-Chat anzutreffen und mich durch ihren Witz wieder auf die Beine bringen zu lassen. By the way: Wer von euch beiden plant eigentlich unsere nächste Eifelwanderung? Zeit hätte ich ja nun wieder ☺. Frau Riepl von LE-TeX in Leipzig hat sehr bereitwillig alle meine laienhaften Fragen rund um die Gestaltung von Grafiken, die Seitengestaltung und das Publishing beantwortet. Auch hierfür gebührt mein herzlichster Dank. Durch Frau Glaunsinger und Herrn Engesser vom Springer-Verlag habe ich eine hervorragende Betreuung erhalten und eine äußerst angenehme Zusammenarbeit erfahren. Ein ganz besonderer Dank gebührt ihnen auch

XII

Vorwort

dafür, dass sie meine Performanceengpässe und die daraus resultierenden Terminverschiebungen so geduldig mitgetragen und mich in Zeiten der Frustration immer wieder aufgemuntert haben. Das Verfassen des Buches war ein äußerst anstrengender Marathonlauf. Als mir noch auf dem letzten Kilometer die Achillessehne riss, hat mir meine Schwester Inge geholfen, auf einem Bein humpelnd die Ziellinie zu überqueren. Ich bin ihr dafür über alle Maßen dankbar. Laura, Du hast mich mit Deinen Übersetzungshilfen bei den notwendigen Absprachen mit meinen Kollegen in den Vereinigten Staaten auf ganz praktische Weise unterstützt. Das war für mich von großer Bedeutung. Doch auch aus anderen Gründen würde es dieses Buch ohne Dich nicht geben. Ich gewinne so viel Kraft aus Deiner Kreativität, Deinem intelligenten Humor und Deiner Begeisterungsfähigkeit für die wirklich wichtigen Dinge im Leben. Kerstin, siebzehn großartige Jahre mit Dir waren für mein Leben ein optimales Performancetuning. Du bist die Ghostwriterin dieses Buches.

Inhaltsverzeichnis

1

Einführung ........................................................................................1 1.2 Ein Performancemeeting..............................................................1 1.3 Das fachliche und technische Umfeld.........................................4 1.4 Performanceaspekte .....................................................................5 1.5 Neue Herausforderungen .............................................................8 1.6 Performance als interdisziplinäre Herausforderung...................10

2

Performance und Entwicklungsprozess .......................................13 2.1 Motivation..................................................................................13 2.2 Rollen und Aufgaben .................................................................14 2.2.1 Der Facharchitekt...............................................................14 2.2.2 Der IT-Architekt ................................................................15 2.2.3 Der Entwickler ...................................................................16 2.2.4 Der Systemadministrator ...................................................17 2.3 Aufbau eines Performanceteams................................................18 2.3.1 Organisationsstruktur des Performanceteams ....................19 2.3.2 Kickoff Workshop des Performanceteams ........................22 2.4 Performance- und Lasttests........................................................32 2.4.1 Der Testplan.......................................................................33 2.4.2 Testvorbereitung ................................................................35 2.4.3 Testdurchführung...............................................................40 2.4.4 Analyse und Testberichte...................................................40 2.5 Zusammenfassung......................................................................41

XIV

Inhaltsverzeichnis

3

Quantitative Methoden ..................................................................43 3.1 Motivation..................................................................................43 3.2 Ressourcen und Warteschlangen ...............................................45 3.2.1 Begriffsfestlegungen und Definitionen..............................46 3.2.2 Auslastung und das Utilization Law ..................................47 3.2.3 Das Forced Flow Law........................................................50 3.2.4 Die Queueing-Formel von Little........................................50 3.2.5 Response Time Law...........................................................51 3.3 Mean Value Analysis.................................................................53 3.3.1 Das Arrival-Theorem .........................................................55 3.3.2 Implementierung des MVA-Algorithmus..........................56 3.3.3 Anwendungsmöglichkeiten der Mean Value Analysis ......59 3.4 Zusammenfassung und Ausblick ...............................................62

4

Simulationstechniken .....................................................................65 4.1 Motivation..................................................................................65 4.1.1 Kleine Ursache – große Wirkung.......................................66 4.2 Rechnergestützte Simulationsmodelle .......................................67 4.2.1 Simulation als Alternative zu Testverfahren......................68 4.2.2 Simulation als Alternative zu analytischen Verfahren.......68 4.3 Begriffsbildung und Definitionen ..............................................69 4.3.1 Der Systembegriff..............................................................70 4.3.2 Der Modellbegriff ..............................................................70 4.3.3 Datenstrukturen..................................................................71 4.4 Diskrete Ereignissimulation.......................................................72 4.4.1 Entitäten, Ressourcen und Attribute ..................................72 4.4.2 Ereignisse, Aktivitäten und Prozesse .................................73 4.4.3 Algorithmische Grundprinzipien einer Simulation............76 4.5 Zusammenfassung......................................................................80

5

Dokumentation der Performanceanforderungen ........................83 5.1 Motivation..................................................................................83 5.2 Nicht-funktionale Anforderungen..............................................85 5.2.1 Die Dualität von Anforderungen........................................85 5.2.2 Die Bedeutung der nicht-funktionalen Anforderungen......86 5.2.3 Anforderungsdokumentation als Balanceakt .....................86 5.3 Die zentralen Performanceanforderungen .................................87 5.3.1 Mengengerüste und Volumen ............................................87 5.3.2 Antwortzeiten aus Benutzersicht .......................................89 5.3.3 Durchsatz ...........................................................................95 5.3.4 Verfügbarkeit .....................................................................95 5.3.5 Skalierbarkeit ...................................................................100 5.4 Service Level Agreements .......................................................102

Inhaltsverzeichnis

5.4.1 5.4.2

XV

Performancekontrollen etablieren....................................103 SLA und SOA ..................................................................104

6

Werkzeugunterstützte Kapazitätsplanung.................................107 6.1 Zielsetzung und Motivation .....................................................107 6.2 Die Notwendigkeit von Modellerweiterungen.........................108 6.2.1 High Performance On Demand Solutions........................109 6.3 On Demand Performance Advisor...........................................109 6.3.1 What-If-Analysen und Anwendungsmodi .......................111 6.3.2 Verfahrensweise...............................................................111 6.3.3 MVA-Erweiterungen .......................................................116 6.4 Kapazitätsplanung einer Versicherungsanwendung ................117 6.4.1 Antragserfassung und Vertragsverwaltung......................117 6.4.2 Anwendungsfälle und Lastszenarien ...............................118 6.4.3 Ressourcenbedarfsermittlung im Lasttest ........................119 6.4.4 Performanceziele..............................................................120 6.4.5 Auswertung des Modells..................................................122 6.5 Zusammenfassung und Ausblick .............................................125 6.5.1 Restriktionen....................................................................125 6.5.2 Ergänzende und alternative Werkzeuge...........................126

7

Simulation von Geschäftsprozessen ............................................129 7.1 Motivation................................................................................129 7.1.1 Modelle als Orientierungsrahmen....................................129 7.1.2 Analogien nutzen .............................................................130 7.1.3 Performanceanforderungen identifizieren........................130 7.2 Prozessmanagement und Simulation .......................................130 7.2.1 Analyse und Modellbildung.............................................131 7.2.2 Entwicklung und Deployment .........................................132 7.2.3 Prozessmonitoring............................................................132 7.3 WebSphere Business Modeler .................................................132 7.3.1 Aktivitäten........................................................................133 7.3.2 Business Items .................................................................133 7.3.3 Ressourcen und Rollen ....................................................134 7.4 Fallbeispiel Schadensmanagement ..........................................134 7.4.1 Automatisierte Belegverarbeitung ...................................135 7.4.2 Der fachliche Hintergrund ...............................................136 7.4.3 Die fachlichen Objekte ....................................................137 7.4.4 Ressourcen und Rollen ....................................................138 7.4.5 Aktivitäten, Services und Entscheidungspfade................138 7.5 Ziele der Prozessanalyse ..........................................................141

XVI

Inhaltsverzeichnis

7.6 Simulationsergebnisse..............................................................143 7.6.1 Ein Arbeitstag in der Schadensabteilung .........................144 7.6.2 What-If-Analysen ............................................................147 7.7 Zusammenfassung und Ausblick .............................................151 7.7.1 Planung von Simulationsprojekten ..................................152 8

Java Monitoring und Profiling....................................................155 8.1 Zielsetzung und Motivation .....................................................155 8.2 Die Qual der Wahl ...................................................................156 8.2.1 Projektübergreifendes Produktmanagement ....................157 8.2.2 Performancetests durch Werkzeugevaluierung................159 8.2.3 Anwendungsspezifische Messverfahren ..........................160 8.2.4 Einschränkungen und Nachteile.......................................161 8.3 Ein Java Monitor im Eigenbau ................................................163 8.3.1 Leistungsbeschreibung des Performancemonitors...........164 8.3.2 Profiling versus Monitoring.............................................166 8.3.3 Werkzeugportfolio ...........................................................168 8.3.4 Die Unterstützung durch Java..........................................168 8.4 Java Virtual Machine Profiler Interface...................................172 8.4.1 Klassifikation der JVMPI-Ereignisse...............................173 8.4.2 Ein erster prototypischer Versuch....................................175 8.4.3 Byte-Code-Instrumentierung ...........................................179 8.4.4 Byte Code Engineering Library .......................................182 8.4.5 Der Monitor im ersten Einsatz.........................................192 8.5 Neuerungen in Java 5...............................................................195 8.6 Bewertungskriterien für kommerzielle Werkzeuge .................199 8.6.1 Schlechte Antwortzeiten bei geringer Systemlast............200 8.6.2 Ressourcenbedarf der Werkzeuge....................................201 8.6.3 Ressourcenermittlung und Auslastungsprofile ................202 8.6.4 End-To-End Monitoring und Transaktionstracking.........204 8.6.5 Weitere Anforderungen ...................................................206 8.7 Zusammenfassung....................................................................207

9

Visualisierungstechniken .............................................................209 9.1 Motivation................................................................................209 9.2 Grundlegende Aspekte der Visualisierung ..............................211 9.3 Streudiagramme .......................................................................211 9.3.1 Einsatz von Mobilfunktechnologien ................................212 9.3.2 Laufzeiten eines Servlets .................................................214 9.3.3 Speicherverhalten einer J2EE-Applikation......................215 9.4 Balkendiagramme und Histogramme.......................................217 9.4.1 GPRS-Benchmarkdaten im Histogramm .........................217 9.4.2 Klasseneinteilung über Anwendungsfälle........................219

Inhaltsverzeichnis

XVII

9.5 Interaktive Visualisierungstechniken.......................................219 9.5.1 Eine Versicherungsanwendung im Internet .....................220 9.5.2 Ergebnisse des Tests ........................................................222 9.5.3 Die Analyse mit Treemaps...............................................223 9.5.4 Detailanalyse und Problemlösung....................................226 9.6 Ein Chartgenerator in Perl .......................................................227 9.6.1 Die Struktur der Rohdaten ...............................................228 9.7 Zusammenfassung....................................................................233 10

Beispielszenario Webservice........................................................235 10.1 Motivation............................................................................235 10.2 Rahmenbedingungen und Gestaltungsmöglichkeiten ..........236 10.3 Das Beispielszenario............................................................237 10.4 Aufbau der Testumgebung...................................................238 10.4.1 Der Webservice................................................................238 10.4.2 Applikationsserver und Lasttreiber..................................240 10.5 Der Single-User-Test ...........................................................242 10.6 Der Webservice als Warteschlangenmodell.........................243 10.6.1 Modellierung von Mehrfachressourcen ...........................244 10.6.2 Analytische Performanceprognose und Validierung .......245 10.7 Die Simulation eines Webservice ........................................247 10.7.1 Die Komponenten des Modells........................................247 10.8 Das Webservice-Modell in Desmo-J ...................................250 10.8.1 Die Modellklasse .............................................................250 10.8.2 Das Ereignis RequesterRequestServiceEvent ..................253 10.8.3 Das Ereignis WorkerThreadLookUpEvent......................254 10.8.4 Das Ereignis WorkerThreadFinishService.......................255 10.8.5 Ergänzende Elemente der Simulation ..............................256 10.9 Simulationsergebnisse..........................................................258 10.9.1 Häufigkeitsverteilung der Antwortzeiten.........................259 10.10 Limitierte Warteschlangen...................................................262 10.11 Zusammenfassung................................................................263

Sachverzeichnis ......................................................................................265

1

Einführung

Es gibt wenig Softwareentwicklungsprojekte, in denen die Performance nicht zu irgendeinem Zeitpunkt eine gewisse Rolle spielt. Wenn das Projektmanagement das Thema nicht schon für die ersten Design- und Entwicklungsphasen adressiert und einplant, so wird es spätestens mit der ersten Produktivschaltung auf der Tagesordnung stehen. Und das wahrscheinlich in einer für alle Beteiligten mehr oder weniger unerfreulichen Weise. Diese Erkenntnis ist nun wahrlich nicht neu und unzählige Studien und Monographien haben sich den damit einhergehenden Problemen mit unterschiedlichen Blickwinkeln und Schwerpunkten gewidmet. Performance ist das hauptsächliche Motiv für die Entwicklung des maschinellen Rechnens und damit auch immer schon ein zentrales Qualitätskriterium zur Bewertung von Anwendungen und Programmen gewesen. Seitdem jedoch die Internettechnologien ihr ursprünglich auf den akademisch-wissenschaftlichen Bereich beschränktes Einsatzgebiet erweitert haben und zu einem der wesentlichen Erfolgsfaktoren und Treiber neuer Geschäftsmodelle und -systeme geworden sind, haben sich die Rahmenbedingungen für das Management der Performance entscheidend verändert. In immer kürzer werdenden Zyklen treten neue Technologien und Paradigmen in Erscheinung und machen es für den einzelnen IT-Manager, Architekten oder Entwickler zunehmend schwierig, einen universellen Überblick zu behalten. Zwangsläufig ergibt sich ein immer feingliedrigeres Bild von Spezialthemen und Einzeldisziplinen und die Frage, wer wann was für das Erreichen der notwendigen Anwendungs- oder Systemperformance leisten muss, lässt sich immer schwieriger beantworten. Inwieweit über Jahre gefestigte Ansichten und Meinungen hierbei eine Rolle spielen, wollen wir am Beispiel des folgenden fiktiven Fallbeispiels ergründen.

1.2

Ein Performancemeeting

Wöchentliches Status-Meeting einer IT-Abteilung, Beginn 10:30 im Büro des CIO. Die Teilnehmer sind:

2

1 Einführung

• Frau Dr. Funke, Leiterin Informationstechnologie eines Versicherungsunternehmens und in dieser Funktion Mitglied der Geschäftsführung. • Herr Graf, Hauptabteilungsleiter Produktion. • Herr König, Hauptabteilungsleiter Anwendungsentwicklung. • Frau May, Abteilungsleiterin Methoden und Verfahren / IT-Strategie. Die übliche Tagesordnung ist abgearbeitet. Konfliktreiche Themen liegen zurzeit nicht vor. Der einzige offen gebliebene Punkt ist die Budgetfreigabe für eine Vorstudie zum Thema „Knowledge Management auf Basis neuer Webtechnologien“. Es ist 11:50, man möchte gemeinsam das Mittagessen einnehmen und nutzt die verbleibenden 10 Minuten bis zur Öffnung der Kantine für ein lockeres Gespräch. Frau Dr. Funke: „Gestern Nachmittag habe ich im Anschluss an die Sitzung des Lenkungsausschusses noch einen Kaffee mit Herrn Becker aus dem Bereich KFZ getrunken. Die testen zur Zeit zusammen mit unseren entsprechenden Vertragspartnern die Anwendung zum Leihwagenmanagement. Wie ich verstanden habe, läuft das ganz gut an. Es werden kaum kritische Fehler gemeldet, und wenn es mal hakt, wird in aller Regel relativ zügig ein Fix geliefert. Meine Gratulation, Herr König. Wenn das so weitergeht, scheinen wir ja seit langer Zeit mal wieder in Time und Budget zu liefern.“ Herr König: „Ja. Und was mich noch mehr freut, ist die Tatsache, dass bei den Sachbearbeitern die – ich drücke es mal vorsichtig aus – anfängliche Skepsis gegenüber dem Arbeiten mit dem Webbrowser gänzlich verschwunden ist. Und da unser Architekt seine dogmatische Ablehnung des Einsatzes von Java Applets für die Visualisierung der Statistiken aufgegeben hat, konnten nun einige Wogen geglättet werden.“ Frau Dr. Funke (lachend): „Das waren schon sehr hartleibige Diskussionen. Vielleicht kann der KFZ-Bereich hier eine Multiplikatorrolle einnehmen. Damit würden wir auf dem Weg der Anwendungskonsolidierung natürlich ein gutes Stück vorankommen. Einen kleinen Wermutstropfen habe ich aber dennoch. Herr Becker meint, einige Sachbearbeiter wären etwas unzufrieden mit den Antwortzeiten der Anwendung gewesen. Haben wir hier vielleicht irgendwo einen Engpass, Herr Graf? Herr Graf (leicht irritiert): „Ich weiß jetzt nicht, warum Sie gerade mich das fragen. Soweit ich informiert bin, wird die Testanwendung nicht auf unserer Infrastruktur betrieben. Da haben sich doch die Mitarbeiter von Herrn König und auch von Ihnen, Frau May, selbst was zusammengezimmert, wenn ich das mal so lax sagen darf.“ Herr König und Frau May (unisono): „Na, na.“

1.2 Ein Performancemeeting

3

Frau May: „Ja, an so flexible und agile Herangehensweisen werden Sie sich zukünftig noch gewöhnen müssen.“ Frau Dr. Funke: „Frau May, meine Herren, ich darf doch bitten. Mal im Ernst: haben wir dort eine Leiche im Keller? Herr Graf, Sie stecken doch dort mitten in den SLA-Verhandlungen und stehen damit auch ein wenig in der Pflicht.“ Herr Graf: „Da haben Sie natürlich Recht, Frau Dr. Funke. Der Fachbereich geht in der Endausbaustufe von einer Anzahl Anwender im unteren dreistelligen Bereich aus. Mir machen die paar Hansel mit ihrer Leihwagensteuerung auch keine Sorgen. Da hängen wir meinetwegen noch eine CPU auf die Webserver und dann bekommen wir schon die im SLADokument geforderte „flüssige und ergonomische Dialogverarbeitung“. Aber nach 30 Jahren Betriebszugehörigkeit darf ich mich wohl mit Fug und Recht als einen alten IT-Hasen bezeichnen und als solcher möchte ich doch gerne mal ein paar grundsätzliche Anmerkungen machen. Wir betreiben, wie Sie alle wissen, mit unserer Infrastruktur seit Jahren auch unter den immer enger werdenden finanziellen Möglichkeiten eine ganze Menge von unterschiedlichen Anwendungen mit teilweise beträchtlichem Transaktionsvolumen. Wenn wir gelegentlich – die Betonung liegt auf gelegentlich – mal hier und da ein Performanceproblem hatten, so haben wir das zügig und, wie ich betonen möchte, in bestem Einvernehmen mit Ihrem Vorgänger – Herr König – lösen können. Mit dem Einzug der von unseren Methodikern so sehr gefeierten JavaTechnologie scheinen wir uns aber ein Maß an Komplexität ins Haus geholt zu haben, die uns für stark frequentierte Anwendungen im Endkundenbereich noch so manche Sorgen machen wird. Da laden sich die Entwickler ohne Sinn und Verstand ein Tool nach dem anderen aus dem Internet, um ihre technische Neugier zu befriedigen, und wir können dann sehen, wie wir dieses Konglomerat verwaltet bekommen. Das macht nicht wirklich Freude. Und mit Verlaub: Sie nutzen für Ihre Anwendung u.a. die Adressverwaltung. Diese wurde in Cobol – Frau May, ich betone: in Cobol – zu einer Zeit entwickelt, als Sie noch die Schulbank gedrückt haben und man von Java höchstens in exotischen Reiseführern lesen konnte. Und da die Adressverwaltung noch nie mit unakzeptablem Antwortzeitverhalten aufgefallen ist, können wir diese ja schon mal als Ursache der Performanceprobleme ausschließen.“ (Verschränkt die Arme und lehnt sich zurück.) Frau May (zu sich selbst): „Der wird hier noch für die Wiedereinführung der Lochkarten plädieren.“ „Herr Graf, ich kann ja Ihre Sorgen bis zu einem gewissen Grad nachvollziehen. Aber sind Sie insgesamt nicht etwas zu pessimistisch?“

4

1 Einführung

Frau Dr. Funke: „Hätten Sie einen Lösungsvorschlag? Wie können wir dem Betrieb hier Unterstützung zukommen lassen?“ Frau May: „Gut, dass Sie danach fragen, Frau Dr. Funke. Ich war in der vergangenen Woche auf einer Java-Konferenz. Dort wurde Speed4J vorgestellt. Dies ist ein beeindruckender Java-Profiler. In einer Roadshow wurde eine Benchmark-Applikation zur Verschlüsselung von Daten einem Profiling unterzogen und innerhalb von 10 Minuten konnten zwei signifikant schlechte Codestellen identifiziert und optimiert werden und so die Antwortzeit um mehr als 60 % gesenkt werden. Ich habe von dem Hersteller eine zeitlich begrenzte Testlizenz erhalten. Ich schlage daher vor, die Anwendung auf einen Ihrer Unix-Server zu deployen, Herr Graf. Ihre Administratoren müssten dann Speed4J auf dem Applikationsserver installieren. Und während der Fachbereich testet, analysieren wir parallel das Performanceverhalten. Herr König, Ihr Support wäre dann natürlich beim Tuning gefragt.“ Herr König: „Kein Thema. Aber wir müssen unbedingt auch einen Netzwerker ins Boot nehmen. Wir haben zwar keine dedizierten Performancetests durchgeführt, schließlich hatten wir mit der Entwicklung der fachlichen Anforderungen nun wirklich genug zu tun. Aber letztendlich arbeiten unsere Entwickler ja ständig mit der Anwendung und von Performanceproblemen ist mir noch nichts zu Ohren gekommen. Für meinen Verantwortungsbereich habe ich da mal keine schlaflosen Nächte. Herr Graf, wären Sie im Übrigen so nett, Frau May und mir das SLA-Dokument bei Gelegenheit einmal zuzusenden? Herr Graf (friedlich schmunzelnd): Klar, geht Ihnen heute Nachmittag zu. Wie immer, Frau May, alles ganz easy und speedy. Aber ich bin dabei.“ Frau Dr. Funke: „Dann ist ja alles im grünen Bereich. Gehen wir zu Tisch, heute gibt es spanische Küche.“ Dann wollen auch wir ihnen gönnen, sich die Tapas schmecken zu lassen, für uns selbst aber einige Erkenntnisse aus der vorausgegangenen Diskussion ableiten.

1.3

Das fachliche und technische Umfeld

Einige Aussagen sind ein Beleg dafür, dass die IT-Abteilung unter zunehmend schwierigeren Rahmenbedingungen neuen Herausforderungen begegnen und selbst eine aktive Rolle in den Transformationsprozessen des Gesamtunternehmens einnehmen muss. Technologische Innovationen eröffnen ganz neue Perspektiven bei der Gestaltung von Geschäftsprozessen.

1.4 Performanceaspekte

5

Das erwähnte „Knowledge Management auf Basis neuer Webtechnologien“ ist dafür ein kleineres Beispiel. Die debattierte Anwendung zum Leihwagenmanagement, welche von zwei unterschiedlichen Unternehmen aus unterschiedlichen Branchen gemeinsam genutzt wird, deutet aber bereits umfangreichere Transformationen an. Solche mit deutlichen Umbrüchen verbundenen Prozesse vollziehen sich natürlich nicht ohne Reibungsverluste. Da von diesen in letzter Konsequenz Menschen betroffen sind, zeigen sich Ängste und Widerstände, welche sich zuweilen in Ressentiments gegenüber den ermöglichenden Technologien äußern. Herr Graf bringt seine Skepsis gegenüber jenen Technologien, welche heute die Basis von verteilten Anwendungssystemen darstellen, offen zum Ausdruck. Konsens besteht offenkundig bei der Bewertung der Rahmenbedingungen, unter denen die IT agieren muss. Herr Graf spricht von „den immer enger werdenden finanziellen Möglichkeiten“, welche ein Motiv für den von Frau Dr. Funke postulierten „Weg zur Anwendungskonsolidierung“ sein dürften. Frau May hingegen strahlt ein optimistisches Vertrauen in neue Technologien aus, welches sich nicht nur in einer hohen Begeisterungsfähigkeit für bestimmte Produkte äußert, sondern auch in der positiven Hervorhebung bestimmter SW-Entwicklungsmethodiken („flexible und agile Herangehensweisen“) manifestiert. Der Hauptabteilungsleiter der Anwendungsentwicklung nimmt insofern eine Mittlerrolle ein, als er eine positive Haltung zu neuen Technologien einnimmt, dabei aber zu Gunsten einer guten Kompromissfindung mit den Klienten bereit ist, pragmatische Entscheidungen zu treffen. Wie der Einsatz von Java Applets konkret bewertet werden muss, braucht uns an dieser Stelle nicht zu interessieren.

1.4

Performanceaspekte

Die Diskussion liefert durch das, was gesagt wird, aber auch durch das, was nicht gesagt wird, einige höchst bemerkenswerte Informationen. Verfolgen wird diese der Reihe nach: Frau Funke ist zuversichtlich, was die Einhaltung von Terminen und Budgetgrenzen für dieses Projekt angeht, während noch keine Performancetests in der Entwicklung stattgefunden haben und Herr König darin auch kein offensichtliches Problem erkennen kann. Die Aussage, die Sachbearbeiter seien „etwas unzufrieden mit den Antwortzeiten der Anwendung“ ist sehr vage.

6

1 Einführung

Besteht die Unzufriedenheit hinsichtlich der Antwortzeiten? Wenn ja, für alle oder nur Teile der Anwendung? Betrifft die Performanceeinschränkung überhaupt die direkte Interaktion mit dem System oder ist eher die Bearbeitung eines gesamten Prozesses bzw. Geschäftsvorfalles gemeint, an dem unter Umständen mehrere Personen beteiligt sein können (Prozesssteuerung und Workflow)? Überraschend ist hier weniger, dass die IT-Chefin eine sehr informelle Information weitergibt. Problematisch ist aber die Bereitschaft der Diskutanten das Thema in der Tiefe zu erörtern, ohne zuvor wirklich quantifizierte und damit belastbare Informationen zu den Performanceproblemen einzuholen. Gehen wir der Einfachheit halber von mangelnden Server-Antwortzeiten aus. Das System reagiert nach dem Verständnis des Sachbearbeiters nicht schnell genug auf Anfragen. Der Produktionsleiter sieht sich hier nicht als Ansprechpartner. Denn die Server, welche spontan für den Test bereitgestellt wurden, fallen in die Verantwortung der Anwendungsentwicklung. Frau Funke nimmt da eine etwas andere Haltung ein. Sobald die Anwendung life geht, verwendet der Anwender implizit die Infrastruktur des Betriebes. Daher hat dieser auch für die entsprechende Performance zu sorgen. Sie macht dies mit dem dezenten Hinweis auf die laufenden SLAVerhandlungen deutlich. Ihre Frage nach dem Vorliegen eines Engpasses bleibt unbeantwortet. Hier kann es auch ad hoc keine ausreichende Antwort geben, wir kommen aber im Verlauf des Buches hierauf noch zurück. Wenn Herr Graf auch eine Verteidigungshaltung einnimmt, stellt er seine eigene Rolle als alleiniger technischer Verhandlungsführer der SLA nicht in Frage. Warum haben Herr König und Frau May in ihrer Verantwortung für das Anwendungsdesign und grundsätzliche technische Strategieentscheidungen keine Aufgaben im SLA-Management? Herrn König reicht es scheinbar aus, das „SLA-Dokument einmal bei Gelegenheit zu erhalten“. Das SLA-Dokument selbst fordert eine „flüssige und ergonomische Dialogbearbeitung“ für eine Anzahl Anwender im „unteren dreistelligen“ Bereich. Bedeutet dies Dialogwechselzeiten von maximal 2 Sekunden für etwa 120 Benutzer in 80 % aller Fälle bei einer maximalen Abweichung von 3 Sekunden für die restlichen 20 %? Oder sind doch eher 1,2 Sekunden Antwortzeit für etwa 350 Anwender in 95% der Aufrufe gemeint?

1.4 Performanceaspekte

7

Dies scheint nicht so wichtig zu sein. Im Zweifelsfalle kann eine CPUAufrüstung auf den Webservern ja die unspezifisch geforderte Performance leisten. Oder ist es möglich, dass die Prozessoren der Webserver bereits jetzt völlig überdimensioniert sind und die Problemursache an einer ganz anderen Stelle zu suchen ist? Und kann tatsächlich völlig ausgeschlossen werden, dass die Verwendung der bestehenden Cobol-Adressverwaltung in der Neuanwendung ein ganz anderes Performanceverhalten zeigt als bei der klassischen Nutzung? Zum Schluss offeriert Frau May in Form eines Java Profiler und eines spontan „konzipierten“ Testverfahrens eine für alle Seiten akzeptable Lösung. Aber eine rechenintensive (Benchmark-) Software zur Verschlüsselung unterscheidet sich doch deutlich von der im Test befindlichen Leihwagenanwendung? Eventuell stellen sich dann ja auch ganz andere Anforderungen an die zu erfassenden Messdaten und somit auch an die zu verwendenden Werkzeuge. Es bleibt also eine Reihe offener Punkte und unbeantworteter Fragen: • Die Performanceanforderungen der Auftraggeber (in diesem Falle des Fachbereiches) sind nicht genau spezifiziert. • Einheitliche Methoden und Vorgehensmodelle sind nicht festgelegt. • Insbesondere sind Performanceuntersuchungen nicht Teil des Entwicklungsprozesses. • Es gibt keine klar festgelegten Verantwortlichkeiten und Rollen. • Werkzeuge zur Erhebung von Performancemessdaten werden mehr zufällig und nicht auf Basis eines Kriterienkataloges ausgewählt. Alles in allem ist das eingeschlagene Verfahren wenig zielgerichtet und reaktiv. Das schließt nicht aus, dass eine erfolgreiche Optimierung der Anwendung dennoch gelingt und mit dem von Frau May vertretenen Ansatz tatsächlich ein paar Performanceschwachstellen aufgedeckt werden. Benötigt wird aber eine umfassende Systematik, mittels derer auch unter steigenden Anforderungen an die Anwendungen, wachsenden Benutzergruppen und Ausweitung des Serviceportfolios mögliche Performanceengpässe frühzeitig identifiziert und behoben werden können, bevor diese zu ernsthaften wirtschaftlichen Schäden für das Unternehmen führen. Geeignete Werkzeuge sind dabei sicher ein bedeutender, aber garantiert nicht ausschließlicher Erfolgsfaktor. Vielmehr bedarf es auf die jeweiligen Phasen des Entwicklungsprozesses abgestimmter Performanceaktivitäten, die sich in Projekt-, Personalund Budgetplänen wiederfinden müssen und zu deren Bearbeitung zuwei-

8

1 Einführung

len auch teamübergreifende Abstimmungen sowie Einzelmaßnahmen notwendig werden. Wie für andere Teilgebiete des Software Engineering muss auch die Organisation der Performance in anwendungs- und projektübergreifende Steuerungsmechanismen eingebettet sein. Dazu gehören u.a.: • • • • •

Risikomanagement Unternehmensweite Architekturfestlegungen Budgetplanungen Ausbildungs- und Schulungspläne Vorgehensmodelle und Projektmanagement

Betriebs- und Ablauforganisation nehmen damit eine zentrale Rolle ein. Um zu unterstreichen, dass Performance eben nicht nur ein technologisches Themengebiet ist, für das Architekten, Infrastrukturspezialisten und Entwickler zuständig sind, wird in diesem Buch der Terminus Performancemanagement anstelle des geläufigeren Begriffes Performance Engineering verwendet.

1.5

Neue Herausforderungen

Seit den frühen 60er-Jahren des vergangenen Jahrhunderts wird IT intensiv zur Automatisierung oder Unterstützung von Geschäftsprozessen genutzt. Daher ist die Frage berechtigt, ob Performancemanagement im Zeitalter der Internets und der Etablierung serviceorientierter Architekturen tatsächlich einen qualitativ anderen Stellenwert einnimmt oder einnehmen muss, als das bei mehr traditionellen IT-Architekturen der Fall ist. Tatsächlich hat es schon immer Anwendungen gegeben, die aufgrund eines mangelhaften Durchsatzes oder wegen schlechter Antwortzeiten nur mit massiver Aufrüstung der Hardware oder durch aufwändige Tuningmaßnahmen in Produktion genommen werden konnten. Und schon immer wurden dadurch im Extremfall enorme betriebswirtschaftliche Schäden verursacht. Im Laufe der Zeit haben sich jedoch mit den Technologien auch die Ursachen für Performanceprobleme verändert. Der wachsenden Komplexität der fachlichen Anforderungen konnte mit den klassischen Verfahren der Softwareentwicklung, Programmiersprachen und Werkzeugen nicht mehr in angemessener Qualität und innerhalb überschaubarer Zeit- und Kostenrahmen begegnet werden. In der Konsequenz haben sich eine Reihe von Methodiken und Technologien herausgebildet, mit Hilfe derer ein gewaltiger Produktivitätsschub bei der Erstellung von Software erzielt werden

1.5 Neue Herausforderungen

9

konnte. Einige bedeutende Meilensteine auf diesem Weg waren und sind ohne Anspruch auf Vollständigkeit • die Objektorientierung mit ihren Möglichkeiten zur Modularisierung und Wiederverwendung; • die Unified Modelling Language zur standardisierten Beschreibung eines Softwaresystems; • Linux als freies Betriebssystem; • Java, wegen der Entkopplung von hardware- und plattformspezifischen Besonderheiten durch die Virtual Machine und den einfachen und einheitlichen Zugängen, die diese Sprache zu Themen wie der Netzwerkprogrammierung, des Multithreading usw. bietet. Die Java 2 Enterprise Edition erweitert dieses Portfolio um einheitliche Schnittstellen zur Transaktionsverwaltung, Ressourcenzugriffen, Sicherheit usw; • XML, unter anderem zum standardisierten Datenaustausch über das Web; • Eclipse als Softwareentwicklungsumgebung, zunehmend aber auch als Basis für grafische Anwendungssysteme (Rich Client Platform); • Webservices, als programmatische Kommunikationsschnittstelle zwischen unterschiedlichsten Systemen und als ein wesentlicher Technologietreiber der Serviceorientierung; • Open Source und Open Source Communities als Zulieferer für hochqualitative Komponenten und Frameworks. Die mit diesen Technologien einhergehende Abstraktion fördert die Entwicklung verteilter Anwendungen und bietet eine hohe Flexibilität für die Interaktion zwischen Komponenten und für die Komposition von Services zu vollständigen Anwendungssystemen. Jede Abstraktionsschicht führt aber auch zu zusätzlichem Ressourcenbedarf und die nahezu unendliche Anzahl von Möglichkeiten, die Architekten zur Kombination von Anwendungskomponenten, Systemsoftware und Infrastrukturen zur Verfügung stehen, erhöht das Risiko von versteckten Performanceproblemen. Die ursprüngliche Anwendungsentwicklung erfolgte unter Verwendung maschinennaher Programmiersprachen. Der Programmierer hatte dadurch naturgemäß die Zielplattform, auf der sein Anwendungscode ausgeführt wurde, deutlicher vor Augen. Die nachfolgenden Programmiersprachen haben zwar schon von der zugrundeliegenden Hardware abstrahiert. Dennoch ist bei klassischen Client/Server-Anwendungen dem Programmierer weitestgehend das Bewusstsein darüber erhalten geblieben, an welchen Stellen seines Codes Zugriffe auf entfernte Systeme (meistens Datenbanken) stattfinden oder nicht. Eine Trennung von Anwendungs- und Systemcode war nicht vollständig gegeben, und wenn sich das in mancherlei Hinsicht als eine Quelle von Schwierigkeiten dargestellt hat, so waren doch

10

1 Einführung

mögliche Performancerisiken eindeutiger und früher zu erkennen als das heute der Fall ist.

1.6

Performance als interdisziplinäre Herausforderung

Mit welcher Intensität ein Entwicklungsprojekt das Performancemanagement vorantreibt oder vorantreiben sollte, hängt vom Projektumfang (Anzahl der Komponenten, Anzahl der Projektmitarbeiter, eingesetzte Technologien) und der Bedeutung der durch das Projekt realisierten fachlichen Funktionen und unterstützten Geschäftsprozesse ab. Diese beiden Faktoren müssen nicht zwangsläufig miteinander korrelieren. So können manche wichtige fachliche Anforderungen gelegentlich mit relativ einfachen Technologien umgesetzt werden und umgekehrt. Vielfach wird das Thema Performance durch einen Performancearchitekten verantwortet, wobei diese Rolle mitunter auch in Personalunion durch einen IT-Architekten wahrgenommen wird, dem noch andere Aufgaben im Projekt obliegen. Ungeachtet dessen, ist Performancemanagement per se eine fortlaufende Aufgabe, zu deren Bewältigung zu bestimmten Zeiten Spezialisten für gewisse Verfahren und Technologien involviert werden müssen. Dies kann im Rahmen der Performanceanalyse, des Performancemonitoring oder auch der Performanceoptimierung und des Tunings notwendig sein. Dass diese Formen der Zusammenarbeit zur Erreichung von Teilzielen benötigt werden, ist in der Regel auch unstrittig. Schwierig gestaltet sich jedoch häufig die Entwicklung von Gesamtkonzepten und ganzheitlichen Vorgehensweisen im Sinne eines strategischen Performancemanagements. Nach Überzeugung des Autors sind die unterschiedlichen Perspektiven zur Performance, die Fach-, Anwendungs- und Systemarchitekten aufgrund ihres jeweiligen Rollenverständnisses einnehmen, hierfür die hauptsächliche Ursache. Die Abbildung 1.1 illustriert das Problem. Jeder der drei Architekten widmet seine Aufmerksamkeit zwar wichtigen und richtigen Fragestellungen – es fehlt jedoch die übergeordnete und koordinierende Sicht und das Management der vielschichtigen Abhängigkeiten zwischen den zahlreichen Einzelaspekten. Wird dieses Defizit überwunden, bestehen gute Chancen das Performancemanagement nachhaltig zu verbessern und über Projektgrenzen hinaus zu etablieren.

1.6 Performance als interdisziplinäre Herausforderung


Prozesse


Sessionverwaltung


Prozessorauslastung


Externe Services


Cachingmechanismen


Verfügbarkeit


Benutzerprofile


Einsatz EJB


Clustering


Workflow


XML Processing


Virtualisierung

Facharchitekt

Anwendungsarchitekt

11

Systemarchitekt

Abb. 1.1. Unterschiedliche Architekturrollen und Performanceperspektiven

Eine an gemeinsamen Performancezielen ausgerichtete Zusammenarbeit der drei Architekturgruppen erfordert einerseits einen adäquaten organisatorischen Gestaltungsrahmen. Sie macht andererseits den Einsatz von Methoden, Modellen und Werkzeugen notwendig, welche eine langfristige Gültigkeit haben und nicht durch die zuweilen kurzlebigen Einzeltechnologien immer wieder in Frage gestellt werden.

Literatur Cömert C, Fischer S, Fröhlich D, Lekkas P, Schmalenbach C (2004) Performance Management von Enterprise-Java-Anwendungen Teil 1, Objektspektrum 1/2004 Cömert C, Fischer S, Fröhlich D, Lekkas P, Schmalenbach C (2004) Performance Management von Enterprise-Java-Anwendungen Teil 2, Objektspektrum 2/2004

2

Performance und Entwicklungsprozess

2.1

Motivation

Die Performanceeigenschaften eines IT-Systems werden von einer Vielzahl unterschiedlichster Faktoren beeinflusst. Nur wer sich der vielfältigen und komplexen Zusammenhänge bewusst wird, hat letztendlich die Chance, die notwendigen Performancequalitäten einer vollständigen Anwendung oder auch eines einzelnen Services zu erkennen und die notwendigen Maßnahmen zu ergreifen, um diesen Qualitätsmaßstäben gerecht zu werden. So evident dieser Sachverhalt auch erscheinen mag, so muss doch konstatiert werden, dass er in der Praxis oftmals nur unzureichend berücksichtigt wird. Denn die Entwicklung und der Betrieb von Anwendungssystemen beruhen aus guten Gründen im hohen Maße auf Spezialisierung und Arbeitsteilung. Daraus resultieren höchst unterschiedliche Blickwinkel und Perspektiven der Akteure und in der Konsequenz wird bereits die Herausbildung gemeinsamer Zielvorstellungen schwierig. Und solange Fach- und IT-Architekten, Entwickler und Systemadministratoren nicht über einheitliche Vorstellungen von den Anforderungen und den daraus abzuleitenden Vorgaben an Architektur und Design verfügen, bleiben zu viele Einflussgrößen dem Zufall überlassen und die Performance wird mehr oder weniger zu einem Glücksspiel. Interdisziplinäre Arbeitsweisen sind also notwendig, um den Herausforderungen des Performancemanagements adäquat begegnen zu können. Und dies bedeutet mehr als nur den Austausch von Informationen zwischen den Vertretern der verschiedenen Disziplinen. Vielmehr müssen die unterschiedlichen Teilaspekte miteinander verzahnt und in Beziehung gesetzt werden.

14

2.2

2 Performance und Entwicklungsprozess

Rollen und Aufgaben

Bevor wir uns jedoch den Fragen widmen können, wie eine solche Interdisziplinarität erreicht werden kann und welche Themen denn überhaupt einer übergreifenden Bearbeitung bedürfen, gilt es zunächst ein Verständnis darüber zu gewinnen, welche Perspektiven auf die Performance die Vertreter der verschiedenen Rollen einnehmen. 2.2.1 Der Facharchitekt Dem Facharchitekten obliegt die Aufgabe, die Produktivität der von ihm betreuten Geschäftsbereiche zu steigern. Dazu muss er klare Vorstellungen darüber besitzen, wie mittels moderner Technologien neue Geschäftsmodelle etabliert werden können. Das momentan deutlich erkennbare Bestreben vieler Unternehmen, nach Jahren der Kostenreduktion nunmehr wieder über innovative Lösungen nachzudenken, fordert von dem Facharchitekten als Mittler zwischen Business und IT die Kenntnis darüber, wo die bestehenden Systeme zu einem Hemmnis für die Wahrnehmung potentieller Marktchancen geworden sind und durch eine serviceorientierte Neuausrichtung der Unternehmensarchitektur ergänzt oder ersetzt werden müssen. Selbstverständlich spielt dabei Performance eine bedeutende Rolle, schließlich geht es ja um die Beschleunigung von Betriebsabläufen, die Vermeidung von Leerlaufzeiten, die Erhöhung der Auslastung von Organisationen und Systemen. Allerdings abstrahieren die damit verbundenen Kenngrößen und Metriken weitestgehend von den technologischen Gegebenheiten und Rahmenbedingungen. Sie werden formuliert in der Terminologie und der Sprache des zugrundeliegenden Business. Der Facharchitekt darf seine Rolle natürlich nicht als eine technologieneutrale verstehen. Dennoch wird und kann er sich in der Regel sicher nicht sehr detailliert mit Fragen beschäftigen, welche die einzusetzende Infrastruktur und Systemkomponenten betreffen. Grundlegende technische Architekturentscheidungen müssen unter Beteiligung des Facharchitekten getroffen werden. Ohne ihn kann beispielsweise nicht festgelegt werden, ob die Anwendungsarchitektur auf Basis der J2EE-Plattform konzipiert wird, welche Funktionen als Service implementiert werden, oder ob als Benutzerschnittstelle ein Webbrowser eingesetzt wird. Denn solche Entscheidungen sind nur vordergründig rein technischer Natur; in der Regel haben sie direkte Auswirkungen auf die Fachlichkeit und müssen hinsichtlich ihrer Vor- und Nachteile, der mit ihnen verbundenen Kosten, möglicher Implikationen für das Gesamtunternehmen usw. bewertet werden.

2.2 Rollen und Aufgaben

15

Nachdem jedoch die wichtigsten technischen Grundsatzentscheidungen getroffen wurden, steht der Rahmen fest, innerhalb dessen die nötigen Feinspezifikationen erfolgen müssen. Konkrete technologische Festlegungen sind nun von den IT-Architekten zu leisten. Die Entwicklung von Kriterien, anhand derer z.B. die Auswahl eines Persistenzframeworks erfolgt oder die Protokolle bestimmt werden, über die ein Service aufzurufen ist, erfordern ein technisches Spezialwissen, über das der Facharchitekt nicht verfügt. 2.2.2 Der IT-Architekt Der IT-Architekt nimmt in gewisser Weise eine Vermittlerrolle zwischen den Vertretern der Fachbereiche und den Facharchitekten auf der einen Seite sowie den Entwicklern und Systemadministratoren auf der anderen Seite ein. Die von ihm erstellten Artefakte bilden die Brücke zwischen den fachlichen Anforderungen und deren technischer Realisierung. Die technische Architektur beschreibt das zu erstellende oder zu erweiternde System noch relativ grob und muss von vielen Details abstrahieren. Denn schließlich erfüllen die Architekturdokumente eine ganze Reihe sehr unterschiedlicher Zwecke und müssen zum Teil auch von Personen zur Entscheidungsfindung herangezogen werden, die nicht über technisches Spezialwissen verfügen. Software-Architekturen bewegen sich ja in den seltensten Fällen auf einem absolut sicheren Terrain. Gerade in den frühen Konzeptions- und Designphasen treten häufig Unwägbarkeiten auf und es müssen Entscheidungen unter Unsicherheit getroffen werden. In diesem Sinne gehört das Risikomanagement zum Aufgabenbereich des IT-Architekten. Er liefert die Entscheidungsgrundlagen und muss diese so aufbereiten, dass sie von den Entscheidungsträgern (Projektleitern, Auftraggebern, Managern) verstanden und beurteilt werden können. Andererseits erwarten die Entwickler von dem IT-Architekten konkrete Vorgaben und einen klaren Gestaltungsrahmen, innerhalb dessen sie die technische Realisierung einer Anwendung vorantreiben können. Zuweilen nimmt ein Architekt auch Entwicklertätigkeiten wahr. Dies ist z.B. häufig bei der Erstellung von Frameworks der Fall. Eine gute IT-Architektur muss daher so allgemein sein, dass Spielräume für Neuerungen bleiben, Unvorhergesehenes berücksichtigt werden kann und auf Managementebene verstanden wird, und dabei gleichzeitig eine Bestimmtheit aufweisen, die einen Wildwuchs auf der Entwicklungsseite vermeidet.

16

2 Performance und Entwicklungsprozess

Das richtige Maß zwischen der Abstraktion und dem Konkreten zu finden ist besonders schwer in Bezug auf die nichtfunktionalen Anforderungen (siehe Kapitel 5) im Allgemeinen und die Performance im Besonderen. Denn Performanceeigenschaften sind sehr sensitiv gegenüber Änderungen an Teilen einer Architektur und an Komponenten des Systems. Lässt die Architektur zu viele Freiheitsgrade, können Entscheidungen, die von den Entwicklern autark getroffen werden, zu erheblichen und variantenreichen Performanceproblemen führen, die jeweils individueller Lösungen bedürfen. Gibt der IT-Architekt hingegen bereits in den frühen Phasen sehr enge Rahmenbedingungen vor, so fehlt unter Umständen später der Freiraum für Optimierungs- und Tuningmaßnahmen, und Performanceprobleme können – wenn überhaupt – nur durch ein aufwendiges Redesign behoben werden. 2.2.3 Der Entwickler Um den Einfluss zu beschreiben, den ein Entwickler auf die Performance eines Anwendungssystems haben kann, ist es zunächst notwendig, seine Rolle näher zu beschreiben und abzugrenzen. Denn es gibt ja nicht eine Berufsbezeichnung, die klar das Tätigkeitsprofil eines Entwicklers beschreibt. Ähnliches gilt zwar auch für den IT-Architekten, aber dessen Aufgabengebiete sind Gegenstand intensiver Forschung und umfangreicher Literatur, während der Entwickler vergleichsweise wenig Aufmerksamkeit erfährt. Das Spektrum der Entwickler ist heute sehr breit gefächert. Mit Entwickler werden einerseits Mitarbeiter bezeichnet, die nach einer kurzen Ausbildung in einem Spezialgebiet (z.B. Datenbankentwicklung für ein ganz bestimmtes Datenbanksystem) Teile von Anwendungen betreuen, deren fachlichen Hintergrund sie kaum kennen und die sie auch technisch nicht im Gesamtkontext einordnen können. Demgegenüber steht der Entwickler, dem seine Aufgaben mehr Passion und Berufung denn Beruf sind. Solche Entwickler haben in der Regel eine langjährige solide technische Ausbildung genossen und verfügen oftmals über einen Hochschulabschluss im natur- oder ingenieurwissenschaftlichen Bereich. Sie verfügen dadurch über eine ausgeprägte Fähigkeit zur Abstraktion und Verallgemeinerung. Damit lassen sie sich ungern auf einen eng begrenzten Aufgabenbereich reduzieren und suchen nach ständig neuen Herausforderungen, in denen sie ihr kreatives Potential ausleben können. Nach Überzeugung des Autors sind ein zu eingeengter Blick und eine zu hohe Spezialisierung eine wesentliche Ursache für Performanceprobleme. Der zunehmenden Komplexität von Architekturen und Technologien wird man auch auf der Entwicklungsseite zukünftig nur durch ein Mindestmaß an Universalität und Ganzheitlichkeit begegnen können. Aus die-

2.2 Rollen und Aufgaben

17

sem Grund liegt den nachfolgenden Betrachtungen auch der zuletzt beschriebene, schöpferische Entwickler zugrunde. Durch sein hohes Technologieverständnis kann der Entwickler eine wichtige Stütze des IT-Architekten bei der Identifikation von potentiellen Performanceproblemen und deren Vermeidung sein. Durch die hohe Arbeitsteilung bei der Implementierung kann der einzelne Entwickler unmittelbar natürlich nur die Komponenten und Module beeinflussen, zu denen er Programmcode beisteuert. Damit seine Kenntnisse, die er in früheren Projekten oder durch aktive Teilnahme an Open-SourceProjekten u. dgl. gewonnen hat, als Synergien im Performancemanagement genutzt werden können, muss ihm die Bedeutung der Performance bewusst gemacht und er in diesbezügliche planerische Aktivitäten involviert werden. Die Neugier von Entwicklern ist in erster Linie natürlich zu begrüßen, weil sie ein Nährboden für innovative Ideen und den Projektfortschritt sein kann. Dazu bedarf es aber entsprechender Steuerungsmechanismen und einer engen Abstimmung zwischen Architekten und Entwicklerteams. Ohne diese werden die Entwickler ihren intellektuellen Durst unkontrolliert stillen und damit unter Umständen sogar die Performance gefährden. 2.2.4 Der Systemadministrator Die letzte hier beschriebene Rolle ist die des Systemadministrators. Moderne Anwendungssysteme und Infrastrukturen fordern von den Systemadministratoren einen hohen Einsatz und um ihre vielfältigen Aufgaben muss man sie nicht immer beneiden. Betrachtet man den Entwicklungsprozess in seinen einzelnen Phasen, so stehen zu Beginn die fachlich motivierten Anforderungen, die in der Folge durch die Facharchitektur konzeptionell untermauert werden und alsdann in einer technischen Architektur ihren Niederschlag finden. Im Anschluss wird die Anwendung aus bereits bestehenden Services assembliert und durch neu zu implementierende Komponenten ergänzt. Häufig sind die Administratoren auch nicht in die Planung und Vorbereitung von Last- und Performancetests eingebunden, sondern unterstützen erst bei der Testdurchführung. Nach der produktiven Einführung einer Anwendung sind es aber gerade die Mitarbeiter des operativen Betriebes, von denen die unverzügliche Behebung von Fehlern und Störungen erwartet wird. Auch wenn die Systemadministratoren formal nicht die ersten Ansprechpartner für die Benutzer der Systeme sind, so laufen doch bei ihnen die meisten Informationen auf. Dadurch, dass die Geschäftslogik von serviceorientierten Applikationen durch Software auf den Applikationsservern realisiert wird, können Problemursachen nur hier identifiziert werden. Dies gilt natürlich

18

2 Performance und Entwicklungsprozess

auch und gerade für Probleme, die im Zusammenhang mit einer mangelhaften Performance stehen. Damit die Administratoren hier eine angemessene Unterstützung leisten können, reichen aber die Kenntnisse der eingesetzten Systemsoftware, der Datenbank- und Applikationsserver ebenso wenig aus wie die Beobachtung der Auslastung einzelner Server oder Netzwerke. Vielmehr müssen die Systemadministratoren die Architektur in Grundzügen kennen. Welche Komponenten miteinander kommunizieren und auf Basis welcher Protokolle diese Kommunikationen stattfinden, sind wichtige Informationen um das Verhalten eines IT-Systems im normalen Betrieb und erst recht bei auftretenden Störungen zu verstehen.

2.3

Aufbau eines Performanceteams

Wir haben nun einige wichtige Gruppen im Entwicklungsprozess kennen gelernt und gesehen, dass diese ganz unterschiedliche Sichten und Einflüsse auf die Performance haben. Damit die Aktivitäten, die von den Vertretern dieser Gruppen im Rahmen des Performancemanagements durchgeführt werden, gut miteinander harmonieren, bedarf es entsprechender Koordination und eines organisierten Zusammenspiels. Eine Möglichkeit, das zu erreichen, besteht im Aufbau eines Performanceteams, welches sich aus Vertretern der beschriebenen Rollen zusammensetzt. Manche Unternehmen haben in ihrer IT-Abteilung eine Organisationseinheit etabliert, die in allen Entwicklungsprojekten die Hoheit über das Performancemanagement hat. Dann existieren in der Regel auch Konzepte, Methoden und Verfahren, die von den technischen Projektmitarbeitern und allen voran den IT-Architekten genutzt werden können und müssen. Je gründlicher durch eine solche Einheit Standards ausgearbeitet werden, desto leichter lassen sich wichtige und unverzichtbare Architekturfestlegungen treffen. Insbesondere das Anforderungsmanagement und die Festlegungen von Qualitätsmetriken profitieren von allgemein gültigen Vorlagen, von einer gemeinsam zwischen Fach- und IT-Vertretern abgestimmten Begrifflichkeit und bereits eingespielten Verfahren. Häufiger jedoch ist Performance ein Thema, dass je nach Bedarf in jedem Projekt erneut adressiert wird. Und ist der Umfang solcher Projekte (Teamgrößen, Anzahl der zu entwickelnden Services) überschaubar, so wird das Thema Performance nicht durch eine eigenständige Projektrolle bearbeitet, sondern von einem IT-Architekten und Spezialisten in Personalunion betreut. Das ist durchaus legitim. Doch auch in solchen Fällen macht ein Team Sinn, in dem motivierte und für Performanceaspekte sensibilisierte Mitarbeiter wirken und das Projekt von der Konzeptionsphase bis zum Betrieb begleiten.

2.3 Aufbau eines Performanceteams

19

Das vorrangige Ziel dieses Teams besteht darin, über den gesamten Projektzeitraum und über Organisationsgrenzen hinweg eine einheitliche Sicht auf die performancerelevanten Fragen zu gewährleisten. Mögliche Risiken und Lösungsansätze sollten gemeinschaftlich von Fach- und ITMitarbeitern getragen werden. Welcher zeitliche und damit auch finanzielle Aufwand bei der Wahrnehmung der Teamaufgaben anfällt, hängt von zahlreichen Faktoren ab. Durch eine klare Organisationsstruktur werden die Aufwände jedoch vernünftig planbar und das Risiko unbeabsichtigter Kosten für Eskalationsfälle und zu spät entdeckte Performanceprobleme wird deutlich reduziert. 2.3.1 Organisationsstruktur des Performanceteams Performancearchitekt

Das Performanceteam wird nach außen durch einen Performancearchitekten vertreten. Dieser muss über entsprechende technische Fertigkeiten verfügen. Hierzu gehören: • Sehr gute Kenntnisse der zugrundeliegenden Basistechnologien. Bezogen auf Java umfasst das die wichtigsten J2EE-Komponenten, die üblichen Protokolle, mit denen Komponenten über Prozess- und Rechnergrenzen hinweg miteinander kommunizieren (HTTP, RMI, CORBA), und die im Einsatz befindlichen oder geplanten Applikationsserver sowie die gängigen Bibliotheken und Frameworks der Open Source Community. • Beherrschung mindestens einer höheren Programmiersprache (idealerweise Java). Um Berichte eigenständig erfassen zu können, ist die Kenntnis einer Skriptsprache sehr hilfreich (siehe hierzu auch Kap. 9.6). • Basiswissen zu statistischen Verfahren, wie sie etwa in mathematischen Vorlesungen im Grundstudium der Informatik oder auch in MathematikLeistungskursen an Gymnasien vermittelt werden. Quantitative Methoden, wie sie in Kapitel 3 vorgestellt werden, sind eine äußerst hilfreiche Ergänzung. • Grundkenntnisse von Serverinfrastrukturen, Virtualisierungskonzepten und Betriebssystemen. • Intensive Erfahrungen mit mindestens einem Werkzeug zur Lastgenerierung.

20

2 Performance und Entwicklungsprozess

Mindestens ebenso wichtig wie das technische Know-how sind kommunikative Fähigkeiten, denn schließlich muss der Performancearchitekt nicht nur innerhalb des Teams wirken, sondern darüber hinaus ständigen Kontakt mit Projektleitern, Entwicklerteams und Fachvertretern pflegen. Und nicht immer wird er gute Nachrichten zu verkaufen haben. Daher sollte er über eine hohe Frustrationstoleranz und eine gewisse Konfliktfähigkeit verfügen. Connie Smith schlägt vor, dass die Rolle des Performancearchitekten am besten aus dem Entwicklungsteam und nicht aus der Reihe der Systemadministratoren rekrutiert wird (Smith u. Williams 2006). Sie begründet das mit der Neigung der Entwicklungsmannschaften, die Meilensteintermine höher zu priorisieren als die Vermeidung von Performanceproblemen und den mit diesen einhergehenden hohen Betriebskosten. Indem Entwicklungsleiter oder IT-Architekten dergestalt eine organisatorische Verantwortung für die Performance übernehmen, könne diesem Phänomen entgegengewirkt werden. Kapazitätsplanern fehlt es nach Ansicht von Smith zu häufig an Vertrautheit mit Softwarearchitekturen, als dass sie die Leitung eines solchen Teams übernehmen könnten. Fachvertreter

Betrachtet man die Performance als eine qualitative Eigenschaft des Anwendungssystems, so ist diese nie absolut. Vielmehr kann die Güte der Performance immer nur in Relation zu definierten Anforderungen ermessen werden. Und diese Anforderungen müssen entweder direkt fachlich motiviert sein oder – wenn sie bereits technisch formuliert sind – aus einem fachlichen Bedarf ableitbar sein. Anforderungen, die einem technischen Selbstzweck dienen, machen keinen Sinn. Ein Interessenvertreter der Fachbereiche und Fachabteilungen muss daher im Team mitwirken. Interessensvertreter ist hier wörtlich zu verstehen. Die Fachbereiche und Auftraggeber müssen ihre Anliegen im Performanceteam gut aufgehoben und vertreten wissen. Im Verlauf des Entwicklungsprozesses werden sich die Performanceaktivitäten zunehmend technologisch ausrichten. Treten Zielkonflikte zwischen den Anforderungen und der unter den zeitlichen und finanziellen Rahmenbedingungen technisch erreichbaren Performance auf, so ist es unabdingbar, dass der Fachvertreter sich selbst ein möglichst objektives Bild von der Schwere des Konfliktes machen kann. Seine Schlussfolgerungen, Ansichten und Positionen muss er selbstbewusst und ohne schlechtes Gewissen sowohl gegenüber den von ihm repräsentierten Fachbereichen als auch gegenüber der IT einnehmen können. Die Objektivität setzt ein gutes

2.3 Aufbau eines Performanceteams

21

Verständnis technischer Zusammenhänge voraus. Über eine entsprechende Expertise verfügt in erster Linie der Facharchitekt. Anwendungsarchitekten und Entwickler

Nimmt der IT-Architekt nicht ohnehin auch die Rolle des Performancearchitekten ein, so muss er zwingend im Performanceteam mitarbeiten. Er trägt die Verantwortung dafür, dass die Architektur den fachlichen Anforderungen genügt. Dieser schweren Aufgabe kann er nur gerecht werden, wenn er an zentraler Stelle an allen performancerelevanten Fragestellungen und Entscheidungen aktiv beteiligt ist. Seine Teilnahme ist also Pflicht und Recht zugleich. Ein Architekt, der die technischen Gegebenheiten nur aus der Vogelperspektive betrachtet, wird kein gutes Gefühl für mögliche Performancerisiken gewinnen. Es ist daher zwingend notwendig, dass er sich immer wieder mit der Realisierung und auch den kodierungsnahen Aspekten auseinandersetzt. Allein aus zeitlichen Gründen wird er aber nicht alle technischen Details wahrnehmen und beherrschen können. Wie bereits erwähnt sind Entwickler in dieser Hinsicht häufig besser positioniert. Aufgrund ihres Tätigkeitsprofils können sie technologische Entwicklungen wesentlich intensiver verfolgen und daraus potentiell resultierende Chancen besser beurteilen. Es empfiehlt sich daher, neben dem IT-Architekten auch einen Entwickler mit überdurchschnittlichen Fähigkeiten in das Performanceteam zu integrieren. Systemadministratoren

In welcher Weise Unternehmensanwendungen betrieblich organisiert werden, ist den Fachabteilungen, aber auch den mit der Softwareentwicklung betrauten Technikern häufig allenfalls oberflächlich bekannt. Aus Gesichtspunkten der Performance ist vor allen Dingen von Interesse, mit welchen anderen Anwendungen die zu entwickelnde Applikation um Ressourcen konkurrieren muss. In einer serviceorientierten Landschaft sind es ja auch nicht mehr nur die Prozessoren, Festplatten und Netzwerke, die von unterschiedlichen Anwendungen gemeinsam verwendet werden. Auch die Services selbst können und sollen für sehr unterschiedliche Anwendungsszenarien und in verschiedenen Kontexten (wieder-)verwendet werden. Hier haben die Mitarbeiter des Rechenzentrums einen guten Überblick. Allein schon deswegen kann auf ihre Mitarbeit im Performanceteam nicht verzichtet werden. Umgekehrt bietet das Team hervorragende Möglichkeiten, um den Systemadministratoren einen Einblick in die grundlegenden Eigenschaften der Architektur zu vermitteln.

22

2 Performance und Entwicklungsprozess

Ergänzende Betrachtungen

Mit jeweils ein bis zwei Vertretern aus Fachlichkeit, Softwareentwicklung und Betrieb besteht das Kernteam aus 4–7 Mitarbeitern und ist damit groß genug um den Performanceherausforderungen begegnen zu können. Eine deutlich höhere Anzahl von ständigen Mitarbeitern empfiehlt sich nicht, da ansonsten die nötige Flexibilität verloren geht. Die Vorbereitung, Durchführung und Nachbereitung von Performancetests wird eine der hauptsächlichen Aufgaben des Teams sein. Fehlt es den genannten Teilnehmern an Erfahrung auf diesem Gebiet, empfiehlt sich die zeitweilige oder dauerhafte Erweiterung des Teams um einen Testspezialisten. Mit der Zeit wird das Team eine Reihe konzeptioneller und planerischer Aufgaben erledigt haben. Mit Beginn der Testphase stehen dann sehr praktische Aktivitäten an, die von dem Team alleine nicht mehr geleistet werden können, sondern der Unterstützung von Spezialisten bedürfen. Diese sind dann zeitlich begrenzt und situationsabhängig in die Arbeiten des Teams zu involvieren. Neben der Teamaufteilung, welche die grobe Organisation eines Projektes widerspiegelt, ist unbedingt darauf zu achten, dass das Unternehmen sich insgesamt in dem Performanceteam vertreten sieht. Es mag zwar erfreulich sein, wenn das Team in fast allen Fragen einen Konsens erzielt und in Harmonie miteinander arbeitet. Aber es ist nicht unkritisch, wenn alle Teammitglieder auf der Gehaltsliste externer Beratungsunternehmen stehen. Denn auch wenn dies nicht beabsichtigt ist, kann der unterschwellige Verdacht aufkommen, dass die Interessen des beauftragenden Unternehmens nicht angemessen berücksichtigt werden. Aufgrund der Bedeutung der fachlichen Anforderungen sollte unbedingt ein dem Unternehmen angehörender Fachvertreter im Performanceteam mitwirken. 2.3.2 Kickoff-Workshop des Performanceteams Das Performanceteam konstituiert seine zukünftige Arbeit sinnvollerweise in einem Workshop zu Beginn des Projektes. Dieser Workshop dient einem ersten Erfahrungsaustausch und der groben Planung der von dem Team im Verlauf des Projektes durchzuführenden Aktivitäten. Auch für die Gestaltung des Workshops bilden die fachlichen Anforderungen die entscheidende Grundlage. Wie genau ein solcher Workshop zu organisieren ist, hängt von vielerlei Faktoren ab. Sind die Teilnehmer untereinander bekannt und ist ihnen der fachliche Hintergrund wenigstens in den Grundprinzipien geläufig, wird der Workshop sich relativ zügig dem Kernthema Performance widmen können. Handelt es sich bei einigen Teilnehmern jedoch um technische Spezialisten, die in dem Entwicklungsprojekt erstma-

2.3 Aufbau eines Performanceteams

23

lig mit den branchenspezifischen Fragen in Berührung kommen, wird man einige einführende Materialien über die zugrundeliegenden Geschäftsziele vorstellen. Ungeachtet der konkreten Workshopgestaltung kann die Agenda an folgenden Themen ausgerichtet werden: 1. Vorstellung der Teilnehmer und Einführung 2. Der geschäftliche Hintergrund und die Performanceerwartungen 3. Anwendungsarchitektur und Rahmenbedingungen 4. Anforderungen und Dienstleistungen des Betriebes 5. Identifikation von Risiken / Risikobewertung 6. Festlegung der nächsten Aktivitäten Vorstellung und Einführung

Die Vorstellungsrunde dient wie üblich dazu, die Teammitglieder einander bekannt und vertraut zu machen. Darüber hinaus sollte jeder Teilnehmer kurz erläutern, welche Beziehung er zum Thema Performance hat, worin er seine Arbeitsschwerpunkte sieht und welche Erwartungen er an die anderen Teilnehmer stellt. Möglicherweise werden dabei bereits Schwachpunkte bestehender Verfahren deutlich und es zeichnen sich erste Alternativen für Vorgehensweisen ab, die bisher als unumstößlich gegolten haben. Der geschäftliche Hintergrund

Möglicherweise hat bereits eine Kickoffveranstaltung des Gesamtprojektes stattgefunden und es wurden dort die Ziele erläutert, die das Unternehmen mit dem Projekt verfolgt. Mit besonderem Augenmerk auf die Performancebelange kann der Fachvertreter nun diese Ziele konkretisieren. Den Teilnehmern soll bewusst werden, welche geschäftlichen Motive für die Projektdurchführung ausschlaggebend sind. Die Präsentation sollte Antworten zu den folgenden Fragen liefern: • Warum werden die bestehenden Systeme den fachlichen Anforderungen nicht mehr gerecht? Gibt es neue Geschäftsmodelle, die mit den Altsystemen technologisch nicht mehr umgesetzt werden können? Die Nutzung des Internets als Vertriebskanal könnte ein solches Motiv sein. Oder genügen die bestehenden Anwendungen zwar noch den Ansprüchen der Benutzer, sind aber aufgrund von Wartungs- und Betriebskosten nicht mehr konkurrenzfähig?

24

2 Performance und Entwicklungsprozess

Wenn Anwendungen hauptsächlich aus Kostenerwägungen abgelöst werden, so kann unter Umständen die ersetzende Applikation für den Endbenutzer mit Performanceeinschränkungen verbunden sein. Auch wenn die Vorteile für das Gesamtunternehmen überwiegen mögen, besteht dann ein potentieller Konfliktfall. • Wie positioniert sich das Unternehmen mit der Anwendung am Markt? Nimmt das Unternehmen die Funktion eines „early adaptors“ ein? Oder haben andere Unternehmen bereits sehr ähnliche Systeme im Einsatz? Im ersten Fall sind potentielle Chancen, aber auch die einhergehenden Risiken naturgemäß höher als im zweiten. Dies gilt besonders dann, wenn nicht nur auf fachlicher Seite, sondern auch mit der benötigten ITTechnologie völliges Neuland betreten wird. Der Einsatz neuer Technologien ist in den meisten Fällen mit einem erhöhten Performancerisiko verbunden. Flankierende Maßnahmen (Benchmarks, Prototypen) sind dann eventuell zur Abschätzung des Risikos notwendig. • Wer sind die Benutzer, die zukünftig mit dem System arbeiten werden? Wie homogen ist die Benutzergruppe? Was kann über das Benutzerverhalten gesagt werden; welche Erwartungen werden von den Benutzern formuliert? Bei reinen Intranetanwendungen lassen sich viel genauere Aussagen zur Anzahl der Benutzer und deren Nutzungsverhalten treffen, als das bei Anwendungen der Fall ist, die frei über das Internet genutzt werden können. Dementsprechend unterschiedlich ist das Lastspektrum, das bei der Performancebewertung berücksichtigt werden muss. • Welche Geschäftstransaktionen müssen von dem System unterstützt werden? Welche Daten liegen diesen Transaktionen zugrunde? Die Beantwortung dieser Fragen liefert erste Erkenntnisse zu den Lasten, die von den Systemen zukünftig zu bearbeiten sind. Vielleicht sind bereits im Rahmen einer Ausschreibung oder der Erstellung eines Pflichtenheftes sehr konkrete Anforderungen an die Performance formuliert worden. Wenn das Unternehmen über breite Erfahrungen bei der Durchführung von IT-Projekten verfügt und Vorgaben an die IT durch ein ordnungsgemäßes Anforderungsmanagement erfolgen, sind die Performanceerwartungen mit hoher Wahrscheinlichkeit bereits in einem Dokument unmissverständlich quantifiziert und lassen kaum Raum für Mehrdeutigkeiten. Die Anforderungen sind dem Fachvertreter und dem IT-

2.3 Aufbau eines Performanceteams

25

Architekten dann sicher bekannt und brauchen für die anderen Teilnehmer nur noch einmal zusammengefasst zu werden. Es ist aber auch denkbar, dass sich bislang noch niemand Gedanken darüber gemacht hat, wie Performanceanforderungen vernünftig zu formulieren sind, damit sie in der Architektur, der Realisierung und dem Betrieb auch angemessen berücksichtigt werden können. Dann sind die Erwartungen vielleicht sehr oberflächlich und informell beschrieben. Dies würde bereits ein hohes Risiko bedeuten. Aus der Not kann das Team dann eine Tugend machen, indem es selbst eine Vorlage für die Performanceanforderungen erstellt und diese mit den Fachabteilungen und dem IT-Management diskutiert. Als Leitfaden kann dafür das Kapitel 5 dienen. Anwendungsarchitektur

Zu Beginn des Projektes gibt es noch keine umfangreichen Architekturdokumente, -konzepte und -vorgaben, die im Rahmen des Workshops vorgestellt werden können. Allerdings starten die Architekten auch nicht „auf der Grünen Wiese“, sondern müssen Richtlinien und Normen berücksichtigen. Zuweilen gibt es ein unternehmensweit einzusetzendes Framework, das für alle Projekte verbindlich ist, soweit keine schwerwiegenden Gründe dagegen sprechen. Aber auch projektinterne Vorgaben schränken den Spielraum der Architekten ein. Ein Teil der benötigten Services oder Geschäftsfunktionen muss gegebenenfalls mit Hilfe von Standardsoftware realisiert werden. Sicherheitsaspekte müssen sich ebenfalls in der zukünftigen Architektur niederschlagen. Diese Rahmenbedingungen haben auch Auswirkungen und Einflüsse auf die Performance und sollten deshalb im Workshop vorgestellt und diskutiert werden. Auch hier lassen sich einige Fragen formulieren, deren Beantwortung den Teilnehmern bei der Festlegung ihre Aufgaben hilft:

26

2 Performance und Entwicklungsprozess

• Welche Vorgaben sind bei der Erstellung der Anwenderschnittstelle zu berücksichtigen? Welche Voraussetzungen können an die Ausstattung der Anwender-PCs gestellt werden; welche Restriktionen sind hier zu berücksichtigen? Zur Vermeidung des administrativen Aufwandes und der Kosten für die Verteilung von Anwendungen und Softwareupdates galt bis vor kurzem der Webbrowser als adäquates Lösungskonzept. Inzwischen bieten Rich-Client-Konzepte auf Basis der Eclipse-Plattform eine Alternative. Jede Benutzeranfrage, die direkt von der Clientsoftware bearbeitet werden kann und keine Kommunikation mit dem Server erfordert, ist ein Performancegewinn. Auch wenn dies nicht das einzige Entscheidungskriterium sein kann, so müssen die Implikationen, die das Design der Anwenderschnittstelle auf die Performance hat, sorgfältig beachtet werden. • Wie gestaltet sich eine typische Benutzersitzung? Welche Implikationen ergeben sich daraus für das Sessionmanagement? Erfolgt die Kommunikation zwischen dem Endanwender und den serverseitigen Anwendungskomponenten über das statuslose HTTPProtokoll, und müssen zwischen zwei Requests Daten vorgehalten werden, die abhängig von der Benutzersitzung sind, so ist dafür ein entsprechendes Sessionkonzept zu entwerfen. Der Speicherbedarf pro Session und die Dauer einer Session sind vernünftig auszubalancieren. Da der Client dem Server das Ende der Sitzung nicht mitteilen muss, stehen technisch nur einfache Timeout-Verfahren zur Verfügung. Daher gilt das Sessionmanagement nicht zu Unrecht als eine der schwierigen Herausforderungen bei der Gestaltung einer Anwendungsarchitektur. • Welche Sicherheitsmaßnahmen sind zu beachten? Müssen sich die Benutzer authentifizieren? In welcher Granularität sind Zugriffe der Benutzer zu autorisieren? Wo besteht der Bedarf zur Verschlüsselung von Daten? Eine Anwendung, die den funktionalen Anforderungen genügt, aber erhebliche Sicherheitslücken aufweist, hat kaum eine Chance abgenommen zu werden. Doch jede nachträglich eingeführte Maßnahme zur Verbesserung der Sicherheit kann zu dramatischen Einbrüchen der Performance führen. Hier muss also darauf geachtet werden, dass der „Teufel nicht mit dem Beelzebub ausgetrieben wird“.

2.3 Aufbau eines Performanceteams

27

• Wie hoch ist der Bedarf an Transaktionssicherheit? Wo werden mehrere Ressourcen wie Datenbanken in einer Transaktion genutzt und erfordern daher den Einsatz eines Transaktionsmonitors? Je geringer die Anforderungen für technische Transaktionen sind, desto einfacher lässt sich die Architektur gestalten. Möglicherweise kann dann auf komplexe J2EE-Konzepte wie Enterprise Java Beans verzichtet werden. Damit vereinfacht sich auch das Performancemanagement. • Zu welchen externen Anwendungen und Systemen müssen Schnittstellen bereitgestellt werden? Auf Basis welcher Protokolle können diese Schnittstellen realisiert werden? Bereits existierende Anwendungen und Services haben Performanceeigenschaften, die nicht ohne weiteres durch die Architektur beeinflusst werden können. Anforderungen, die im direkten Widerspruch zu diesen Performanceeigenschaften stehen, müssen diskutiert und neu bewertet werden. Anforderungen und Dienstleistungen des Betriebs

Wie die alltägliche Arbeit in einem Rechenzentrum aussieht, ist den Sachbearbeitern in den Fachabteilungen normalerweise nicht bekannt. Doch auch die Entwickler und IT-Architekten wissen meistens relativ wenig über die Verfahren, mit denen die Systemadministratoren ihre Arbeit organisieren. Umgekehrt sind die von der Entwicklung ausgelieferten Komponenten für die Administratoren im Betrieb unterschiedslose Einheiten, für deren Innenleben sie sich nicht weiter interessieren. Damit fehlt aber eine ganzheitliche Sicht, die für ein erfolgversprechendes Performancemanagement unabdingbar ist. Wie soll der Administrator die Anzahl der zur Verarbeitung von Anfragen an einen Webservice erforderlichen Threads sinnvoll festlegen, wenn ihm jede Kenntnis darüber fehlt, welche Dienste dieser Webservice anbietet und mit welchem Zeitbedarf dabei zu rechnen ist? Für die Teilnehmer des Workshops sind folgende Gesichtspunkte von Interesse: • Welche Anwendungen werden produktiv genutzt? Wie ist deren Performanceverhalten? Wie hoch ist der Ressourcenbedarf? • Welche Werkzeuge setzt der Betrieb ein, um auftretende Performanceprobleme schnell identifizieren zu können? Welche Maßnahmen werden bei solchen Problemen eingeleitet?

28

2 Performance und Entwicklungsprozess

• Welche Daten werden protokolliert, die für die Analyse des Performanceverhaltens verwendet werden könnten? Kann eine Benutzeranfrage nahtlos vom Webserver bis zu den Datenbanken verfolgt werden? Können die Zeiten, in denen eine Benutzeranfrage auf den verschiedenen Servern bearbeitet wird, detailliert protokolliert werden, so ist dies von unschätzbarem Wert. Eine schnelle Problemeingrenzung ist so möglich, falls die Antwortzeiten über das geforderte Maß hinausgehen. • Welche Anforderungen stellt der Betrieb an die Verfahren zum Protokollieren von Fehlern und Ausnahmebedingungen? Wie können sie die Anwendungen bei der Identifikation von Problemursachen unterstützen? Identifikation von Risiken / Risikobewertung

Wenn es in diesem ersten Kickoff gelingt, die verschiedenen Sichtweisen auf das Thema Performance transparent zu machen und trotz der unterschiedlichen Perspektiven ein gemeinsames Verständnis über die wichtigsten Aufgaben zu erzielen, ist bereit sehr viel gewonnen. Darüber hinaus decken die Diskussionen vielleicht aber auch schon einige Widersprüche in den Anforderungen oder sonstige Risiken auf, die es zu bewerten und gegebenenfalls an das Management zu adressieren gilt. Es empfiehlt sich prinzipiell die Erstellung einer Offenen-Punkte-Liste, in der solche Risiken dokumentiert werden können. Hier einige Beispiele möglicher Risiken, die sich schon zu Projektbeginn abzeichnen können: • Die geforderten Antwortzeiten können nicht in allen Anwendungsfällen erreicht werden, da zu deren Realisierung Zugriffe auf Legacy-Systeme erforderlich sind, die für sich genommen schon nachweislich höhere Bearbeitungszeiten haben. • Die Sicherheitsrichtlinien schreiben vor, dass zukünftig zwischen den verschiedenen Applikationsservern ausgetauschte Daten mit dem SSLVerfahren verschlüsselt werden müssen. Dies ist in den Kapazitätsplanungen bislang nicht berücksichtigt worden. Es werden Performanceeinbußen erwartet. • Im Projektplan sind keine Aktivitäten für die Analyse der Performanceund Lasttestergebnisse vorgesehen. Weiterhin fehlen Reserven für Tuning- und Optimierungsmaßnahmen. • Der Betrieb verfügt zurzeit nicht über die Werkzeuge zur Kontrolle von Service-Level-Vereinbarungen.

2.3 Aufbau eines Performanceteams

29

Festlegung der nächsten Aktivitäten

Das Performanceteam wird regelmäßige Besprechungen mit dem Ziel durchführen, den Projektstatus im Hinblick auf performancerelevante Fragen zu erörtern. Das Team sollte sich als beratendes Gremium verstehen und sich eigenständig organisieren. Neben der Identifikation von Performancerisiken und potentiellen Gefahren muss das Team auch Lösungsvorschläge unterbreiten und nach Kosten- und Nutzenaspekten bewerten. Nur so wird die Arbeit des Teams im Management die notwendige Anerkennung und Unterstützung finden. Welchen Umfang die Arbeiten des Teams annehmen und wie hoch der zeitliche und finanzielle Aufwand ist, hängt natürlich von der Art des Projektes und vielen weiteren Faktoren ab. Im einfachsten Falle handelt es sich um ein Entwicklungsprojekt, das bisherigen Projekten in Bezug auf die eingesetzten Methodiken, Technologien und Anforderungen ähnelt. Dann sind die möglichen Risiken überschaubar und die Arbeit des Teams beschränkt sich auf die Qualitätssicherung und Tuningmaßnahmen in Einzelfällen. Im entgegengesetzten Fall betritt das Projekt sowohl fachinhaltlich als auch in Bezug auf die Technologie Neuland. Dann ergeben sich selbstverständlich deutlich mehr Aufgaben, die nicht alle durch das Kernteam bewältigt werden können, sondern zusätzlicher Unterstützung bedürfen. Wenn im Rahmen des Projektes das Performancemanagement erstmalig systematisch betrieben wird, benötigt das Team auch mehr Zeit für die interne Organisation, für den Aufbau eines konzeptionellen Unterbaus und für die Festlegung von Standards. Zukünftige Projekte werden davon profitieren. Die damit verbundenen Kosten dürfen jedoch nicht übersehen werden und die Unterstützung durch das Management ist unabdingbar. Die nachfolgend beschriebenen Aufgaben sind unabhängig davon zu planen, ob das Team bereits in mehreren Projekten gewirkt hat und entsprechend eingespielt ist oder ob es erstmalig das Performancemanagement verantwortet.1 1. Analyse der Performanceanforderungen: Die Performanceanforderungen sind auf ihre Konsistenz und Stichhaltigkeit zu überprüfen. Als Leitlinie können hierzu die sogenannten SMART-Kriterien dienen, die häufig zur Bewertung von Anforderungen herangezogen werden (Mannion u. Keepence 1995). SMART ist ein Akronym und steht für die Eigenschaften spezifisch, messbar, erreichbar (attainable), realisierbar und nachvollziehbar (traceable).

1

Ist der Erfahrungsschatz der Teammitglieder gering, so werden die zeitlichen Aufwände für die Aktivitäten natürlich höher sein. So muss beispielsweise der sichere Umgang mit Testwerkzeugen an einem Prototyp geübt werden.

30

2 Performance und Entwicklungsprozess

Spezifisch: Sind die Anforderungen eindeutig und widerspruchsfrei formuliert, so dass sie vom Auftragnehmer verstanden werden können? – Messbar: Beziehen sich die Anforderungen auf quantifizierbare Größen und gibt es Messverfahren, mit denen die zugehörigen Performancedaten ermittelt werden können? – Erreichbar: Können die Anforderungen in der Theorie erfüllt werden und stehen nicht im Widerspruch zu physikalischen Gesetzmäßigkeiten. Die Anforderung, dass unabhängig von der Anzahl aktiver Benutzer die Antwortzeiten maximal eine Sekunde betragen dürfen, verletzt beispielsweise dieses Kriterium? – Realisierbar: Ist es möglich, den Anforderungen auch in der Praxis gerecht zu werden oder stehen sie im Widerspruch zu den Rahmenbedingungen (Zeit, Budgets, Hardware, usw.)? – Nachvollziehbar: Kann nachgewiesen werden, dass das implementierte System den Anforderungen genügt. Im Rahmen des Performancemanagements bedeutet das in erster Linie, dass die Einhaltung der Performanceanforderungen durch Testverfahren kontrolliert werden kann? 2. Performancebudgetierung: Werden die fachlichen Anforderungen den SMART-Kriterien gerecht, so müssen die Architekten dafür Sorge tragen, dass diese Anforderungen realisiert werden. In einer frühen Projektphase können die Architekten und Entwickler noch kein genaues Bild von den Implementierungsdetails haben. Die Fragen, ob und wie häufig beispielsweise XML-Daten pro Benutzersitzung bearbeitet werden müssen, wie oft Benutzerberechtigungen von einem LDAP-Server zu ermitteln sind und welche Cachingmechanismen genutzt werden können, haben in der Zukunft zwar erheblichen Einfluss auf die Performance, können aber zu diesem Zeitpunkt auch nicht annähernd beantwortet werden. Relativ früh zeichnet sich aber meistens ab, wie die grobe Schichtung der Architektur aussehen wird. Und dieses Wissen kann dazu genutzt werden, die erwarteten Antwortzeiten auf die verschiedenen Schichten aufzuteilen. Der Lösungsraum, in dem eine Realisierung der Performanceanforderungen gefunden werden muss, wird also in gewisser Weise übersichtlicher gestaltet. Dieses Vorgehen wird als Performancebudgetierung bezeichnet und ist im Prinzip recht simpel. Für jeden Server, der an der Bearbeitung einer Benutzeranfrage beteiligt ist, wird die Bearbeitungszeit limitiert. Die Summe dieser Zeitvorgaben und der für die Netzzugriffe zu veranschlagenden Latenzzeiten ist identisch mit der vorgegebenen Antwortzeit. Im ersten Schritt ist man bei der Erstellung der Zeitvorgaben auf Erfahrungswerte und Daumenregeln angewiesen. Doch mit jeder Iteration konkretisieren sich die Werte und –

2.3 Aufbau eines Performanceteams

31

eine Anpassung der Vorgaben ist möglich. Auch die Anzahl der betrachteten Schichten kann sukzessive erhöht werden. Soll für einen bestimmten Anwendungsfall im Schnitt die Antwortzeit von 2 Sekunden nicht überschritten werden, so kann eine erste Budgetierung wie in Tabelle 2.1 skizziert erfolgen. Mit der Zeit stellt sich dann vielleicht heraus, dass die veranschlagten Zeiten für den Applikationsserver über- und die für den Datenbankserver unterschätzt wurden. Das Verfahren kann nun für jede Schicht rekursiv und unabhängig verfeinert werden. Damit gewinnen die einzelnen Entwickler und Entwicklerteams eine Hoheit über „ihre“ Performancebudgets (siehe Tabelle 2.2). Tabelle 2.1. Grobe Performancebudgets auf Serverebene Schicht / Komponente Browser (Rendering, Java Script) Netzwerk Webserver Applikationsserver Datenbank

Zeitvorgabe [Millisekunden] 200 250 150 800 600

Tabelle 2.2. Verfeinerte Performancebudgetierung für den Applikationsserver Schicht / Komponente Servlet / Controller JSP Session Bean Entity Bean A Entity Bean B Aufruf eines externen Webservice

Zeitvorgabe [Millisekunden] 200 100 50 150 100 200

3. Festlegung und Implementierung von Messpunkten: Um die Einhaltung der durch die Performancebudgetierung vorgegebenen Zeitvorgaben überprüfen zu können, sind Messverfahren erforderlich. Unter Umständen kann dies mit Hilfe von Werkzeugen erfolgen. Einige Applikationsserver können z.B. so konfiguriert werden, dass sie Aufrufe von Servlet- und EJB-Methoden mit Angaben zu den Bearbeitungszeiten protokollieren. Falls dies nicht möglich ist, muss untersucht werden, ob andere Werkzeuge zur Verfügung stehen oder zu vertretbaren Kosten beschafft werden können, mit Hilfe derer die automatische Erfassung von Messdaten möglich ist. Für Anwendungs-

32

2 Performance und Entwicklungsprozess

komponenten, die in Java programmiert sind, kann der in Kapitel 8 vorgestellte Performancemonitor verwendet werden. Schließlich besteht auch noch die Möglichkeit, Messpunkte im Anwendungscode aufzunehmen. 4. Werkzeugauswahl und Betreuung: Der Bedarf an Software zum Performancemonitoring wurde bereits erwähnt. Zusätzlich werden Werkzeuge zur Lastgenerierung, zur Ermittlung des Ressourcenbedarfs und zur Erstellung von Reports benötigt. Optional kann die Beschaffung von Tools zur Performancemodellierung in Erwägung gezogen werden. Das Team hat nun die Aufgabe, eine Bestandsaufnahme der bereits eingesetzten Software2 durchzuführen und muss überprüfen, ob damit der Bedarf gedeckt ist. 5. Planung und Durchführung von Performancetests: Performancetests sind von so wesentlicher Bedeutung, dass ihnen das folgende Unterkapitel gewidmet ist.

2.4

Performance- und Lasttests

Testverfahren sind ein unverzichtbarer Bestandteil der Qualitätssicherung im Softwareentwicklungsprozess. Dies gilt nicht nur für die diversen Testverfahren, mit denen die fachliche oder technische Korrektheit des entwickelten Codes überprüft wird (Unittests, Regressionstests, Integrationstest), sondern auch für alle Tests, mit Hilfe derer die Erfüllung der nichtfunktionalen Anforderungen überprüft werden soll. Und darunter haben wiederum Performancetests eine große Bedeutung. Selbstverständlich bedeutet das Testen der Performanceeigenschaften einer Anwendung oder Komponenten mehr als nur deren Ausführung unter gleichzeitiger Erfassung einiger Metriken. Denn schließlich leiten sich die Erfolgsfaktoren von Tests ja nicht aus abstrakten Kenngrößen ab. Vielmehr müssen sich in den Testverfahren sowohl konkrete Anforderungen als auch reale Rahmenbedingungen wie Kosten und Kapazitätsgrenzen widerspiegeln. Aus diesem Grund können in Projekten mittleren oder großen Umfangs die Performancetests durchaus den Umfang eines eigenständigen Teilprojektes mit entsprechenden Leitungs- und Teamfunktionen annehmen. Doch selbst unter der Voraussetzung, dass das Performancemanagement von einem oder mehreren IT-Architekten als Nebentätigkeit wahrgenommen 2

Häufig verfügen IT-Abteilungen über lizenzierte Testwerkzeuge, ohne dass diese intensiv eingesetzt werden. Solche Software muss erneut auf ihre Zweckmäßigkeit überprüft werden.

2.4 Performance- und Lasttests

33

wird, reicht die sporadische Durchführung von Performancetests zur Gewährleistung der geforderten Qualitätsmerkmale nicht aus. Ungeachtet vom Projektumfang sollten Performancetests in vier Phasen erfolgen: 1. In der Phase der Testplanung werden die Anforderungen validiert und eine ihnen entsprechende Teststrategie festgelegt. Eine Schätzung der erforderlichen Zeit und der benötigten Mitarbeiter sind weitere Punkte des Testplans. 2. In der Phase der Testvorbereitung werden adäquate Arbeitslasten definiert, die erforderlichen Messprozeduren festgelegt und eine Testumgebung aufgesetzt. 3. Bei der Testdurchführung werden die zum Nachweis der geforderten Performanceeigenschaften benötigten Daten gesammelt. 4. Schließlich sind mit einem finalen Testbericht aus den Testergebnissen Handlungsempfehlungen für unterschiedliche Entscheidungsträger zielgruppengerecht aufzubereiten (Berichtsphase). 2.4.1 Der Testplan Im Idealfall soll nach der Durchführung des Performancetests feststehen, dass die untersuchte Anwendung oder Komponente auf der geplanten Infrastruktur den an sie gestellten Leistungsanforderungen in Bezug auf die erforderlichen Antwortzeiten und Durchsatzraten genügt. Deckt der Test hingegen grundsätzliche Performanceschwächen auf, so sollen aus den Ergebnissen die Abweichung von den Sollgrößen quantifiziert werden können und wenigstens grob Tuningmaßnahmen erkennbar sein, die in überschaubarer Zeit und zu vertretbaren Kosten eine signifikante Verbesserung der Performance versprechen. Das macht es notwendig, dass sich die beteiligten Projektmanager und Architekten planerisch mit den Anforderungen auseinandersetzen und angemessene Testziele festlegen. Validierung der Anforderungen

Ist eine komplette Fachanwendung Gegenstand des durchzuführenden Performancetests, so sind im Dokument zu den nichtfunktionalen Anforderungen (siehe Kapitel 5) die Bedingungen für ein positives Testergebnis bereits formuliert. In anderen Fällen sind die den Test bestimmenden Anforderungen nicht immer eine direkte Konsequenz aus den fachlichen Gegebenheiten, sondern sie werden auf Basis von Schätzungen oder Erfahrungswerten definiert. Das kann dann der Fall sein, wenn es sich bei der zu testenden Einheit um eine Teilanwendung, einen einzelnen Service oder auch um eine Systemkomponente handelt. Ein mögliches Beispiel hierfür wäre die Vor-

34

2 Performance und Entwicklungsprozess

gabe, dass Datenbankoperationen maximal 200 ms in Anspruch nehmen dürfen, weil die Gesamtantwortzeit eine Sekunde nicht überschreiten soll und in architekturähnlichen Anwendungen 700–800 ms bereits für die implementierte Geschäftslogik und die Übertragung der Daten im Netz erforderlich ist. Zuweilen ist auch eine Entscheidung zwischen zwei Architekturalternativen zu fällen und die Performance ist eine von mehreren Entscheidungskriterien. Generell sollten die dem durchzuführenden Test zugrunde liegenden Anforderungen einer kritischen Bewertung unterzogen werden. Das ist besonders dann notwendig, wenn aufgrund einer Vielzahl möglicher Einflussfaktoren nicht alle potentiellen Laufzeitvarianten (z.B. alle Anwendungsfälle) getestet werden können und eine Schwerpunktsetzung zwingend erforderlich ist. Die Anforderungen, die aus betriebswirtschaftlichem Verständnis und im Sinne des Projektfortschrittes die größte Relevanz haben, sind durch diese Bewertung zu identifizieren und abzustimmen. Nach einer Überprüfung und eventuellen Überarbeitung der Anforderungen dürfen diese keinen Raum mehr für Interpretationen oder Mehrdeutigkeiten bieten. Die Quantifizierbarkeit ist dazu unerlässlich. Dass eine Anwendung „auch gelegentliche über das normale Maß hinausgehende Spitzenlasten ohne nennenswerte Performanceeinbußen verkraftet“ kann durch keinen Test überprüft oder widerlegt werden. Festlegung der Testziele

Aus den Performanceanforderungen müssen im nächsten Planungsschritt passende Testziele abgeleitet werden. Je mehr die Testumgebung und die Lastprofile den produktiven Bedingungen entsprechen, desto stärker können Testziele und Anforderungen übereinstimmen. Klassische Client/Serverund mehrschichtigen J2EE-Anwendungen erfüllen unter Umständen diese Voraussetzungen. In einer serviceorientierten Anwendungslandschaft sind die Bedingungen komplizierter. Services sind per definitionem zur Verwendung in unterschiedlichen Anwendungen gedacht. Daher ist bereits die Klärung schwierig, was denn genau unter produktiven Bedingungen zu verstehen ist. Produktionsähnliche Voraussetzungen für den Test des Performanceverhaltens einzelner Services können damit kaum geschaffen werden. Der Zeitbedarf eines Services mag für eine Anwendung mehr als zufriedenstellend, für eine andere hingegen äußerst problematisch sein. Weiterhin können nicht alle Anwendungen, die den Service nutzen, zeitgleich getestet werden. In diesen schwierigen Fällen müssen die Testziele mit sehr großer

2.4 Performance- und Lasttests

35

Sorgfalt festgelegt werden, damit sie von allen Beteiligten als den Anforderungen angemessen anerkannt werden. Teststrategie

Die Teststrategie legt die Rahmenbedingungen fest, unter denen der Test erfolgt. In erster Linie geht es dabei um die Frage, welche Teile der für die Durchführung des Tests erforderlichen Ressourcen und Systeme Teile des Untersuchungsgegenstandes (SUT, System Under Test) sind und welche als reine Supportsysteme angesehen werden. Letztere sind zwar technisch zur Durchführung des Tests notwendig, aber ihre Performanceeigenschaften sind nicht zu ermitteln oder gar zu analysieren. Hat ein Unternehmen sich z.B. für den Einsatz einer Java-Laufzeitumgebung (JRE) in einer festgelegten Version und von einem bestimmten Anbieter entschieden, wird es diese Entscheidung nicht ohne triftige Gründe zur Disposition stellen. Dann ist das Performanceverhalten dieser JRE auch nicht Gegenstand des Tests. In einem anderen Fall kann gerade der Vergleich verschiedener JRE im Fokus des Tests stehen. Die Teststrategie beschreibt weiterhin die zur Gewinnung belastbarer Erkenntnisse notwendigen Lastprofile, die zur Analyse erforderlichen Messdaten und die bereitzustellende Testumgebung. 2.4.2 Testvorbereitung In vielen Projekten wird nach der Festlegung des Testumfangs und der Testziele unverzüglich mit der Testdurchführung begonnen. Möglicherweise sind bereits anderweitige Verzögerungen im Projekt aufgetreten und man möchte die Tests nun schnell abschließen, um weitere Terminüberschreitungen zu vermeiden. Oder es sind bereits ähnliche Tests durchgeführt worden und man geht optimistisch von ähnlichen Ergebnissen bei den nun anstehenden Tests aus. Wenn auch die Motive für ein derartiges Vorgehen verständlich sind, so kann nur davor gewarnt werden, die Testdurchführung völlig ohne vorbereitende Maßnahmen zu treffen. Werden mit weiteren Software Releases die gleichen Testläufe im Sinne eines Regressionstests durchgeführt, so können viele Aktivitäten im Vorfeld aus den vergangenen Tests übernommen werden. Aber auch das muss in Form von Handlungsanweisungen und unterstützt durch Checklisten und dergleichen organisiert werden. Hat man es mit einem völlig neuen fachlichen und/oder technischen Hintergrund zu tun, sollte man der Testvorbereitung genügend Zeit widmen. Während die Teststrategie sich mit der Frage beschäftigt, was im Test getan werden soll, klärt die Testvorbereitung, wie der Test durchzuführen

36

2 Performance und Entwicklungsprozess

ist. Kernpunkte der Vorbereitung sind die Lastprofile, die Testautomatisierung, der Messprozess und die Testumgebung. Lastprofile und Lastgenerierung

Aus den im Test ermittelten Performancekennzahlen sind möglichst genaue Rückschlüsse auf das reale Performanceverhalten unter produktiven Bedingungen zu ziehen. Neben der Anwendungsarchitektur und den entwickelten oder von Drittanbietern erworbenen Softwarekomponenten stellen vor allem die für die Tests bereitzustellende Hardware und das Lastprofil die Größen dar, welche das im Test erreichte Performanceverhalten maßgeblich beeinflussen. Architektur und Software sind hauptsächlicher Testgegenstand und damit für den Zeitraum zwischen dem Beginn der Testplanung und dem Abschluss des Testberichtes fixiert. Und für die Auswahl der Hardware spielen häufig Kostenkriterien die zentrale Rolle und können nicht beliebig durch das Projekt beeinflusst werden. Die generierten Lasten stellen das flexibelste Mittel dar, um aus den Ergebnissen des Tests belastbare Aussagen für das zukünftige Produktivsystem ableiten zu können. Diese Möglichkeit der Kalibrierung ist Segen und Fluch zugleich. Ein Segen, weil sich mit unterschiedlichen Lastprofilen nahezu unerschöpfliche Testvarianten bieten. Ein Fluch, weil die komplexen Abhängigkeiten zwischen Hardwareeigenschaften, Last und Performance die Wahl einer zwecktauglichen Testlast außerordentlich schwer macht. Projekt- und anwendungsspezifische Charakteristiken sind bei der Definition der Testlast auf jeden Fall zu berücksichtigen, so dass sich generelle, vom Gegenstand der Untersuchung unabhängige Verfahrensanweisungen nicht formulieren lassen. Aber anhand eines kleinen Beispiels wird dargelegt, wie mit Hilfe von Lastprofilen eine Lücke zwischen den Test- und den produktiven Bedingungen geschlossen werden kann (Menasce u. Almeida 2002). Mit dem neuesten Release einer bereits produktiv genutzten Intranetanwendung ist vor der Produktionsübernahme ein Lasttest durchzuführen. Die Anwendung wird von 3000 Anwendern genutzt und die Antwortzeiten sollen im Schnitt 1,5 Sekunden nicht überschreiten. Aufgrund von Untersuchungen ist bekannt, dass die Benutzer durchschnittlich 30 Sekunden auf einer Seite verweilen (Bedenkzeit), bevor sie den nächsten Request auslösen. Zur Generierung der Last wird ein Werkzeug verwendet, bei dem jeder virtuelle Benutzer durch einen Thread repräsentiert wird. Die Verwaltung von 3000 Threads auf einem handelsüblichen PC ist jedoch – wenn überhaupt – nur mit erheblichen Performanceeinbußen möglich. Daher befürchten die Testverantwortlichen eine Verfälschung der Ergebnisse. Da aber auch keine weiteren Rechner zur Verfügung stehen, auf denen die

2.4 Performance- und Lasttests

37

Simulation der Benutzer verteilt werden kann, besteht die Idee, durch einen Verzicht auf die Bedenkzeit die Last je virtuellen Benutzer zu erhöhen und dafür im Gegenzug virtuelle Benutzer einsparen zu können. Die Antwortzeiten und der Durchsatz am Server sollen dabei jedoch unverändert bleiben. Es stellt sich daher die Frage, wie hoch die Zahl der virtuellen Benutzer zu wählen ist. Zur Beantwortung dieser Frage ziehen wir im Vorgriff auf das Kapitel 3 das Response Time Law zu Rate. Dessen Aussage lautet formell:

R = N / X0 − Z

(2.1)

und in einer simplen algebraischen Umformung:

X 0 = N / (R + Z )

(2.2)

Dabei bezeichnet R die Antwortzeit, X 0 den Systemdurchsatz, Z die Bedenkzeit und N die Anzahl der Benutzer. Setzen wir nun die uns bereits bekannten Werte in die letzte Gleichung ein und berücksichtigen die Forderung des unveränderten Durchsatzes und der unveränderten Antwortzeit, so erhalten wir die beiden folgenden Formeln:

X 0 = 3000 / (2 + 30)

(2.3)

X 0 = N virtuell / (2 + 0 )

(2.4)

N virtuell = 6000 / 32 ≈ 187,5

(2.5)

und schließlich:

Nun kann der Lasttest mit 188 virtuellen Benutzern durchgeführt werden, die unmittelbar nach Erhalt einer Serverantwort den nächsten Request absetzen. Selbstverständlich stimmt die Belastung der Systemressourcen durch dieses Testverfahren nicht exakt mit denen des produktiven Betriebes überein. Durch die deutlich geringere Benutzerzahl ist auch der Speicherbedarf zur Verwaltung von Sitzungsdaten erheblich reduziert. Ob die Testziele mit dieser Einschränkung vereinbar sind, hängt von den Testzielen ab. Dokumentation der Testumgebung und der Konfiguration

Eine Bewertung der Testergebnisse ist ohne die Kenntnis der Ausstattung und der Konfiguration der Testumgebung schlichtweg nicht denkbar. Gerade im Hinblick auf Abweichungen zu den Produktionssystemen, aber auch zur Gewährleistung vergleichbarer Testbedingungen in unterschiedlichen Releases der Anwendung ist die Dokumentation der Umgebung un-

38

2 Performance und Entwicklungsprozess

abdingbar. Die folgenden Elemente sind in der Umgebungsdokumentation zu beschreiben: • Hardware: Die im Test verwendeten Server, deren Ausrüstung und Konfiguration ist genau zu erfassen. Dies umfasst die Leistungsfähigkeit der Prozessoren, Typ und Kapazität der Plattensysteme und der verfügbaren Speicher. Die Rechnersysteme, auf denen die Lastgeneratoren betrieben werden, sind in gleicher Weise zu dokumentieren. • Software: Hierzu gehören alle für die Testdurchführung benötigten Softwarekomponenten, also Betriebssysteme, Webserver, Applikationsund Datenbankserver sowie die Software zur Generierung der Last. Die Konfigurationsdaten sind zu dokumentieren. Sofern die Konfigurationsdaten in ASCII-Dateien vorliegen, können diese als Anhang des Dokuments beigefügt werden. • Netzwerkumgebung: Alle Netzwerkverbindungen, über die der Testclient mit den Servern oder diese untereinander kommunizieren, sind aufzuführen. Auch hier sind die Leistungskennziffern (Bandbreiten) genau zu erfassen. Weiterhin müssen die Kommunikationsprotokolle in die Dokumentation aufgenommen werden. • Daten: Vielfach geben sich Testverantwortliche die größte Mühe, um eine möglichst produktionsnahe Serverausstattung für Performancetests zu erhalten. Hingegen wird der Versorgung mit geeigneten Testdaten nur geringe Aufmerksamkeit gewidmet, obgleich die Performance der Datenbanken sehr stark mit den vorhandenen Mengengerüsten streut. Die Struktur und das Volumen der bereitzustellenden Testdaten ist gut zu dokumentieren. Weichen sie signifikant von den produktiven Mengengerüsten ab, so ist dies zu begründen und die daraus resultierenden Implikationen für die Performanceanalyse sind zu bewerten. Entwicklung eines Messplans

So vielfältig die Ziele auch sein können, die man mit einem Performancetest verfolgt, so geht es doch immer darum, in irgendeiner Weise die Last in Relation zu den Bearbeitungszeiten und dem Ressourcenbedarf zu setzen. Alle mit der Messung von Performancedaten im Zusammenhang stehenden Fragen sind in einem Messplan zu behandeln: • Welche Informationen werden benötigt? Der Informationsbedarf für die auf Basis des Tests zu treffende Entscheidung ist zu beschreiben. Soll beispielsweise eine Anwendung nur dann in Produktion genommen werden, wenn sie 500 Anwender auf der vorhandenen Infrastruktur unterstützen kann und die Antwortzeiten dabei in 90% aller Fälle unter 2 Sekunden liegen, so besteht der Informationsbedarf in einer entsprechenden Statistik.

2.4 Performance- und Lasttests

39

• Wie sind die Ergebnisse des Performancetests zu präsentieren? Die Form, in der die Daten für die jeweilige Zielgruppe aufbereitet werden soll, muss bereits vor der Testdurchführung feststehen, denn möglicherweise ergeben sich daraus auch Konsequenzen für die Datenerfassung. Soll die Abhängigkeit zwischen der Anzahl gleichzeitig aktiver Benutzer und der durchschnittlichen Antwortzeit in einem Diagramm illustriert werden, so muss diese Abhängigkeit aus den gesammelten Rohdaten abgeleitet werden können. • Wie werden diese Ergebnisse ermittelt? Welche Verfahren sind erforderlich, um die gewünschten Ergebnisse aus den Daten abzuleiten. Angenommen aus den Protokollen des Lastgenerators kann für jeden Zeitpunkt während der Testdurchführung die Anzahl der aktiven (virtuellen) Benutzer ermittelt werden und jede Sekunde wird die Auslastung der Serverprozessoren gemessen und protokolliert. Möchte man den Einfluss der Benutzeranzahl auf die Auslastung untersuchen, so sind die Daten aus den beiden Protokollen miteinander zu verknüpfen. Dazu sind Skripte zur Auswertung erforderlich und müssen beauftragt und geplant werden. • Welche Messdaten müssen während des Tests erfasst werden und welche Werkzeuge und Verfahren sind dazu erforderlich? Es sind jene Messdaten zu bestimmen, die zur Deckung des Informationsbedarfs erforderlich sind und nicht durch Algorithmen aus anderen bekannten Metriken abgeleitet werden können. Weiterhin sind die Werkzeuge zu dokumentieren, die zur Ermittlung dieser Daten benötigt werden. Organisatorisches

Um einen möglichst reibungslosen Ablauf der Testdurchführung sicherzustellen, sind einige organisatorische Maßnahmen zu treffen. Zum Teil handelt es sich dabei um sehr profane Angelegenheiten. Beispielsweise ist es zuweilen erforderlich, die Tests außerhalb der üblichen Arbeitszeiten durchzuführen. Dann ist dafür Sorge zu tragen, dass der Zugang zu den Arbeitsplätzen und Serverräumen gewährleistet ist. Auch die Zustimmung der Personalabteilungen kann notwendig sein, wenn die beteiligten Mitarbeiter Überstunden oder Wochenendarbeit leisten müssen. Geklärt werden muss auf jeden Fall, welche administrativen oder technischen Supportmitarbeiter im Verlaufe des Tests unmittelbar oder aber telefonisch erreichbar sein müssen. Diese und ähnlich gelagerte Fragen werden am besten in Form von Checklisten organisiert.

40

2 Performance und Entwicklungsprozess

2.4.3 Testdurchführung Sind die Aktivitäten der Testplanung und der Testvorbereitung diszipliniert und ordnungsgemäß durchgeführt worden, so sollte die Testdurchführung selbst keine größeren Probleme bereiten. Natürlich steckt der Teufel im Detail und es kann nicht ausgeschlossen werden, dass trotz aller Planungssorgfalt ein vergleichsweise geringer, aber schwer zu identifizierender Software- oder Konfigurationsfehler dazu führt, dass der Test abgebrochen werden muss und keine aussagekräftigen Ergebnisse erzielt werden können. Während die Tests ablaufen, ist das System genau zu beobachten, um auftretende Probleme unverzüglich lösen zu können. Üblicherweise werden mehrere Testläufe mit unterschiedlichen Laststufen oder Umgebungskonfigurationen durchgeführt. Es empfiehlt sich, nach jedem dieser Testläufe die erhobenen Messdaten zu sichern, veränderte Geschäftsdaten gegebenenfalls zu bereinigen und die Server durchzustarten. Viele der dabei erforderlichen Aktivitäten scheinen vielleicht bedeutungslos zu sein. Es ist aber ratsam, jede Aktivität in einem Ausführungsplan zu erfassen und den Status jeweils zu kontrollieren und zu dokumentieren. 2.4.4 Analyse und Testberichte Nach der Durchführung des Performancetests sind die gesammelten Daten zu sichten und aufzubereiten. Auch hier gibt es keine allgemeingültigen Verfahrensanweisungen, da die Datenanalyse stark von dem im Messplan aufgeführten Informationsbedarf abhängt. Die folgenden Daten dürften aber in der einen oder anderen Form Bestandteil jeder Testauswertung sein: • Statistiken zu den clientseitig gemessenen Antwortzeiten in Abhängigkeit von der Last. • Statistiken zum erreichten Durchsatz in Abhängigkeit von der Last. • Soll-/Ist-Abgleich zu den Performancebudgets. Welche Budgets werden überschritten, welche sind eventuell zu großzügig bemessen? • Anteil der aufgetretenen Fehler während des Testablaufs, Auswirkung dieser Fehler auf die Signifikanz der Ergebnisse. • Auslastung der Prozessoren und Plattensysteme in der Testumgebung. • Netzwerkauslastung und Netzwerklatenzzeiten. Die Erstellung zielgruppengerechter Berichte orientiert sich an dem jeweiligen Entscheidungsbedarf. Geeignete Präsentationstechniken sind ein Kernelement des Berichtswesens und Kapitel 9 widmet sich ausschließlich diesem Thema.

2.5 Zusammenfassung

2.5

41

Zusammenfassung

Die Performance von Anwendungssystemen ist facettenreich. Fach- und IT-Abteilungen nehmen naturgemäß verschiedene Perspektiven auf die Performance ein. Auch innerhalb der IT-Organisation hängt das Performanceverständnis der Mitarbeiter stark von ihrer jeweiligen Rolle ab. Die Sicherstellung einer guten Performance erfordert daher ein interdisziplinäres Vorgehen. Ausgehend von dem Selbstverständnis der verschiedenen Rollen wurden Struktur und Aufgaben eines Performanceteams beschrieben, in dem die nötige Zusammenarbeit über Organisations- und Abteilungsgrenzen hinweg erreicht werden kann. Performance- und Lasttests sind im Entwicklungsprozess zur Qualitätssicherung unerlässlich. Die verschiedenen Maßnahmen zur Planung, Durchführung und Nachbearbeitung solcher Tests wurden erläutert.

42

2 Performance und Entwicklungsprozess

Literatur Mannion M, Keepence B (1995) SMART Requirements. ACM SIGSOFT Software Engineering Notes, 20 (2):S 42-47 Menasce D, Almeida V (2002) Capacity Planning for Web Services. Prentice Hall, New York Smith C, Williams L (2006) Five Steps to Establish Software Performance Engineering in Your Organization. Proc. CMG, Reno http://www.perfeng.com/cspubs.htm

3

Quantitative Methoden

3.1

Motivation

Wie in kaum einer anderen Disziplin des Software Engineering beschäftigt man sich im Performancemanagement mit quantitativen Daten und Metriken. Die Zeit steht dabei als physikalische Einheit im Mittelpunkt der Betrachtungen und wird in ihren unterschiedlichen Varianten (Antwortzeiten, Servicezeiten, Wartezeiten etc.) untersucht. Auch andere Performancegrößen wie der maximal erreichbare Durchsatz oder der Bandbreitenbedarf nehmen indirekt Bezug auf die Zeit. Dass zwischen diesen Größen direkte Zusammenhänge bestehen, leuchtet unmittelbar ein. Doch wie lassen sich die Zusammenhänge formal beschreiben? Und vor allen Dingen – welchen praktischen Nutzen kann man aus der Kenntnis der quantitativen Beziehungen gewinnen? Welche Einschränkungen ergeben sich aufgrund der Vereinfachungen, die man bei der Entwicklung eines mathematischen Modells in Kauf nehmen muss? Auf diese Fragen möchte das vorliegende Kapitel Antworten geben. Zugrunde liegt dabei die teilweise komplexe Warteschlangentheorie, zu der es umfangreiche Monographien gibt und aus der sich inzwischen eigenständige Fachrichtungen entwickelt haben. Im Rahmen dieses Buches muss daher eine starke Beschränkung auf die wesentlichen Sachverhalte vorgenommen werden. So wird etwa auf ausführliche Beweise von Formeln und Gesetzmäßigkeiten verzichtet und stattdessen die Anwendbarkeit der Theorie an einfachen Beispielen demonstriert. Warum sollte sich ein Anwendungsarchitekt, ein Kapazitätsplaner oder ein Systemadministrator mit formalen und theoretischen Aspekten des Performancemanagements auseinandersetzen? Ist die Annahme nicht vermessen, man könne auf Basis einiger weniger Voraussetzungen und Anforderungen berechnen, welche Kapazitäten und Rechnerleistungen auf den unterschiedlichen Ebenen einer verteilten

44

3 Quantitative Methoden

Komponentenarchitektur und komplexen Infrastruktur bereitzustellen sind? Tatsächlich kann ein formales Modell nicht alle Facetten einer hochdynamischen Anwendungslandschaft abbilden. Bereits die bei solchen Modellen üblicherweise implizit angenommenen Raten, mit denen HTTPAnfragen an einen Webserver eintreffen, dienen mehr der mathematischen Beherrschbarkeit des Modells, als dass sie reale Phänomene beschreiben. Schon aus diesem Grunde können quantitative Ansätze ein fundiertes Performancetest- und Systemmanagement nicht ersetzen, sondern dieses nur ergänzen. Daher liegt der Zweck eines formalen Ansatzes auch vorwiegend darin, grundlegende Annahmen etwa in dem nicht-funktionalen Anforderungsdokument (siehe Kapitel 5) oder in den definierten Lastprofilen für Performancetests zu validieren und erste Anhaltspunkte für angemessene Kapazitätsplanungen und Serverkonfigurationen zu gewinnen. Es muss leider immer wieder festgestellt werden, dass Administratoren die vielfältigen Systemparameter von Web-, Applikations- und Datenbankservern entweder unverändert mit den von den Herstellern vorkonfigurierten Werten belassen oder allenfalls aufgrund von Mutmaßungen und Daumenregeln einstellen. Damit verzichten sie auf ein besseres Verständnis der inneren Zusammenhänge und gehen erhebliche Risiken ein, wertvolle Systemressourcen über Gebühr zu strapazieren oder umgekehrt eine erwünschte Auslastung der Rechner zu verhindern. Bei diesen und ähnlich gelagerten Fragestellungen, die im weiteren Verlauf des Kapitels erörtert werden, stellen formale Untersuchungen und Bewertungen eine außerordentlich wertvolle Ergänzung der sonstigen Planungsverfahren dar. Ein weiteres Motiv, welches bereits alleine die Beschäftigung mit diesem Gebiet rechtfertigt, ist die für mathematisch-analytische Verfahren symptomatische Strenge und Eindeutigkeit, mit der Begrifflichkeiten festgelegt werden. Denn Abhängigkeiten und Beziehungen zwischen zwei oder mehreren Performancemetriken können ja nur dann in der Form von Gleichungen oder Ungleichungen formuliert oder durch Algorithmen berechnet werden, wenn sie so definiert und beschrieben werden, dass für Fehlinterpretationen und mehrdeutige Auslegungen keinerlei Spielräume mehr bleiben. Hält man dem entgegen, wie häufig wichtige Kenngrößen und Termini wie Systemauslastung und Engpass in Dokumenten aufgeführt werden, aber von verschiedenen Personen aus Fach- und ITAbteilungen ganz unterschiedlich interpretiert werden und welche Missverständnisse sich daraus ergeben können, wird man den Wert einer zweifelsfreien Begriffsbildung schätzen lernen. Jene Leser, denen dies nicht einleuchtet, sind aufgefordert, Kolleginnen und Kollegen um eine Defini-

3.2 Ressourcen und Warteschlangen

45

tion des Begriffs Skalierbarkeit zu bitten; sie werden von dem breiten Spektrum an Antworten überrascht sein.

3.2

Ressourcen und Warteschlangen

Im Zentrum der folgenden Erörterungen steht eine Ressource, welche einen wie immer gearteten Service anbietet. Der Begriff Ressource wird dabei sehr universell und abstrakt gefasst. Damit besitzt die Warteschlangentheorie ein weites Anwendungsspektrum innerhalb und außerhalb der IT. Eine Ressource kann sowohl ein Mitarbeiter eines Callcenters als auch eine CPU eines Datenbankservers sein. In diesem Fall besteht der abrufbare Service aus Rechenzyklen, in jenem vielleicht aus Beratungs- oder Gesprächszeit. Je nach Blickwinkel muss es sich bei der konkreten Ressource nicht zwingend um eine physisch wahrnehmbare Komponente wie den bereits erwähnten Prozessor, eine Netzwerkkarte oder einen Webserver handeln. Auch ein nur begrifflich, aber nicht sinnlich fassbares Objekt kann als Ressource in einem formalen Performancemodell aufgenommen werden. Beispiele hierfür sind Threadpools eines Webcontainers, Datenbankverbindungen in einem Connectionpool, Caches und andere durch Software realisierte Ressourcen. Wird der Service, den eine Ressource anbietet, von einem Konsumenten angefordert, so nimmt die Ausführung des Service eine gewisse Zeit – die Servicezeit – in Anspruch. Während dieser Ausführungszeit steht die Ressource für andere Anfragen nicht zur Verfügung. Diese müssen in einer Warteschlange (Queue) auf die Freigabe der Ressource warten. Die Nutzer der Ressource müssen also mit Wartezeiten rechnen, die je nach Art der Ressource und dem Ausmaß der Konkurrenz unterschiedlich hoch ausfallen können. Die bis hierhin festgelegten Begriffe stellen für sich genommen noch kein herausragendes Ergebnis dar. Jeder Besuch eines Post- oder Fahrkartenschalters liefert genügend Anschauungsmaterial zum Verständnis der bislang beschriebenen Sachverhalte. Ein Schalterbeamter bedient die Kunden, welche sich je nach Andrang in eine Warteschlange einreihen müssen, ehe sie ihre Pakete aufgeben oder eine Fahrkarte erwerben können. Die Bedeutung und der Nutzen der Theorie erschließt sich erst dann, wenn nicht mehr nur eine einzelne Ressource und die mit ihr verbundene Warteschlange untersucht, sondern ein ganzer Verbund (Queueing Network) von Ressourcen mit verschiedenen Servicezeiten und Belastungen analysiert werden soll. Als eine Analogie aus dem Alltagsleben bietet sich der Vergleich mit einer Poliklinik an: Hier werden Patienten unter Umständen einer ganzen Reihe von Behandlungen durch verschiedene medi-

46

3 Quantitative Methoden

zinische Apparaturen und Spezialisten unterzogen. Diese reichen von der Anmeldung über die Blutabnahme, das Röntgen und Belastungs-EKG bis zu einer ersten Diagnose durch einen Arzt. In der Regel entstehen dabei Wartezeiten, die der Patient mit anderen im Wartezimmer verbringt. Je nach Befund muss der Patient bei einem Arzt auch mehrfach vorstellig werden. Auch für die mehrfache Inanspruchnahme eines Services gibt es vergleichbare Situationen im IT-Umfeld: • Auf Systemebene etwa das Rendering einer HTML-Seite durch einen Webbrowser, bei dem alle eingebetteten Objekte wie Grafiken und Scriptdateien zu wiederholten, nicht durch den Benutzer unmittelbar initiierten Anfragen an den Webserver führen. • Auf Hardwarekomponentenebene die mehrfach wechselnde CPU- und I/O-Anfrage eines Datenbankservers während der Bearbeitung einer SQL-Anfrage. 3.2.1 Begriffsfestlegungen und Definitionen Im Folgenden werden die bisher mehr oder weniger umgangssprachlich verwendeten Begriffe definiert und daraus erste Ergebnisse abgeleitet. Diese Definitionen und Resultate sind in dieser zusammenhängenden Form erstmals durch Denning und Buzen formuliert worden (Denning u. Buzen 1978). Unter dem Begriff Queue verstehen wir eine Ressource und die mit dieser verbundene Warteschlange, in der zu bearbeitende Anfragen auf die Freigabe der Ressource warten können. Ein Queuing-Netzwerk besteht aus n Queues Q1 , Q2 ,K, Qn . Es werden Serviceanfragen an das Netzwerk gestellt, die von allen oder einigen der Ressourcen zu bearbeiten sind. Das Netzwerk wird von außen also als ein einheitlicher Serviceprovider betrachtet. Auf dieser Basis werden nun die nachstehenden Definitionen getroffen1: • Vi (visits): Anzahl der Ressourcenanforderungen an Queue Qi je Serviceanfrage. • Si : Benötigte Servicezeit je Ressourcenanforderung an Queue Qi .

1

Alle numerischen Werte sind als Durchschnittswerte zu verstehen, auch wenn dies nicht explizit angegeben ist.

3.2 Ressourcen und Warteschlangen

47

• Di : Gesamter Servicezeitbedarf (Demand) an Queue Qi je Serviceanfrage, also Di = Vi × Si . • Wi : Durchschnittliche Wartezeit an Queue Qi je Ressourcenanforderung. • Ri : Verweil- oder Antwortzeit (Responsetime) der Queue Qi je Ressourcenanforderung. Diese Antwortzeit setzt sich zusammen aus der Servicezeit und der Wartezeit, es gilt also Ri = Si + Wi . • QLi (Queuelength): Anzahl der Anfragen in einer Queue, die auf Bearbeitung warten. • X i : Durchsatz an Queue Qi , also die Anzahl der bearbeiteten Ressourcenanforderungen je Zeiteinheit. • X 0 : Durchsatz (Systemdurchsatz) des gesamten Netzwerks, also die Anzahl der je Zeiteinheit vollständig bearbeiteten Serviceanfragen. 3.2.2 Auslastung und das Utilization Law Die Auslastung einer Ressource an Queue Q i definiert den relativen Zeitanteil, währenddessen die Ressource aktiv mit der Bearbeitung von Anforderungen beschäftigt ist. Bezeichnet wird diese Auslastung mit U i (Utilization). Ist die Ressource während des Betrachtungszeitraums T zu Bi (Busytime) Zeiteinheiten aktiv, so beträgt also die Auslastung:

U i = Bi / T

(3.1)

Werden insgesamt C Anfragen bearbeitet, so ergibt sich für die Servicezeit die Gleichung

Bi = C × Si

(3.2)

X i = C / T also T = C / X i

(3.3)

und für den Durchsatz

Setzt man die in (3.2) und (3.3) erhaltenen Werte für Bi und T in Gl. (3.1) ein, erhält man das so genannte Utilization Law:

48

3 Quantitative Methoden

U i = C × Si / (C / X i ) = Si × X i

(3.4)

Die Gesamtzeit (Betrachtungszeitraum), in deren Verhältnis die reine Bearbeitungszeit gesetzt wird, hängt vom Kontext und der Betrachtungsweise ab. Prinzipiell erhält man mit dem Utilization Law Durchschnittswerte und keine Aussagen über Spitzenauslastungen. Sind unter Zuhilfenahme eines JavaProfilers z.B. CPU-Zeiten einer zentralen Java-Methode eines Webservices gemessen worden und ist die Anzahl seiner Aufrufe aus den Protokolldateien des Webservers ermittelbar, so kann das Utilization Law dazu verwendet werden, die durch den Web Service verursachte CPU-Auslastung zu berechnen. Legt man aber ein Zeitfenster zugrunde, welches auch Phasen extremer Unterlast (Wochenenden, nachts) umfasst, sind die Ergebnisse nur von eingeschränktem Wert. Beispiel: Rechenzeiten zur Verarbeitung einer Webanfrage

Das Utilization Law kann dazu verwendet werden, die zur Verarbeitung einer Webanfrage erforderliche CPU-Zeit zu schätzen. Dazu geht man in folgenden Schritten vor: 1. Bestimmung der Grundlast: Der Server wird über einen Zeitraum von 10–20 Minuten einem Monitoring2 unterzogen. Dabei wird darauf geachtet, dass nur Kernel- und Systemprozesse aktiv sind. Insbesondere ist zwar der Applikationsserver gestartet, aber es werden an diesen keine Anfragen gestellt. 2. Anschließend beginnt man damit, mittels Lastgeneratoren Anfragen an das System zu senden, und steigert diese Last sukzessive. Die erreichte Maximallast wird über einen Zeitraum von einer oder mehreren Stunden gehalten. Über den gesamten Zeitraum wird das Monitoring fortgesetzt (siehe Abb. 3.1). 3. Aus den gesammelten Monitoringdaten wird die Differenz der Prozessorauslastung ermittelt. Die Lastgeneratoren protokollieren den erreichten Durchsatz oder man kann diesen aus der Anzahl der ausgeführten Anfragen ermitteln. Mittels der Umformung des Utilization Law zu Si = U i / X i erhält man damit die zur Bearbeitung eines Requests erforderliche CPU Zeit. Diese kann dann als Grundlage für Kapazitätsplanungen herangezogen werden.

2

Als Monitoringwerkzeug kann hierzu das unter Unix-Derivaten oder Linux verfügbare vmstat verwendet werden.

3.2 Ressourcen und Warteschlangen

49

100 90 80

CPU Auslastung [%]

70

steady state / maximale Last

60 50 40 sukzessive Laststeigerung

30 20 10

Grundlast

Grundlast

0

Abb. 3.1 CPU Auslastung vor, während und nach einem Lasttest als Grundlage zur Ermittlung von benötigten Rechenzeiten auf Basis des Utilization Law

Diese Vorgehensweise scheint auf den ersten Blick übertrieben aufwändig zu sein. Die von einer Java-Methode benötigte CPU-Zeit kann doch auch mittels marktüblicher Java-Profiler ermittelt werden. Nun, ein Java-Profiler dient üblicherweise dem Tuning von Applikationen und der Identifikation von unökonomisch implementierten Algorithmen. Zu diesem Zweck muss eine mikroskopisch genaue Untersuchung der Anwendung zur Laufzeit erfolgen und das erfordert zusätzliche Rechenleistung. Dadurch ist aber eine Messung unter mittlerer bis hoher Last von vorneherein ausgeschlossen. (Kapitel 8 widmet sich dieser Problematik im Detail). Eine gewisse Grundlast ist aber notwendig um genügend statistisch aussagefähiges Datenmaterial zu erhalten und den Einfluss von Ausreißern möglichst gering zu halten. Natürlich gibt es auch professionelle Monitoring-Lösungen für J2EE-Applikationen, mit denen die Auslastung der Hardwarekomponenten auch unter Last überwacht werden kann, aber nicht immer stehen diese in allen Testumgebungen zur Verfügung. In solchen Fällen stellt das beschriebene Verfahren eine kostengünstige und effizient umzusetzende Alternative dar. 3.2.3 Das Forced Flow Law Der Gesamtdurchsatz X 0 des Queueing-Netzwerks und der Durchsatz an einer einzelnen Queue X i stehen in einem direkten Zusammenhang:

50

3 Quantitative Methoden

X i = Vi × X 0

(3.5)

Jede von dem System zu bearbeitende Serviceanfrage führt im Schnitt zu Vi Anfragen an der der Queue Qi zugeordneten Ressource. Der Gesamtdurchsatz erzwingt daher dem in der Gl. (3.5) angegeben Queuedurchsatz. Beispiel: Datenbankdurchsatz

Die Auswertungen einer Systemprotokolldatei haben ergeben, dass ein Webservice in der Stunde etwa 72000-mal aufgerufen wird. Zur Bearbeitung eines Aufrufes sind drei Datenbankaufrufe erforderlich. Wie hoch ist der Datenbankdurchsatz X DB dieser Webservice-Anwendung? Wegen X 0 = 72000 / 3600 = 20 und VDB = 3 erhält man X DB = 60 . 3.2.4 Die Queueing-Formel von Little Die nun beschriebene Gesetzmäßigkeit ist als Little’s Law (Little 1961) bekannt und besitzt im Rahmen der quantitativen Methoden des Performancemanagements ein weites Anwendungsfeld. Es besagt, dass die durchschnittliche Anzahl N von Anfragen, die parallel in einem System bearbeitet werden oder auf Bearbeitung warten, sich aus dem Produkt des Durchsatzes X und der mittleren Verweilzeit R ergeben:

N = X ×R

(3.6)

Dieser Sachverhalt lässt sich heuristisch wie folgt erklären: Zwischen dem Eintreffen einer Serviceanfrage im System bis zum Zeitpunkt der vollständigen Bearbeitung dieser Anfrage vergehen R Zeiteinheiten. Je Zeiteinheit löst eine Anfrage also 1 / R Transaktionen aus. Um einen Durchsatz von X Transaktionen je Zeiteinheit zu erreichen, sind daher X /(1 / R ) = X × R Anfragen notwendig. Ein vollständiger Beweis des Little’s Law ist jedoch um einiges aufwändiger. Auf den ersten Blick scheint die Aussage unmittelbar einleuchtend zu sein. Um die eigentliche Bedeutung dieses Gesetzes zu verstehen, muss man sich jedoch vergegenwärtigen, dass keinerlei Voraussetzungen an die statistische Verteilung der Verweilzeiten und der Eintreffrate der Anfragen gestellt werden und die Formel damit eine sehr universelle Gültigkeit besitzt.

3.2 Ressourcen und Warteschlangen

51

Beispiel: Datenbankverbindungspool

Nimmt man zu dem vorherigen Beispiel an, dass die Datenbankabfragen des Webservice im Schnitt 200 ms benötigen, so sind nach der Formel von Little im Mittel X × R = 60 × 0.2 = 12 Datenbankabfragen gleichzeitig aktiv – eine wertvolle Information für die Administratoren des Applikationsservers, denn sie hilft ihnen bei der Konfiguration des Datenbankverbindungspools. Das Beispiel belegt eindrücklich, mit welchen bescheidenen Mitteln zuweilen zentrale Konfigurationsparameter der Server und Systemsoftware validiert werden können. In diesem Fall ist die Analyse von Protokolldateien des Datenbank- und des Applikationsservers bereits ausreichend. Eine unmittelbar mit dem Little’s Law im Zusammenhang stehende Formel ist das Response Time Law. 3.2.5 Response Time Law Das Response Time Law stellt einen Zusammenhang zwischen der Anzahl der Benutzer eines Systems N, deren durchschnittlicher Bedenkzeit Z, dem Durchsatz dieses Systems X0 und der Antwortzeit R des Systems her. Die Durchführung eines Geschäftsvorfalles über eine interaktive Benutzerschnittstelle erfolgt üblicherweise über mehrere Dialogschritte. Wenn auch akzeptable Antwortzeiten von Anwendungstyp und Umgebung abhängen und sich daher generelle Aussagen verbieten, erfordert die ergonomische Handhabung einer solchen Anwendung doch Serverantwortzeiten, die im Allgemeinen im einstelligen Sekundenbereich liegen sollten. Die Zeit, die der Benutzer benötigt, um die Resultate seiner Anfragen zu bewerten, Eingaben zu tätigen und die notwendigen Folgeaktivitäten abzuleiten, in deren Verlauf er aber keine weiteren Anfragen an das System stellt, wird in der Regel jedoch höher ausfallen. Diese Zeit wird als Bedenkzeit (englisch Thinktime) bezeichnet. Für die Antwortzeit des Systems macht das Response Time Law nun folgende Aussage:

R = N / X0 − Z

(3.7)

Ein formaler Beweis des Response Time Law ist mit Hilfe der Formel von Little möglich. Veranschaulichen lässt sich die Korrektheit aber auch durch die folgenden einfachen Überlegungen. Werden im Beobachtungszeitraum T insgesamt C Systemanfragen bearbeitet, so fallen auf jeden Benutzer im Schnitt C/N dieser Anfragen. Eine Benutzeranfrage ist somit T/(C/N) Zeiteinheiten aktiv in dem Sinne, dass entweder der Server mit ihrer Bearbeitung (R), oder aber der Benutzer mit der Bewertung der Anfrageergebnisse (Z) beschäftigt ist. Wir

52

3 Quantitative Methoden

erhalten R + Z = T/ (C/N ) = N × T/C = N/X 0 und durch eine einfache Umformulierung das Response Time Law. Beispiel Datenbankverbindungspool (Fortsetzung):

Wir nehmen an, dass die Servicezeit des in den vorausgehenden Beispielen beschriebenen WebServices 400 ms beträgt, so dass sich aufgrund der für die drei Datenbankaufrufe erforderliche Zeit von 600 ms eine Bearbeitungszeit von einer Sekunde ergibt. Die Aufrufe selbst werden durch 500 Sachbearbeiter ausgelöst. Somit liegen uns die folgenden Werte vor: N = 500, R = 1, X 0 = 20 Für die Bedenkzeit erhalten wir daraus Z = N / X 0 − R = 24 3. Nun lässt sich fast unmittelbar erkennen, dass eine signifikante Erhöhung des Durchsatzes nicht durch solche Maßnahmen wie das Tuning des Webservices oder den Einsatz schnellerer Prozessoren für den Datenbankserver erreicht werden kann. Denn bei gleicher Anzahl der Sachbearbeiter und unveränderten Bedenkzeiten wird der maximal mögliche Durchsatz (theoretisch) dann erreicht, wenn die Server keine Zeit zur Bearbeitung benötigen ( R = 0 ), und beträgt dann X 0 = N / Z ≈ 20,8 . Um einen deutlich höheren Durchsatz zu erreichen, müssen also entweder mehr Sachbearbeiter eingesetzt oder aber durch eine weitere Automatisierung die erforderliche Bedenkzeit reduziert werden. Auch wenn die Begriffe Bedenkzeit und Serverantwortzeit dies vielleicht nahelegen, beschränkt sich die Anwendung des Response Time Law nicht nur auf die hier zur Veranschaulichung herangezogenen Fälle von Anwendungen, in denen reale Benutzer Anfragen an einen Webserver oder Applikationsserver stellen. Erinnern wir uns an den Begriff des WarteschlangenNetzwerks. Jede Ressource besitzt dort individuelle Service-, Warte- und Antwortzeiten. Und natürlich kann auch die Gemeinschaft der Benutzer als eine Ressource gesehen werden, deren Servicezeit dann eben in der Bedenkzeit besteht. Damit lässt sich das Response Time Law mit den bekannten Definitionen allgemeiner formulieren.

∑R i

3

i

= N × X0

(3.8)

Der zusätzliche Zeitbedarf für die Übertragung der Daten durch das Netzwerk wurde dabei als vernachlässigbar angenommen. Korrekterweise beträgt die Summe aus diesen Zeiten und der Bedenkzeit 24 Sekunden.

3.3 Mean Value Analysis

53

Hier bezeichnet N alle im Gesamtsystem durch eine Ressource bearbeiteten oder auf eine solche Bearbeitung wartenden Anfragen. Beispiel: Trichterbildung von Threadpools

Wir greifen nun ein letztes Mal das Beispiel des Web-Services auf. In den Tuning- und Performancedokumenten von marktführenden J2EEApplikationsservern findet sich die Empfehlung, die zur Bearbeitung von Anfragen auf den verschiedenen Ebenen (Webserver, Webcontainer des Applikationsservers, EJB Container und Datenbankverbindungspool) zu konfigurierenden Threadpools trichterförmig aufzubauen (Roehm et al. 2005). Von Ebene zu Ebene soll dabei die Anzahl der Threads reduziert werden. Das Ziel dieser Maßnahme besteht darin, Anfragen nur bis zu den Ressourcen weiterzuleiten, auf denen eine Bearbeitung mit hoher Wahrscheinlichkeit sofort erfolgen kann und nicht auf die Freigabe einer Ressource warten muss. Wird die Anzahl zu hoch angesetzt, werden wertvolle Systemressourcen nutzlos verbraucht. Das Response Time Law kann den Administratoren natürlich genaue Untersuchungen der Systemauslastung zum Tuning der Threadpools nicht ersparen. Es liefert aber Anhaltspunkte für eine erste Grundkonfiguration, die als Ausgangsbasis für weitere Optimierungsschritte dienen kann. Dass im Schnitt 12 Datenbankverbindungen benötigt werden, wissen wir bereits. Da die Verweilzeit innerhalb der Webservices-Methoden eine Sekunde beträgt, sind bei dem Durchsatz von 20 Anfragen pro Sekunde durchschnittlich 20 Webserviceanfragen aktiv (das garantiert uns Little’s Law). Bei beiden Werten handelt es sich um Durchschnittszahlen und um auch höhere Lasten berücksichtigen zu können müssen die Pools erweitert werden. Das Verhältnis von 5:3 zwischen der Threadanzahl des Webcontainer und der Größe des Datenbankverbindungspools sollte aber als Richtschnur eingehalten werden, bevor durch Testverfahren genauere Erkenntnisse abgeleitet werden können.

3.3

Mean Value Analysis

Die Universalität des Ressourcenbegriffs wurde bereits hervorgehoben. In den Beispielen haben wir uns diese Allgemeingültigkeit zu Nutze gemacht, um auch auf Software basierende Komponenten wie Thread- und Datenbankverbindungspools zu dimensionieren. Allerdings wurde bei diesen Betrachtungen der Fall hoch ausgelasteter Hardware-Komponenten vernachlässigt und deren fortwährende Verfügbarkeit vorausgesetzt. In der Realität nimmt eine Software-Ressource jedoch gewissermaßen eine Doppelrolle ein. Einerseits fungiert sie als Ressource, die nach außen

54

3 Quantitative Methoden

einen Service zur Verfügung stellt. Andererseits nimmt sie selbst Dienste anderer Ressourcen in Anspruch, die entweder wiederum durch Software realisiert sind oder aber durch Hardware-Komponenten bereitgestellt werden. In einem strengeren Sinne benötigt eine Softwareressource keine Servicezeiten. Vielmehr setzt sich die zur Abarbeitung einer Anforderung benötigte Zeit aus Servicezeiten und Wartezeiten von Hardwarekomponenten zusammen. Die angenommenen Servicezeiten von 200 ms für eine Datenbankoperation oder 400 ms für die restliche Laufzeit des Webservices simplifizieren daher den realen Sachverhalt. Mit steigender Benutzerzahl und zunehmender Auslastung der Prozessoren, Netzwerke und Disksysteme werden die Queues an diesen Hardwareressourcen wachsen und die Wartezeit zu einem dominanten Faktor werden. Die angenommenen Zeiten von 200 ms bzw. 400 ms reichen dann nicht mehr zur Erfüllung der Serviceanforderung aus. Daher werden wir uns bei den folgenden Untersuchungen mit den Wartezeiten selbst beschäftigen und einen analytischen Zugang erarbeiten, um so ein besseres Verständnis der Begriffe Engpass, Sättigungspunkt und Durchsatzschranken zu gewinnen. Eine vollständige Durchdringung der dieser Thematik zugrunde liegenden mathematischen Theorie wird Mean Value Analysis genannt und erfordert vertiefte Kenntnisse der Wahrscheinlichkeitstheorie und Statistik, die hier nicht vorausgesetzt werden können. Dem Leser, der an einer theoretisch fundierten Darstellung der Sachverhalte interessiert ist, sei die Lektüre der Originalarbeiten der Begründer dieser Theorie (Reiser u. Lavenberg 1980) und mathematisch orientierter Lehrbücher (Trivedi 2002) empfohlen. Die Grundideen werden daher heuristisch und unter Verzicht auf mathematische Strenge vermittelt. Warteschlangen und Wartezeit

Die Zeit, die ein Kunde einrechnen muss, der an einem Fahrkartenschalter ein Ticket erwerben oder auf einem Postamt ein Paket aufgeben möchte, hängt nicht nur von der Zeit S ab, die der zuständige Mitarbeiter zur Bearbeitung des Anliegens benötigt, sondern wird selbstverständlich auch von der zu erwartenden Anzahl QL der Personen bestimmt, die bereits in der Warteschlange stehen und ebenfalls eine Dienstleistung anfordern. Durchschnittlich muss unser Kunde QL × S Zeiteinheiten warten ( W = QL × S ), bis er „an der Reihe“ und weitere S Zeiteinheiten, bis seine Serviceanforderung erfüllt ist.

3.3 Mean Value Analysis

55

Die Bearbeitungszeit beträgt daher in Summe

R = W + S = QL × S + S = (QL + 1) × S Zeiteinheiten

(3.9)

Damit haben wir zwar eine Darstellung der Bearbeitungszeit gefunden, doch ohne eine Bestimmung der Warteschlangenlänge QL können wir vorerst keine weiteren Aussagen treffen. 3.3.1 Das Arrival-Theorem Hier hilft uns das Arrival-Theorem weiter. Wir möchten wissen, wie groß der Wert QL durchschnittlich werden kann. Das Little Law bestimmt die durchschnittliche Anzahl von Serviceanfragen in einem Queueing-Netzwerk auf Basis des Durchsatzes und der Verweilzeit und behandelt so eine sehr ähnliche Fragestellung. Allerdings bezieht sich dort die Durchschnittsbildung auf den gesamten Beobachtungszeitraum, während wir nun ausschließlich an jenen Zeitpunkten interessiert sind, zu denen ein neuer Kunde die Warteschlange betritt – oder allgemeiner und formal: eine weitere Serviceanforderung im Queueing-Netzwerk eintrifft. Die beiden Werte – Länge der Warteschlange im Allgemeinen und Länge der Warteschlange beim Eintreffen einer Anfrage – stehen unter bestimmten Voraussetzungen in einem direkten Zusammenhang. Dieser Zusammenhang wird durch das Arrival-Theorem detailliert dargestellt. Wir beschränken uns bei der Formulierung dieses Theorems auf geschlossene Warteschlangennetze, in denen Anfragen von N Konsumenten ausgelöst werden. Nach der Beantwortung einer solchen Anfrage wartet der Konsument die Bedenkzeit ab und setzt dann den nächsten Request ab. Intranetanwendungen, die von einer fixen Anzahl von Benutzern verwendet werden, werden üblicherweise durch geschlossene Queueing-Netzwerke modelliert. Dem gegenüber stehen die offenen Netzwerke. Bei diesen wird von einer potentiell unbegrenzten Benutzergruppe ausgegangen, welche einen steten Anfragestrom auf die Ressourcen auslöst. Internetanwendungen sind typische Beispiele für diese Art von Netzen. Trifft einer von insgesamt N möglichen Konsumenten an der Warteschlange einer Ressource ein, so können sich in dieser Warteschlange höchstens N − 1 weitere Konsumenten befinden. Das Arrival-Theorem sagt nun aus, dass die durchschnittliche Zahl der an einer Ressource wartenden Konsumenten in einem geschlossenen Netzwerk mit insgesamt N Konsumenten zu den Zeitpunkten eines Neu-

56

3 Quantitative Methoden

zugangs identisch ist, zu der durchschnittlichen Zahl in einem um einen Konsumenten reduzierten Netzwerk ( N − 1 ) zu beliebigen Zeitpunkten4. Indem das Theorem bedeutende Performanceindikatoren in einem Netz auf eines mit um eins reduzierter Konsumentenzahl zurückführt, ermöglicht es deren sukzessive Berechnung durch einen rekursiven Algorithmus. Denn kennt man die Verweilzeiten Ri ( N ) an jeder Ressource

Qi für N Konsumenten, so ergibt sich aus deren Summe die Verweilzeit R( N ) im gesamten Netz. Nach Little’s Law erhält man den Systemdurchsatz X 0 ( N ) = N / R( N ) und aus diesem – wiederum durch Anwendung des Little Law – die mittlere Länge der Warteschlangen an den Ressourcen QLi ( N ) = X 0 ( N ) × Ri ( N ) . Nach dem Arrival-Theorem ist diese Warteschlangenlänge identisch zu der Anzahl der auf Bearbeitung wartenden Anfragen beim Eintreffen eines neuen Konsumenten in einem Netzwerk mit N + 1 Konsumenten. Dort erhält man für die Verweilzeiten

Ri ( N + 1) = [QLi ( N ) + 1]× Si

(3.10)

und kann so die Berechnung auf der nächsten Stufe fortsetzen. Das ist der Kern der Mean Value Analysis (MVA). 3.3.2 Implementierung des MVA-Algorithmus Der folgende Codeausschnitt zeigt eine Java-Implementierung des MVAAlgorithmus für geschlossene Queueing-Netzwerke in seiner einfachsten Form. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 4

package mva; ... public class CloseQueueMVASolver ... public void solve() { ... double queueLength[] = new double[numResources]; double responseTimes[] = new double[numResources]; Arrays.fill(queueLength, 0.0); Arrays.fill(responseTimes, 0.0); for (int n = 1; n GetEnv((void **)&jvmpi_interface, 11 JVMPI_VERSION_1_2)) < 0) { 12 13 return JNI_ERR; 14 } 15 16 // die Callbackmethode zur Ereignisbearbeitung 17 // wird der JVM bekanntgegeben 18 jvmpi_interface->NotifyEvent = notifyEvent; 19 20 // bekunde Benachrichtigungsinteresse an der 21 // erfolgreichen JVM Initialisierung 22 jvmpi_interface->EnableEvent(JVMPI_EVENT_JVM_INIT_DONE, 23 NULL);

176

8 Java Monitoring und Profiling

24 25 return JNI_OK; 26 } 27 28 }// JVM_OnLoad

Das erste Argument dieser Funktion liefert einen Zeiger auf eine Datenstruktur (JavaVM, Zeile 7), die Zugriffe auf unterstützende Funktionen und Komponenten der JVM ermöglicht. In den Zeilen 10–14 wird über diese Datenstruktur kontrolliert, ob das JVMPI in der Version 1.2 unterstützt wird. Ist dies nicht der Fall, wird der JVM ein Fehlerflag zurückgeliefert, und das Java-Programm dadurch beendet. Anderenfalls erhält man durch den Aufruf in der (globalen) Variablen jvmpi_interface einen Zeiger auf die eine JVMPI-Datenstruktur, die im weiteren Verlauf für die Kommunikation zwischen dem Agenten und der JVM erforderlich ist. Als erstes wird dort (Zeile 18) die Rückruffunktion des Agenten bekannt gegeben (notifyEvent), die bei registrierten Ereignissen durch die JVM aufzurufen ist. In den Zeilen 22 und 23 teilt der Agent der JVM mit, dass er über die erfolgreiche Initialisierung des JVM-Starts benachrichtigt werden möchte. Die Implementierung von notifyEvent zur Ereignisbearbeitung findet sich im folgenden Listing. 1 void notifyEvent(JVMPI_Event *event) { 2 3 switch(event->event_type) { 4 /** 5 * Die JVM wurde erfolgreich initialisiert. 6 * Die notwendige Benachrichtigung zu wichtigen 7 * Ereignissen kann nun erfolgen. 8 */ 9 case JVMPI_EVENT_JVM_INIT_DONE: 10 { 11 jvmpi_interface->EnableEvent 12 ( 13 JVMPI_EVENT_METHOD_ENTRY, 14 NULL 15 ); 16 jvmpi_interface->EnableEvent 17 ( 18 JVMPI_EVENT_METHOD_EXIT, 19 NULL 20 ); 21 jvmpi_interface->EnableEvent 22 ( 23 JVMPI_EVENT_DATA_DUMP_REQUEST, 24 NULL 25 ); 26 jvmpi_interface->EnableEvent 27 ( 28 JVMPI_EVENT_JVM_SHUT_DOWN, 29 NULL 30 );

8.4 Java Virtual Machine Profiler Interface

177

31 break; 32 } 33 34 // Eintritt in eine Java Methode 35 case JVMPI_EVENT_METHOD_ENTRY: 36 { 37 countmethodentries++; 38 break; 39 } 40 41 // Austritt aus einer Java Methode 42 case JVMPI_EVENT_METHOD_EXIT: 43 { 44 countmethodexits++; 45 break; 46 } 47 48 /** 49 * JVM wird beendet oder ein Dump Signal 50 * hat die VM von aussen erreicht. 51 * Erstelle Kurzreport ueber die bisherige 52 * Anzahl von Methodenein- und -austritten. 53 */ 54 case JVMPI_EVENT_JVM_SHUT_DOWN: 55 case JVMPI_EVENT_DATA_DUMP_REQUEST: 56 { 57 fprintf(stdout,"#meth.entry=%d #meth.exit=%d\n", 58 countmethodentries,countmethodexits); 59 break; 60 } 61 } 62 return; 63 }// notifyEvent

Der Abschluss der JVM-Initialisierung ist ein geeigneter Zeitpunkt um weitere Ereignisse zu registrieren, bei deren Eintreten der Agent im weiteren Verlauf des Programms unterrichtet werden soll (Zeilen 9–32). Es handelt sich zum einen um die Ereignisse des Ein- und Austritts von Methoden, zum anderen um die Ereignisse, die das Beenden der JVM oder den Erhalt eines externen Signals ankündigen. Der Agent dient nur dem Zweck, die Anzahl von Methodenein- und austritten in den globalen Variablen countmethodentries bzw. countmethodexits zu zählen (Zeilen 32–46). Nun ist es an der Zeit, den implementierten und kompilierten Agenten in einen Java-Prozess einzublenden und an einem einfachen Beispiel zu testen. 1 public class ManyMethodCalls 2 { 3 int count = 0; 4 static public void main( String[] args ) 5 { 6 ManyMethodCalls mmc = new ManyMethodCalls(); 7 for( int i = 1; i GetActiveObject 9 ( 10 'Excel.Application' 11 ) 12 }; 13 die "Excel not installed" if $@; 14 15 unless (defined $Excel) { 16 $Excel = Win32::OLE->new('Excel.Application') 17 or die "sorry, cannot start Excel"; 18 }

In den Zeilen 7–13 wird kontrolliert, ob Excel auf dem Rechner zur Verfügung steht. Ist dies nicht der Fall, wird das Programm beendet. Auch wenn Excel nicht gestartet werden kann, bricht das Programm sofort ab (Zeilen 15–18). Konnte hingegen die Excel-Anwendung erfolgreich gestartet werden, wird sie nun durch OLE „ferngesteuert“.

230

9 Visualisierungstechniken 1 2 3 4 5 6

# use excel in hidden mode $Excel->{Visible} = 0; my $Book = $Excel->Workbooks->Add; my $Sheet = $Book->Worksheets(1); $Sheet->{Name} = "heap_data"; $sheetname = $Sheet->Name;

Zuerst wird in Zeile 2 dafür Sorge getragen, dass Excel unsichtbar ausgeführt wird. Das verhindert ein unnötiges Flackern bei den nachfolgenden Grafikoperationen. Dann wird eine neue Excel-Arbeitsmappe eingerichtet (Zeile 3) und in dieser ein benanntes Datenblatt angelegt (Zeile 4–5). Diese Schritte wären so oder so ähnlich auch bei der manuellen Anfertigung des Diagramms erforderlich. Nun werden die Daten aus dem Perl-Array nach Excel kopiert: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

# put records into an excel sheet my @excelrange = (); for( $i = 0; $i < $arraysize; $i++ ) { my @tmparr = (); my $rec = $recarr[$i]; my @fields = split(/\t/,$rec); $timestamp = @fields[0]; $free_heap = @fields[1]; $used_heap = @fields[2]; $max_heap = @fields[3]; $min_heap = @fields[4]; push @tmparr,$timestamp; push @tmparr,$free_heap; push @tmparr,$used_heap; push @tmparr,$max_heap; push @tmparr,$min_heap; push @excelrange,\@tmparr; } $lastrow = @excelrange; my $columns = 5; my $LeftUpperCell = $Sheet->Cells(1,1); my $RightLowerCell = $Sheet->Cells($lastrow,$columns); my $Range = $Sheet->Range($LeftUpperCell,$RightLowerCell); $RightLowerCell = $Sheet->Cells($lastrow,$columns); $Range->{Value} = \@excelrange;

Dazu wird für jeden Satz in den Zeilen 5–17 ein eindimensionales temporäres Feld @tmparr mit den Attributen gefüllt und dann dieses temporäre Feld in die Matrix @excelrange eingetragen (Zeile 18). Im Datenblatt wird ein Bereich definiert (Zeilen 21–26) und in Zeile 27 erfolgt dann die Übertragung der Daten. Dann erfolgt die Erstellung des Streudigramms.

9.6 Ein Chartgenerator in Perl 1 2 3 4 5 6 7 8 9 10 11 12

231

# create scatter diagramm of heapusage # we are interested in values from the C-column my $range = "C1:C$lastrow"; my $ChartRange = $Sheet->Range($range); # create a chart my $Chart = $Excel->Charts->Add; $Chart->SetSourceData ( {Source => $ChartRange, PlotBy => xlColumns} ); $Chart->{HasTitle} = 1; $Chart->{ChartType} = xlXYScatter;

Im Code werden wiederum die gleichen Schritte durchgeführt, die auch bei der manuellen Diagrammerstellung üblich sind. Erst wird ein Datenbereich definiert, auf den sich das Diagramm beziehen soll (Zeilen 3–4). Dann wird das Diagramm erzeugt (Zeile 6) und mit dem Bereich verknüpft (Zeilen 7–10). Das Diagramm wird als Streudiagramm konfiguriert (Zeile 12). Jetzt erfolgen einige Anpassungen, die der Ästhetik dienen, und eine Regressionslinie wird dem Diagramm hinzugefügt: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

my $SC = $Chart->SeriesCollection(1); # mark first columns as range for x-axis $xaxes = "=$sheetname!R2C1" . ":R$lastrow" . "C1"; $SC->{XValues} = $xaxes; $SC = $Chart->SeriesCollection(1); # take small circles as marker $SC->{MarkerStyle} = xlCircle; $SC->{MarkerBackgroundColorIndex} = 1; $SC->{MarkerForegroundColorIndex} = 1; $SC->{MarkerSize} = 3; $Chart->PlotArea->Interior->{ColorIndex} = 2; $SC->{Trendlines}->Add( { Type => xlLinear, DisplayEquation => True, DisplayRSquared => True, Name => "heaptrend" } ); # beautify trendline my $Trendline = $SC->Trendlines(1); $Trendline->DataLabel->Font->{Size} = 16; $Trendline->DataLabel->Font->{Name} = "Courier New"; $Trendline->DataLabel->{HorizontalAlignment} = xlLeft; $Trendline->DataLabel->{Top} = 3; # y-axis title $Chart->Axes(xlValue, xlPrimary)->{HasTitle} = 1; $Chart->Axes(xlValue, xlPrimary) ->AxisTitle->{Text} = "heap usage [KByte]";

232

9 Visualisierungstechniken 34 35 36 37 38

# beautify chart $Chart->Legend->{Position} = xlBottom; $Chart->ChartTitle->{Text} = "*** HEAP Report ***"; $Chart->ChartTitle->Font->{Size} = 16; $Chart->ChartTitle->Font->{Bold} = True;

In den Zeilen 1–12 werden die Farbe und die Größe der Streupunkte definiert. In den Zeilen 13–19 erfolgt die Spezifiktion der Regressionslinie. Es handelt sich um eine lineare Regression und sowohl die beschreibende Gleichung als auch der Korrelationskoeffizient werden hinzugefügt. Wie wir ja bereits in Kap. 9.3.3 festgestellt haben, lässt sich dadurch ein möglicher Speicherverlust quantifizieren. Es erfolgen noch einige Anpassungen der Schriftgrößen und es wird ein Titel für das Diagramm vergeben. Damit ist die Erstellung des Diagramms auch schon beendet. Um das Diagramm unabhängig von Excel weiterverwenden zu können, möchten wir es nun noch als Bilddatei exportieren. 1 2 3 4 5 6 7 8 9 10 11 12 13 14

# export chart as picture my $cwd = getcwd() . "/"; my $chartexportfilter = "gif"; my $chartfilename = $cwd . $performancelog . ".$chartexportfilter"; $Chart->Export ( { FileName => $chartfilename, FilterName => $chartexportfilter, Interactive => 0 } );

Das Bild wird als GIF (Graphics Interchange Format) angelegt und im gegenwärtigen Verzeichnis gespeichert. An der Excel-Datei sind wir natürlich auch noch interessiert. 1 # save chart 2 $Book->SaveAs 3 ( 4 { 5 Filename => 6 $cwd . "$performancelog" . "_perlgenerated.xls", 7 Password => "perl_makes_a_lot_of_sense", 8 ConflictResolution => xlLocalSessionChanges 9 } 10 ); 11 # show the result 12 $Excel->{Visible} = 1; 13 } 14 #end heapchart.pl

Wir speichern diese ab (Zeilen 2–10). Auch dabei stehen einem die gleichen Möglichkeiten zur Verfügung, die man im Umgang mit Excel kennt. Hier vergeben wir ein Kennwort, dass beim Öffnen der Exceldatei abge-

9.7 Zusammenfassung

233

fragt wird. Nun ist auch der Zeitpunkt gekommen, das Resultat anzuzeigen (Zeile 12). Die Abbildung 9.9 zeigt das automatisch erstellte Streudiagramm in Excel. *** HEAP Report *** y = 73.017x + 54340 R2 = 0.7947

90000 80000 70000

heap usage [KByte]

60000 50000 40000 30000 20000 10000 0 0

50

100

150

200 used_heap[kbyte]

250

300

350

400

heaptrend

Abb. 9.9 Ein Streudiagramm mit Informationen zum Speicherverhalten einer J2EE-Anwendung. Das Diagramm wurde mit Hilfe eines Perl-Programmes innerhalb einer Sekunde aus rohen Performancedaten gewonnen.

Das beschriebene Perl-Programm wurde unter der Perl Distribution von ActiveState8 in der Version 5.8.7 ausgeführt. Die Dokumentation beinhaltet eine gute Informationen zu Perl und auch eine Kurzeinführung zu OLE mit Perl.

9.7

Zusammenfassung

Das vorliegende Kapitel hat eine Einführung über Techniken zur grafischen Aufbereitung von Performancedaten gegeben. Die Auswahl angemessener Diagramme hängt von der zugrundeliegenden Fragestellung ab. Häufig ist es schwierig, Hypothesen zu formulieren, die ein Performanceproblem erklären können. Dann sind Visualisierungswerkzeuge interessant, die dem Anwender die Untersuchung großer Datenmengen unter verschiedenen Prämissen erlauben. Treemaps sind ein herausragendes Beispiel für solche Techniken. Ihre Verwendung im Rahmen einer Untersuchung zur GPRS Performance wurde vorgestellt. Abschließend wurde 8

http://www.ActiveState.com

234

9 Visualisierungstechniken

am Beispiel eines kleinen Perl-Programms illustriert, dass auch beim Einsatz eigenentwickelter Monitoringlösungen, bei denen die Daten in flachen Dateistrukturen gespeichert werden, auf eine automatisierte Erstellung von Grafiken, Diagrammen und Präsentationen nicht verzichtet werden muss.

Literatur Dubois J (1998) WIN32::OLE, The Perl Journal #10, http://search.cpan.org/~jdb/libwin32-0.27/OLE/lib/Win32/OLE/TPJ.pod Shneiderman B (1992) Tree Visualization with Tree-Maps:2-d Space-Filling Approach. ACM Transactions on Graphics, Volume 11:92–99

10

Beispielszenario Webservice

10.1 Motivation In den vorangegangenen Kapiteln wurden eine ganze Reihe von Methodiken und Werkzeugen vorgestellt, die den verantwortlichen Performancearchitekten bei der Kapazitätsplanung unterstützen und den Anwendungsarchitekten und Systemadministratoren Möglichkeiten zur Ermittlung von Performancedaten und deren Auswertung bieten. Einige der beschriebenen Technologien sind wohlbekannt und dürften vielen Lesern, welche die voranschreitenden Entwicklungen im Umfeld von Java, Webservices und SOA aktiv verfolgen, in der einen oder anderen Form schon einmal begegnet sein. Wer sich ernsthaft mit verteilten JavaApplikationen auseinandersetzt, wird zwangsläufig mit einigen der zahlreichen Frameworks, Bibliotheken und Tools der Apache Software Foundation konfrontiert werden. Daher wird z.B. das Testwerkzeug JMeter einem breiteren Kreis von Entwicklern und Architekten bekannt sein. Den meisten Systemadministratoren von Unix- oder Linuxumgebungen wiederum werden die Hilfswerkzeuge zur Erfassung von Laufzeitstatistiken zur Auslastung von Prozessoren (vmstat) und Ein-/Ausgabegeräten (iostat) sowie für bestehende Netzwerkverbindungen (netstat) vertraut sein. Mit den meisten Themen, die in diesem Buch behandelt wurden, werden IT-Spezialisten in ihrer täglichen Arbeit in der Regel jedoch selten konfrontiert. Diese Themen gehören auch nicht zu den typischen Ausbildungsschwerpunkten an Universitäten und Fachhochschulen. Die Theorie der Warteschlangen, diskrete Simulationsmodelle oder moderne Formen von Visualisierungstechniken lernen nur diejenigen kennen, die spezielle Vorlesungen und Seminare an Mathematik- oder Informatiklehrstühlen besuchen. Die Vermittlung dieser Materie erfordert vom Leser die Bereitschaft, sich mit theoretischen Konzepten auseinanderzusetzen. Damit die einzelnen Sachgebiete nicht zu trocken dargestellt werden und der Praxisbezug nicht verloren geht, wurden die Konzepte durch die Präsentation einfacher Beispiele untermauert.

236

10 Beispielszenario Webservice

Dennoch ist es wünschenswert, den Zusammenhang der Einzelthemen an einem etwas umfangreicheren Beispiel erfahrbar zu machen. Diesem Anliegen dient das vorliegende Kapitel.

10.2 Rahmenbedingungen und Gestaltungsmöglichkeiten Vorrangiges Ziel für das Design eines beispielhaften Szenarios ist also das Zusammenwirken der vorgestellten Technologien und Verfahren. Daraus ergeben sich die folgenden Minimalanforderungen an das umzusetzende Programm: 1. Entwicklung einer Java-Anwendung, die einen über Prozess- und Servergrenzen hinweg nutzbaren Dienst zur Verfügung stellt. 2. Ermittlung der Performance dieses Dienstes unter den moderaten Bedingungen eines Single-User-Betriebs. 3. Erstellung von Performanceprognosen für den Dienst unter unterschiedlichen Lastprofilen. Diese Prognosen sind unter Verwendung der quantitativen Verfahren aus Kap. 3 und unter Zuhilfenahme von Simulationstechniken zu erstellen. 4. Durchführung von Lasttests analog den der Prognose zugrundeliegenden Lasttypen. 5. Messung und Verwaltung von Performancedaten sowohl auf dem Server als auch auf dem Testclient (Endbenutzersicht). 6. Auswertung der Testergebnisse und Abgleich mit den prognostizierten Werten. Damit ein solcher Showcase jedoch ohne allzu großen Aufwand von jedem Interessenten praktisch nachvollzogen werden kann, müssen einige grundsätzliche Voraussetzungen erfüllt sein: 1. Die erforderliche Software für die Entwicklung und den Betrieb des Dienstes muss frei verfügbar sein. 2. Die Berechnung der Warteschlangenmodelle und die Durchführung von Simulationen sollen ebenfalls auf Basis freier Software möglich sein. 3. Die Beispiele können auf einem nach dem Stand der heutigen Technologie ausgestatteten Entwicklungsrechner durchgeführt werden. Auf einem Entwicklungsrechner können natürlich nicht alle Infrastrukturkomponenten, die zum Betrieb einer realen serviceorientierten Anwendung notwendig sind, performant und stabil unter Last ausgeführt werden. Häufig verfügen bereits die Webserver über eine bessere Hardwareausstat-

10.3 Das Beispielszenario

237

tung und in Umgebungen mit hohen Verfügbarkeitsanforderungen ist in der Regel mindestens eine im unteren zweistelligen Bereich liegende Anzahl physischer Server im Einsatz (ein Loadbalancer, zwei bis drei Webserver, mehrere Applikationsserver, LDAP-Server und Datenbankserver). Selbst für die Erzeugung der Last durch einen Testtreiber reicht zuweilen ein leistungsfähiger Rechner nicht aus, wenn zur ordnungsgemäßen Durchführung eines Testszenarios die vom Server gelieferten Daten maschinell verarbeitet und analysiert werden müssen. Bei der konzeptionellen Festlegung des Beispiels ist daher eine Gratwanderung zwischen Realitätsnähe und einfacher Umsetzbarkeit notwendig.

10.3 Das Beispielszenario Der zu entwickelnde Dienst soll als Webservice implementiert und von bis zu 80 Klienten genutzt werden. Diese Klienten werden durch ein Testtool simuliert, das parallel zum Webservice auf dem gleichen Rechner ausgeführt wird. Damit die beiden Prozesse – Applikationsserver und Lasttreiber – nicht zu sehr um Prozessorleistung konkurrieren müssen und alleine schon dadurch der Sinn des Szenarios in Frage gestellt wird, soll der Dienst keine umfangreichen Rechenleistungen in Anspruch nehmen. Dadurch fehlt uns jedoch ein serverseitiger Engpass, der unter Last zu einer Begrenzung des Durchsatzes und zum Anwachsen der Antwortzeiten führt. Unter diesen Optionen limitiert dann allenfalls der Testtreiber oder die Größe des Threadpools im Applikationsserver die Performance. Interessiert sind wir aber an dem Performanceverhalten auf dem Server. Diesem Dilemma begegnen wir durch zwei Maßnahmen. Erstens schränken wir die Leistungsfähigkeit des Applikationsservers durch einen niedrig dimensionierten Threadpool ein. Die Threads, die für die Bearbeitung der eingehenden Requests zuständig sind, werden auf diese Weise zum Engpass gemacht. Zweitens erhöhen wir die Antwortzeiten des Dienstes, in dem wir den ausführenden Thread für eine bestimmte Zeit pausieren lassen. Dadurch wird die Laufzeit, die in der Realität durch eine hohe Hardwareauslastung oder durch das Warten auf eine externe Ressource (Datenbank, weitere Webservices auf fernen Systemen) entsteht, auf künstliche Weise simuliert. Die Klienten selbst rufen den Dienst mit einhundert Wiederholungen auf, wobei zwischen zwei Aufrufen nur für kurze Zeit pausiert wird (niedrige Bedenkzeit). In diesem Sinne ähnelt das Beispielszenario einem Batchprozess, dessen Ablauf aus einem externen Serviceaufruf und einer internen Weiterverarbeitung der Ergebnisse besteht. Die Abbildung 10.1 illustriert diese Vorgehensweise.

238

10 Beispielszenario Webservice

Applikationsserver 1

WebService

0.75

0.5

0.25

Servicetime Distribution

0

Threadpool

Lasttreiber Testrechner

Abb. 10.1. Lasterzeugung und -verarbeitung auf einer Maschine. Ein Engpass wird künstlich durch eine niedrige Zahl von Threads zur Behandlung eingehender Anfragen erreicht. Die Servicezeiten werden einer Verteilung entnommen und durch Pausieren der Threads erzwungen.

10.4 Aufbau der Testumgebung Die Testumgebung umfasst den auf dem Applikationsserver zu installierenden Webservice und den Lasttreiber, der mit konfigurierbar vielen virtuellen Benutzern auf diesen Dienst zugreift. 10.4.1 Der Webservice Zur Entwicklung des Webservice wird das Axis2-Framework der Apache Software Foundation eingesetzt. Axis2 unterstützt in mehrfacher Weise die Entwicklung und die Verwendung von Webservices. Zur Laufzeit stellt Axis2 die notwendigen Mechanismen für den Austausch von SOAPNachrichten zwischen dem Benutzer und dem Anbieter eines Webservice bereit. Axis2 kann also sowohl auf dem Client als auch auf dem Server verwendet werden. Für den letzten Fall stellt Axis2 eine J2EE-konforme Webanwendung zur Verfügung, unter der die Webservices als eigenständige Module implementiert werden können. Die Webservices werden als

10.4 Aufbau der Testumgebung

239

sogenannte Axis-Archivdateien installiert. Diese Archive sind gezippte Dateien mit einer vorgegebenen Struktur. Die Entwicklung von Webservices mit Axis2 kann auf verschiedene Weise geschehen. Für unsere Zwecke reicht die denkbar einfachste Form aus: • Entwicklung und Kompilierung einer simplen Java-Klasse (POJO, Plain Old Java Object) mit einer Methode, welche die Kernimplementierung des Webservice enthält. • Erstellung einer Datei services.xml Datei. In dieser sind Detailangaben zu den Diensten beschrieben und sie wird von den Axis2 Laufzeit ausgewertet. • Erstellung eines Axis-Archivs, das die übersetzte Java-Klasse und die services.xml umfasst. Hier der Code der Javaklasse, die mittels Axis2 als Webservice aufrufbar ist: 1 public class WaitDistributedTimeService 2 { 3 private static final double AVERAGESERVICETIME = 1000.0; 4 static private Random randomGen = new Random(47); 5 public Long waitDistTime() 6 { 7 long l = getServiceTime(); 8 try 9 { 10 Thread.currentThread().sleep(l); 11 } 12 catch( Exception e) 13 { 14 } 15 return( new Long(l) ); 16 } 17 18 public long getServiceTime() 19 { 20 double random = 21 -Math.log(randomGen.nextDouble()); 22 return( (long)(random*AVERAGESERVICETIME)); 23 } 24 }

Die Methode getServiceTime() (Zeile 18-23) ermittelt mit dem Zufallszahlengenerator java.util.Random des jdk eine über das Intervall [0,1] gleichverteilte Zufallszahl. Gleichverteilt bedeutet, dass die ermittelte

Zahl x mit der Wahrscheinlichkeit ( b − a ) in dem Teilintervall [a, b] liegt. Die Methode bildet dann den negativen natürlichen Logarithmus dieser Zahl und multipliziert diesen mit der Konstanten 1000. Der so erhaltene Wert wird als die Anzahl von Millisekunden interpretiert, die der aktive Thread nun pausieren soll (Zeile 10). Da dies ein typisches Beispiel für die

240

10 Beispielszenario Webservice

im Rahmen von Simulationen so bedeutende Generierung von Wahrscheinlichkeitsverteilungen ist, wird hier kurz hergeleitet, wie sich die erzwungene Wartezeit verteilt und welcher durchschnittliche Wert zu erwarten ist: Es gilt z = − log( x ) × 1000.0 ≤ T ⇔ x ≥ exp(− T / 1000.0 ) . Und das ist aufgrund der Gleichverteilung von x mit der Wahrscheinlichkeit von

1 − exp(− T / 1000.0)

(10.1)

der Fall. Diese Formel beschreibt die bekannte Exponentialverteilung mit dem Mittelwert 1000. Die Laufzeit unseres Webservice wird also im Durchschnitt eine Sekunde betragen und exponentiell verteilt sein. 10.4.2 Applikationsserver und Lasttreiber Die Axis2-Webanwendung und somit auch unser Webservice werden auf dem Apache Tomcat Server gehostet. Wir nehmen zwei Anpassungen an der Konfiguration des Applikationsservers vor. Als erstes reduzieren wir die maximale Anzahl von Threads, die Tomcat zur Verarbeitung eingehender HTTP-Requests bereitstellt, von 150 auf 15. Während der Durchführung der einzelnen Lasttests möchten wir nicht nur erfahren, welche Antwortzeiten auf der aufrufenden Seite entstehen. Auch die Laufzeiten des Webservice selbst sind von Interesse. Mit dem in Kap. 8 entwickelten Werkzeug nehmen wir Messpunkte in den folgenden Java-Methoden auf. • aus der Klasse WaitDistributedTimeService die Methode waitDistTime und • die Methode doPost des AxisServlet. Erstellung eines JMeter-Testplans

Zur Generierung von Aufrufen des Webservice über das SOAP-Protokoll wird das Werkzeug JMeter verwendet. Auch dieses Werkzeug wird durch die Apache Software Foundation vertrieben. Mit JMeter können Lastprofile für sehr unterschiedliche Anwendungstypen erstellt und ausgeführt werden. Für den hier angestrebten Zweck kommt ein Webservice-Testplan in Frage. Testpläne in JMeter sind hierarchisch angeordnete Konfigurationselemente. Auf der obersten Ebene legen wir eine Threadgruppe an. In einer solchen Threadgruppe wird festgelegt, wieviele Threads Anfragen gegen den Server ausführen sollen und wie häufig jeder Thread die Anfragen wiederholt. Diese Threads bilden die virtuellen Benutzer. Ergänzend kann ein Zeitrahmen konfiguriert werden, innerhalb dessen die einzelnen

10.4 Aufbau der Testumgebung

241

Threads gestartet werden. Wir werden den Test mit wachsender Anzahl von virtuellen Benutzern wiederholen und durch den Zeitrahmen dafür Sorge tragen, dass die einzelnen Threads in einem zeitlichen Abstand von jeweils 100 ms starten. Dies führt zu einem relativ schnellen Anwachsen der Last und entspricht auch dadurch einer Batchverarbeitung. Der Threadgruppe ordnen wir als weiteres Konfigurationselement einen Zeitgeber zu. Dieser ist verantwortlich für die Erzeugung der Bedenkzeiten. Nachdem JMeter das Ergebnis zu einer Webservice-Anfrage erhalten hat, lässt es den zugehörigen Thread für eine gewisse Zeit ruhen. Diese Zeit wird über den Zeitgeber ermittelt. Wir erhöhen die Dynamik des Testszenarios durch die Erzeugung zufälliger Bedenkzeiten. Das ist eine direkte Analogie zu den künstlichen Wartezeiten, die in unserem Webservice erzeugt werden. Wir verwenden als Zeitgeber den sogenannten Gaussian Random Timer aus JMeter. Dieser erzeugt normalverteilte Werte und gibt deren Absolutbetrag zurück, um negative Bedenkzeiten zu vermeiden. Diese Werte werden nach unserer Vorgabe mit 1000 multipliziert. Aufgrund von Eigenschaften der Normalverteilung beträgt dann die durchschnittliche Bedenkzeit 2000 / (2 × π ) ≈ 798 Millisekunden. Das wichtigste Element des Testplans ist natürlich die Konfiguration des Webservice-Aufrufes selbst. Hier wird zum einen der DNS-Name des Servers angegeben, auf dem der Tomcat Server betrieben wird, und der Port, der auf eingehende HTTP-Anfragen hört. Zusätzlich wird die URI angegeben, unter der auf diesem Server der Webservice erreichbar ist. Nach Angabe einer SOAP-Nachricht, die als Parameter an den Webservice mit jedem Request übergeben wird, ist die Konfiguration fast vollständig. 1 2 4 5 6 8 9

Sie wird nur noch um einen Simple Data Writer erweitert, der zur Laufzeit die Ergebnisse des Tests protokolliert. Die Abb. 10.2 zeigt die in JMeter Oberfläche zur Konfiguration des Testplans. Wir haben nun alle notwendigen Vorbereitungen getroffen und können mit dem ersten Testlauf beginnen.

242

10 Beispielszenario Webservice

Abb. 10.2. Der JMeter-Testplan besteht aus Angaben über den aufzurufenden Webservice und die Konfiguration virtueller Benutzer. Die Ergebnisse des Tests werden durch einen Data Writer in einer ASCII-Datei gesichert.

10.5 Der Single-User-Test Bei diesem Test wird ein einziger virtueller Benutzer in zweihundert Wiederholungen den Webservice aufrufen. Im Betrieb mit mehreren Benutzern können sich die Antwortzeiten sicher nicht verbessern. Der Test wird also die bestmögliche Antwortzeit ermitteln und diese kann als Basiswert für die im Anschluss theoretisch zu errechnenden bzw. durch eine Simulation zu evaluierenden Antwortzeiten für verschiedene Laststufen dienen. Nachdem JMeter die 200 Aufrufe des Webservices durchgeführt hat, werden mit Hilfe einfacher awk-Skripte die Protokolldatei des JMeter und die auf dem Server durch den Einsatz des Performancemonitors gesammelten Performancedaten ausgewertet. Die gemessenen Zeiten werden zu Zeitintervallen der Länge 500 ms zusammengefasst und die Häufigkeitsverteilungen durch Histogramme visualisiert (siehe Abb. 10.3).

10.6 Der Webservice als Warteschlangenmodell

243

200

1

150

0.75

100

0.5

50

0.25

0

0 0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

Abb. 10.3. Die Laufzeiten des Webservice (graues Histogramm) und die auf dem Client gemessenen Antwortzeiten (schraffiertes Histogramm) sind nahezu identisch. Zum Vergleich ist als Liniendiagramm die exponentielle Verteilung der künstlich erzeugten Laufzeiten aufgenommen.

Die Auswertung weist nach, dass unter der einfachen Last die auf dem Client gemessenen Antwortzeiten kaum von den Laufzeiten abweichen, die der Webservice zur Ausführung benötigt. Und die Zeiten folgen offenbar dem durch die exponentielle Verteilung vorgegebenen Muster der erzwungenen Wartezeiten für die Threads des Tomcat-Webcontainers. Wir gehen daher in der Folge davon aus, dass unser Webservice einen durchschnittlichen Zeitbedarf von einer Sekunde besitzt und möchten die Auswirkungen des limitierten Threadpools auf die Performance modellieren und die Ergebnisse der Modelle in weiteren Tests überprüfen. Wir beginnen mit einer Analyse durch ein Warteschlangenmodell.

10.6 Der Webservice als Warteschlangenmodell Im Prinzip ist das zu erstellende Warteschlangenmodell relativ einfach. Es besteht zum einen aus einer Ressource, mit der die Gruppe der virtuellen Benutzer repräsentiert wird und deren Servicezeit identisch mit der durchschnittlichen Bedenkzeit ist. Und als weitere Ressource ist der Threadpool des Tomcat-Servers zu modellieren. Allerdings ergibt sich bei der Modellierung des Threadpools eine Schwierigkeit. Wir wissen zwar, dass jeder einzelne Thread im Schnitt eine Sekunde benötigt, bis er eine Anfrage erfolgreich bearbeitet hat. Ist die eingehende Last so gering, dass keine Anfrage in eine Warteschlange ein-

244

10 Beispielszenario Webservice

gereiht wird, so ist die Anzahl der verfügbaren Threads offenbar für die Bearbeitungszeit belanglos. Als Analogie kann man sich einen Supermarkt vorstellen, in dem die Anzahl der geöffneten Kassen größer ist als die Zahl der Kunden, die ihre Waren bezahlen möchten. Die Bearbeitungszeit an der Kasse wird durch die Öffnung weiterer Kassen nicht verringert. Sobald sich vor dem Threadpool jedoch Warteschlangen bilden, stellt sich der Sachverhalt völlig anders dar. Von der Anzahl der verfügbaren Threads hängen dann die Länge der Warteschlange und implizit die Bearbeitungszeit ab. 10.6.1 Modellierung von Mehrfachressourcen Das Problem wird durch einen heuristischen Ansatz gelöst (Seidmann et al. 1987). Eine Ressource, die eine durchschnittliche Servicezeit D aufweist und von der insgesamt m identische Exemplare verfügbar sind, wird im Modell in die zwei folgenden Ressourcen transformiert: 1. Eine normale Ressource mit der Servicezeit D / m und 2. eine Delay-Ressource mit der Servicezeit D × (m − 1) / m . An einer Delay-Ressource bildet sich keine Warteschlange. Sie benötigt zwar auch eine Servicezeit, kann aber gleichzeitig eine unbegrenzte Anzahl von Serviceanfragen bearbeiten. Welche Idee steht hinter diesem Ansatz? Nun, unter geringer Last bildet sich an der ersten der beiden Ressourcen keine Warteschlange und die Servicezeit der beiden Ressourcen beträgt in Summe D Zeiteinheiten. Unter hoher Last wird hingegen die Bearbeitungszeit durch die Wartezeit an der ersten Ressource dominiert. Durch die Reduktion der Servicezeit auf D / m soll diese Wartezeit dann ähnlich sein zu der, die entsteht, wenn m parallele Ressourcen die Warteschlangen abarbeiten, aber pro Anfrage D Zeiteinheiten benötigen. Diese Aussage ist bewusst im Konjunktiv formuliert, denn sie kann nicht mathematisch hergeleitet werden, sondern ist wie bereits erwähnt heuristischer Natur. Das geschlossene Warteschlangenmodell für die Aufrufe des Webservice im Batch ist unter Berücksichtigung der beschriebenen Transformation in Abb. 10.4 dargestellt.

10.6 Der Webservice als Warteschlangenmodell

Thinktime = 2000 /

245

(2 × π )

Servicenutzer / Client

Ressource mit reduzierter Servicezeit

Delay-Ressource

D1 = 1000 / 15

D2 = 1000 ×14 / 15

Threadpool Abb. 10.4. Das Warteschlangenmodell eines Webservice mit beschränkter Anzahl von verarbeitenden Threads. Der Threadpool wird durch einen Verbund einer Queue mit reduzierter Servicezeit und einer Delay-Ressource modelliert.

10.6.2 Analytische Performanceprognose und Validierung Auf Basis dieses Modells kann nun die in Kapitel 3 vorgestellte JavaImplementierung des MVA-Algorithmus durchgeführt werden. Wir erhalten die in Tabelle 10.1 ausgewiesenen Performancemetriken: Tabelle 10.1. Performanceprognosen auf Basis des MVA-Algorithmus Anzahl Benutzer (Serviceklienten) ∅ Antwortzeit [ms] 1 1000 15 1060.48 20 1109.88 30 1343.72 40 1875.23 50 2535.36 60 3202.00 70 3868.67 80 4535.33 a Anzahl der Webserviceaufrufe pro Sekunde.

Durchsatz 0.56 8.07 10.48 14.01 14.96 15 15 15 15

a

246

10 Beispielszenario Webservice

Die Güte der prognostizierten Antwortzeiten lässt sich ohne Vergleichstests kaum bewerten. Die berechneten Durchsatzzahlen scheinen auf den ersten Blick jedoch richtig zu sein. Da nur 15 Threads gleichzeitig aktiv sind und jeder pro Anfrage im Schnitt eine Sekunde zur Bearbeitung benötigt, können unter Last nicht mehr als 15 Webservice-Anfragen je Sekunde bearbeitet werden. Die Qualität der quantitativ ermittelten Performancemetriken kann nun durch Wiederholung der JMeter-Tests mit den in der ersten Spalte der Tabelle 10.1 angegebenen Benutzerzahlen überprüft werden. Nach jedem Testlauf wird der Tomcat-Server gestoppt und erneut gestartet um jeden Test unter gleichen Ausgangsbedingungen durchzuführen. Der direkte Vergleich zwischen den vorhergesagten und den tatsächlich erreichten Antwortzeiten wird durch das folgende Histogramm (Abb. 10.5) ermöglicht: 5000

Antwortzeit [ms]

4000

3000

2000

1000

0 1

15

20

30

40

50

60

70

80

# Benutzer MVA Prognose der Antwortzeit

Antwortzeit im Lasttest

Abb. 10.5. Vergleich der prognostizierten und der getesteten Antwortzeiten für unterschiedliche Laststufen.

Die hohe Übereinstimmung zwischen den durch Berechnung bzw. Testverfahren ermittelten Werten mag auf den ersten Blick erstaunen. Es darf dabei jedoch nicht vergessen werden, dass der Webservice einen äußerst schonenden Umgang mit den Hardwareressourcen pflegt. In praktischen Anwendungen ist dies so sicher nicht der Fall und die Komplexität ergibt sich gerade dann, wenn mittel- bis hochausgelastete Prozessoren und Festplatten modelliert werden müssen.

10.7 Die Simulation eines Webservice

247

Auch wenn dem implementierten Webservice eine sehr einfache Struktur zugrundeliegt, so ist mit dem bisherigen Vorgehen doch die prinzipielle Verwendbarkeit analytischer Modelle nachgewiesen. Allerdings erhalten wir durch den MVA-Algorithmus nur einige Durchschnittszahlen zu den Antwortzeiten und den Durchsatzraten. Es wäre hilfreich auch die Verteilung dieser Werte und das zeitliche Verhalten des Threadpools modellieren zu können. Dieser Bedarf führt uns zum Thema der Simulation von Infrastrukturen und Anwendungen.

10.7 Die Simulation eines Webservice Die in Kapitel 4 vorgestellten Konzepte zur diskreten Ereignissimulation wurden in Kapitel 7 für die Simulation fachlicher Prozesse verwendet. Nun soll die gleiche Methodik genutzt werden, um technischen Abläufe einer Anwendung besser verstehen zu können. Konkret soll das bisher durch Testverfahren untersuchte Performanceverhalten nun in einem Simulationsmodell nachgespielt werden. Dazu wird das ereignisorientierte Verfahren eingesetzt. Die Simulationsumgebung, die dazu entwickelt wird, stellt gewissermaßen ein Testlabor dar, in dem, unter Verzicht auf einen Lasttesttreiber und einen Applikationsserver, eine Performanceanalyse durchgeführt wird. Die Simulationsstudie wird unter Einsatz des Simulationsframeworks Desmo-J durchgeführt (Kreutzer und Page 2005) und das macht die Implementierung einiger Java-Klassen erforderlich. Das Framework unterstützt aber diese Entwicklung in sehr weiten Teilen und der Aufwand wird sich als sehr überschaubar herausstellen. Bevor jedoch die technischen Details erläutert werden, sind zunächst einige konzeptionelle Überlegungen anzustellen. 10.7.1 Die Komponenten des Modells Das System, welches wir durch ein Modell abbilden möchten, ist nicht schwer zu beschreiben. Es besteht aus einem Applikationsserver, der einen Webservice bereitstellt und einer Reihe von Benutzern, die auf diesen Service zugreifen. Wie bei allen anderen Formen der Modellbildung besteht auch hier die hauptsächliche Herausforderung darin, den für die Abbildung der realen Systemeigenschaften notwendigen Detaillierungsgrad zu erreichen ohne das Modell durch Nebensächlichkeiten und Ausnahmefälle zu überfrachten. Die Bedenkzeiten der Benutzer und die Laufzeiten des Webservice sind bedeutende Eigenschaften des zu simulierenden Systems und werden sich in dem Modell widerspiegeln müssen. Hingegen sind sowohl

248

10 Beispielszenario Webservice

bei den bisherigen Lasttests als auch bei den mit Hilfe des MVAAlgorithmus durchgeführten Analysen keine zweistelligen Antwortzeiten gemessen oder berechnet worden. In der Konfiguration des TomcatServers ist Timeout von 20 Sekunden für die HTTP-Verbindungen definiert. Daher wird wenigstens vorerst auf die Modellierung von Zeitüberschreitungen und die durch diese ausgelösten Ausnahmebedingungen verzichtet. Das Simulationsmodell soll Auskunft darüber geben, wie sich die Performance des Systems unter verschiedenen Lastprofilen verhält. Was genau unter der Performance zusammengefasst wird, ist noch zu klären. Sicher gehören dazu die bisher schon betrachteten Antwortzeiten. Besteht Informationsbedarf zu weiteren Performancemetriken (z.B. Länge der Warteschlange vor dem Threadpool), können diese in Form von Modellerweiterungen Berücksichtigung finden. Durch die strenge Objektorientierung von Desmo-J ist das ohne Schwierigkeiten möglich. Wichtig ist die genaue Festlegung und Beschreibung der in der Simulation verwendeten Entitäten und Ereignisse. Die Entitäten des Simulationsmodells stehen stellvertretend für jene Komponenten des Systems, deren Verhalten analysiert werden soll oder die einen unmittelbaren Einfluss auf die interessierenden Kenngrößen – in unserem Fall die Performancemetriken – haben. Modellierung der Webservice-Klienten

Die Anzahl der Nutzer des Webservice und deren Nutzungsverhalten legen die Last auf das System fest. Daher werden sie als Entität im System modelliert. Als beschreibende Attribute dieser Entität kommen in Frage: 1. Die Anzahl der während des Simulationslaufes von diesem Klienten bereits ausgeführten Anfragen. Dieses Attribut wird während der Simulation mit der Zahl der insgesamt je Klient durchzuführenden Anfragen abgeglichen. Die Werte dieses Attributes für alle beteiligten Klienten sind Teil des Systemstatus und legen fest, ob der Simulationslauf beendet werden kann. 2. Zeitpunkt, zu dem die aktive Anfrage ausgelöst wird. 3. Zeitpunkt, zu dem mit der Bearbeitung der aktiven Anfrage begonnen wird. 4. Zeitpunkt, zu dem die Bearbeitung der aktiven Anfrage abgeschlossen wird. 5. Aktivitätsstatus. Der Klient wartet auf die Antwort des WebService oder arbeitet mit dem Ergebnis der zuletzt gestellten Anfrage (Thinktime).

10.7 Die Simulation eines Webservice

249

Die Differenz zwischen den Zeitpunkten aus 3. und 2. ist die Wartezeit, die eine Anfrage in der Warteschlange des Threadpools verbringt, die Differenz zwischen 4. und 2. die tatsächliche Antwortzeit und zwischen 4. und 3. die Laufzeit des Webservice. Modellierung des Threadpools

Der Threadpool wird nicht als eigenständige Entität modelliert. Stattdessen wird jeder einzelne Workerthread als Entität gepflegt. Hier werden folgende Attribute aufgenommen: 1. Aktivitätsstatus: Der Thread ist gerade mit der Ausführung des Webservice beschäftigt (BUSY) oder unbeschäftigt (IDLE). 2. Zeitpunkt, zu dem der Workerthread gestartet wurde. 3. Zeitpunkt, zu dem der Workerthread mit der Bearbeitung einer Anfrage beginnt. 4. Die Zeit, die der Workerthread bislang aktiv mit der Bearbeitung von Anfragen beschäftigt war. Die Erfassung der Zeiten gestattet die Erhebung von Laufzeitstatistiken (Auslastung der Threads). Nachdem die beiden Entitäten des Modells beschrieben wurden, wenden wir uns nun den Ereignissen zu, mit denen das Verhalten des Systems im Verlaufe der Zeit simuliert wird. Modellierung eines Anfrageereignisses

Die Serviceanfragen der Klienten werden durch ein Ereignis RequesterRequestServiceEvent modelliert. Mit diesem Ereignis wird die Entität, die den Klienten beschreibt, verknüpft, so dass in der Behandlungsroutine des Ereignisses der Zugriff auf die Attributwerte möglich ist. Das Eintreten des Ereignisses repräsentiert also nicht das Eintreffen einer Anfrage am Webcontainer, sondern findet zu dem Zeitpunkt statt, zu dem der Klient die Anfrage auslöst. Modellierung der Anfragebearbeitung

Zwei Ereignisse sind in dem Modell für die Bearbeitung der Anfragen vorgesehen. 1. Jeder Workerthread, der nicht mit der Bearbeitung einer Anfrage beschäftigt ist (Status IDLE) soll in periodischen Abständen kontrollieren, ob eingegangene Anfragen auf eine Bearbeitung warten und sich gegebenenfalls einer dieser Anfragen widmen. Dies wird durch das Ereignis WorkerThreadLookUpEvent modelliert.

250

10 Beispielszenario Webservice

2. Hat ein Thread mit der Ausführung des Webservice begonnen, so wird das Ende der Bearbeitung durch das Ereignis WorkerThreadFinishService signalisiert. Durch einen Zeitgeber wird die Zeit bestimmt, an dem dieses Ereignis stattfinden soll. Der Zeitgeber wählt diese Zeit aus der gleichen Zufallsverteilung wie der modellierte WebService. Beide Ereignisse sind mit der Workerthread-Entität verknüpft. Nachdem die Einzelheiten des Modells nun festgelegt sind, kann seine konkrete Implementierung unter Verwendung des Desmo-J Frameworks erfolgen.

10.8 Das Webservice-Modell in Desmo-J Das Desmo-J Framework ist sehr mächtig und verfügt über eine hohe Zahl von Java Packages. Von diesen wird das Simulationsmodell des Webservice nur einen Teil verwenden und diese werden im Rahmen der nun folgenden Komponentenbeschreibungen erläutert werden. Im Mittelpunkt eines auf Basis des Desmo-J Frameworks erstellten Simulationsmodells steht eine Ableitung der Klasse Model aus dem Package desmoj.core.simulator. 10.8.1 Die Modellklasse Zu Beginn eines Simulationslaufs erzeugt Desmo-J eine Instanz der abgeleiteten Klasse. Dieses Modellobjekt ist bei der Instanzierung aller weiteren Modellkomponenten erforderlich. Ein solches Modellobjekt und die Vergabe eines Namens sind für den Aufruf der Konstruktoren fast aller Desmo-JKlassen obligatorisch. So ist gewährleistet, dass die Komponenten jederzeit Zugriff auf wichtige Modelldaten haben und die Reportfunktionen in Desmo-J die erstellten Berichte eindeutig benennen können. Die Basisklasse verfügt über drei abstrakte Methoden, die folglich im Simulationsprogramm zwingend zu implementieren sind. Eine dieser Methoden gibt eine Modellbeschreibung in Form einer Zeichenkette zurück. Die beiden anderen Methoden nehmen zentrale Initialisierungsaufgaben wahr. Die Methode init() ermöglicht die Erzeugung aller Komponenten, die im weiteren Verlauf der Simulation benötigt werden. Treiber der Simulation sind Ereignisse, die zu einem zukünftigen Zeitpunkt eintreten sollen. Es bedarf also mindestens eines ersten Ereignisses, damit eine Simulation überhaupt beginnen kann. Für die Erzeugung eines initialen Ereignisses und dessen Einfügen in die Eventqueue der Desmo-J-Simulationsengine ist die Methode doIni-

10.8 Das Webservice-Modell in Desmo-J

251

tialSchedules() zuständig. Die beiden Methoden sind in unserer Modelklasse WebServiceModel wie folgt implementiert. 1 /** initializes the model components */ 2 public void init() { 3 ... 4 // DISTRIBUTIONS: 5 thinkTimeStream = 6 new RealDistNormal(this, 7 "ThinkTimeStream", 8 0.0, 9 1.0, 10 true, 11 false); 12 13 webServiceServiceTimeStream = 14 new RealDistExponential(this, 15 "WebServiceServiceTimeStream", 16 WEBSERVICESERVICETIME_MILLIS, 17 true, 18 false); 19 20 // STATISTICS: 21 webContainerThreadPoolUtilization = 22 new Accumulate(this, 23 "threadpool utilization", 24 true, 25 false); 26 ... 27 // create queue for busy worker threads 28 busyWebContainerWorkerThreads = 29 new Queue(this, 30 "busy worker threads", 31 true, 32 false); 33 34 /* create worker threads */ 35 for (int i = 0;i < webContainerWorkerThreadsNumber; 36 i++) { 37 WorkerThread wt = new WorkerThread(this, i + 1); 38 idleWebContainerWorkerThreads.insert(wt); 39 }// end for i 40 41 stopCondition = new StopCondition(this, true); 42 43 }// end init()

In den Zeilen 5–18 werden die beiden Generatoren für zufällige Zeitdauern initialisiert. Für die Bedenkzeiten wird eine Normalverteilung angelegt. Zur Laufzeit wird diese genauso verwendet wie der Gaussian Random Timer in JMeter (siehe Unterkap. 10.4.2). Die Servicezeiten des modellierten Webservice folgen wie im realen System einer Exponentialverteilung. Dann wird in den Zeilen 21–25 zur Erfassung von Informationen der Threadpoolauslastung ein Statistikobjekt angelegt. Zwei Queues dienen der Aufnahme

252

10 Beispielszenario Webservice

der Workerthread-Entitäten. Die beschäftigten Workerthreads werden in der Queue busyWebContainerWorkerThreads verwaltet. Schließlich werden noch die Workerthreads erzeugt, in die idleWebContainerWorkerThreads eingefügt und ein Objekt angelegt, welches zur Laufzeit überprüft, ob die Simulation abgeschlossen ist. Die Simulation beginnt mit dem Einfügen der ersten Ereignisse in die Eventqueue: 1 /** schedules event notes on the event list */ 2 public void doInitialSchedules() { 3 double starttime = 0.0; 4 WorkerThread workerThread = (WorkerThread) 5 idleWebContainerWorkerThreads.first(); 6 7 while (workerThread != null) { 8 WorkerThreadLookUpEvent lookUpEvent 9 = new WorkerThreadLookUpEvent( 10 this); 11 double lookUpTime = 12 WORKERTHREAD_IDLEDELAY + starttime; 13 lookUpEvent.schedule(workerThread, 14 new SimTime(lookUpTime)); 15 16 // the next one 17 workerThread = (WorkerThread) 18 idleWebContainerWorkerThreads 19 .succ(workerThread); 20 // start not exactly at the same time 21 starttime = starttime + 10.0; 22 } 23 24 RequesterRequestServiceEvent lastEvent = null; 25 for (int i = 1; i 20 model.idleWebContainerWorkerThreads.length()) { 21 // it is enough to do 22 pauseTime = WebServiceModel.WORKERTHREAD_BUSYDELAY; 23 } else { 24 pauseTime = WebServiceModel.WORKERTHREAD_IDLEDELAY; 25 } 26 WorkerThreadLookUpEvent lookUpEvent = 27 new WorkerThreadLookUpEvent(model); 28 lookUpEvent.schedule( 29 workerThread, new SimTime(pauseTime)); 30 }// end eventRoutine()

Der Klient wird über den Abschluss der Anfrage informiert. Für den Workerthread wird ein erneutes Ereignis zur Kontrolle wartender Anfragen erzeugt. Der Zeitpunkt, an dem dieses Ereignis eintreffen soll, hängt

256

10 Beispielszenario Webservice

dabei von der noch anstehenden Last ab (Zeilen 19–25). Die Konstante ist im WORKERTHREAD_BUSYDELAY-Modell mit dem Wert 0 belegt. Dies bedeutet, dass der Workerthread bei noch wartenden Anfragen sich augenblicklich um deren Bearbeitung bemüht. Wie wird nun dafür gesorgt, dass die Ereigniskette nicht abbricht, bevor jeder simulierte Klient alle vorgesehenen Anfragen an den Webservice gesendet hat? Dafür sorgt der Klient, vertreten durch ein Objekt der Klasse ServiceRequester, selbst. Solange die Anzahl der bereits bearbeiteten Anfragen noch nicht dem Soll entspricht, wird ein neues Anfragenereignis erzeugt: 1 2 3 4 5 6 7 8 9 10 11

... if (isReady()) { model.getStopCondition().servedMessage(this); } else { // think a while... RequesterRequestServiceEvent arrivalEvent = new RequesterRequestServiceEvent(model); arrivalEvent.schedule(this, new SimTime(model.getThinkTimeStream())); } ...

Dabei wird auf die Einhaltung der Bedenkzeit geachtet (Zeile 9). 10.8.5 Ergänzende Elemente der Simulation Mit den beschriebenen Klassen kann nun bereits eine Simulation erfolgen. Das vollständige Programm enthält aber noch eine von ExperimentRunner abgeleitete Klasse. Diese erlaubt die Anlage von sogenannten SimRunListener, welche zur Laufzeit über die Veränderung von Metriken unterrichtet werden. Desmo-J stellt beispielsweise einige Charts zur Verfügung, die dieses Interface implementieren und bedeutende Performancemetriken visualisieren können. Hier ein Beispiel für die Verwendung: 1 class WebServiceModel 2 requestWaitTimesHistogram = 3 new Histogram( this, "Waittimes", 0, 15000, 4 50, true, false); 5 6 class WebServiceExperimentRunner 7 HistogramPlotter hpWT = new HistogramPlotter( 8 model.requestWaitTimesHistogram.getName(), c, 9 model.requestWaitTimesHistogram, 10 "ms", 360, 360, 365, 0); 11 12 class ServiceRequester 13 model.requestWaitTimesHistogram.update 14 ((serviceStartTime - requestStartTime));

10.8 Das Webservice-Modell in Desmo-J

257

In der Initialisierungsmethode der Modellklasse wird ein HistogrammObjekt angelegt (Zeilen 1–4). Dieses Objekt verwaltet die Statistik eines Histogramms; nicht dessen Visualisierung. Im ExperimentRunner wird dieses Histogramm mit einem HistogramPlotter verknüpft (Zeilen 6–10). Und schließlich aktualisiert der ServiceRequestor nach jeder abgeschlossenen Abfrage die Histogrammdaten und belegt diese mit der Zeit, die bei der Verarbeitung der Anfrage angefallen ist. Als sehr nützlich erweist sich auch die Möglichkeit, Attribute des Modells als benannte Objekte zu parametrisieren. Dann können sie zur Laufzeit über die Simulationsoberfläche verändert werden. Damit können verschiedene Simulationsalternativen getestet werden, ohne dass ein Neustart oder gar eine Anpassung des Programms erforderlich ist. Diese Belegungen der Attribute können auch als Konfigurationsdateien gespeichert werden und stehen damit jederzeit wieder zur Verfügung. Im Programm ist die Erstellung dieser parametrisierbaren Objekte denkbar einfach: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

protected int serviceRequestorNumber; protected int webContainerWorkerThreadsNumber; protected int requestsNumber; ... public Map createParameters() { Map pm = new HashMap(); pm.put("# of Clients", new MutableFieldAccessPoint( "serviceRequestorNumber", this)); pm.put("# of Worker Threads", new MutableFieldAccessPoint( "webContainerWorkerThreadsNumber", this)); pm.put("# of requests per Client", new MutableFieldAccessPoint( "requestsNumber", this)); return pm; }

In der Methode createParameters() werden die Anzahl der Benutzer, die Anzahl der Workerthreads und die Anzahl je Benutzer durchzuführender Anfragen an den Webservice als parametrierbare Objekte angelegt und können daher zur Laufzeit verändert werden. Die Abb. 10.6 zeigt die Desmo-J-Oberfläche mit den parametrierbaren Attributen.

258

10 Beispielszenario Webservice

Abb. 10.6. Desmo-J-Oberfläche. Werden Modellattribute im Programmcode als parametrierbar deklariert, können sie zur Laufzeit verändert werden. So können ohne zusätzlichen Kodierungsaufwand verschiedene Simulationsszenarien durchgespielt werden.

Mit dem implementierten Programm kann nun das Verhalten des Threadpools und des Webservice unter Lastbedingungen simuliert werden.

10.9 Simulationsergebnisse Analog zum Vorgehen in Unterkap. 10.6.2 für die quantitativen Modelle wird nun mit der ersten Analyse untersucht, welche Übereinstimmungen zwischen den realen und den simulierten Antwortzeiten unter verschiedenen Lastprofilen bestehen. Im Unterschied zum Lasttest können wir uns in der Simulation jedoch eine höhere Anzahl von Anfragen pro Klient erlauben. Die Dauer eines Lasttests bei 80 aktiven virtuellen Benutzern, die jeweils einhundert Anfragen an den Webservice stellen, beträgt über neun Minuten. Eine Simulation mit der gleichen Anzahl der Benutzer und 1000 Anfragen je Benutzer ist hingegen nach weniger als neun Sekunden beendet. Wie im Lasttest werden auch hier die Antwortzeiten in Form eines Histogramms dargestellt. Die Abb. 10.7 zeigt das Resultat dieser Simulationsstudie.

10.9 Simulationsergebnisse

259

5000

Antwortzeit [ms]

4000

3000

2000

1000

0 1

15

20

30

40

50

60

70

80

# Benutzer Antwortzeit im Lasttest

Antwortzeiten der Simulation

Abb. 10.7. Vergleich der simulierten und der getesteten Antwortzeiten für unterschiedliche Laststufen.

Diesen ersten Lackmustest besteht die Simulation mit Bravour; die simulierten Werte sind nahezu identisch zu den im Lasttest ermittelten. Allerdings ist der Erkenntnisgewinn nicht höher als im Fall der quantitativen Analyse. Ein Vorteil der Simulation ist erst dann gegeben, wenn die Verteilung der Zeiten sich in der Simulation ähnlich verhält wie im Lasttest. Festzustellen, ob dies tatsächlich der Fall ist, ist unser nächstes Untersuchungsziel. 10.9.1 Häufigkeitsverteilung der Antwortzeiten Die Antwortzeiten in beiden Varianten – Lasttest und Simulation – werden auf eine Genauigkeit von 100 ms gerundet. In einem Liniendiagramm werden diese gerundeten Antwortzeiten auf der X-Achse und die relative Häufigkeit, mit der diese Antwortzeit ermittelt wurde, auf der Y-Achse aufgetragen. Die Abbildungen 10.8–10.10 zeigen diese Häufigkeitsverteilungen für die Test- und Simulationsläufe mit 15, 30 und 80 Benutzern. Die Verteilungsdiagramme für die Lasttests weisen höhere Schwankungen auf als diejenigen der Simulation. Grundsätzlich ist aber auch hier wieder eine hohe Gleichförmigkeit zwischen den Ergebnissen der Simulation und denen des Lasttests erkennbar. Die Darstellung der kumulierten Häufigkeiten (siehe Abb. 10.10) zeigt, dass die exponentielle Verteilung der Laufzeiten des Webservice auf der Clientseite nicht mehr eingehalten werden. Hier dominieren nun eindeutig die Wartezeiten vor dem Threadpool.

260

10 Beispielszenario Webservice

15 Benutzer 0.1

0 0

1000

2000

3000 Simulation

4000

5000

6000

7000

JMeter

Abb. 10.8. Verteilung der Antwortzeiten des Lasttests und der Simulation für 15 Benutzer. 30 Benutzer 0.1

0 0

1000

2000

3000 Simulation

4000

5000

6000

7000

JMeter

Abb. 10.9. Verteilung der Antwortzeiten des Lasttests und der Simulation für 30 Benutzer.

10.9 Simulationsergebnisse

261

80 Benutzer 0.05

0.00 0

2000

4000

6000 Simulation

8000

10000

12000

JMeter

Abb. 10.10. Verteilung der Antwortzeiten des Lasttests und der Simulation für 80 Benutzer.

Die Abbildung 10.11 zeigt die kumulierte Verteilung der Untersuchung für 80 Benutzer. 80 Benutzer (kumulierte Sicht) 1.00

0.00 0

2000

4000

6000 Simulation

JMeter

8000

10000

12000

WebService

Abb. 10.11. Kumulierte Verteilung der Antwortzeiten des Lasttests und der Simulation für 80 Benutzer. Die zum Vergleich aufgeführten Laufzeiten des Webservice (ebenfalls kumuliert) genügen nach wie vor einer Exponentialverteilung.

262

10 Beispielszenario Webservice

10.10 Limitierte Warteschlangen Die Klasse desmoj.core.simulator.Queue aus dem Desmo-J Framework ist in unserer Simulation für die Verwaltung der Workerthreads und die Aufnahme der auf Service wartenden Anfragen verwendet worden. Diese Klasse stellt nicht nur die für diese Datenstruktur üblichen Funktionen zur Navigation, der Ermittlung des ersten oder letzten Elementes oder der Entfernung beliebiger Elemente bereit. Vielmehr führt sie auch eine Statistik über ihr Wachstumsverhalten. Für unsere Simulationsstudie ist das sehr hilfreich, besitzt doch die Warteschlange eine direkte Entsprechung im Echtsystem. Im Applikationsserver stauen sich eingehende Requests an, für die nicht sofort ein bearbeitender Thread zur Verfügung steht. Und dabei handelt es sich um eine echte Warteschlange. Wieviele Elemente sich in dieser Warteschlange durchschnittlich befinden, können wir sowohl mit Hilfe des MVA-Algorithmus, als auch durch die Queueklasse schätzen. Diese beiden theoretischen Größen sind in der Abb. 10.12 für die einzelnen Lastprofile ausgewiesen.

Länge der Warteschlangen 60

50

40

30

20

10

0 1

15

20

30 Queuelength MVA

40

50

60

70

80

Quelength Simulation

Abb. 10.12. Durch den MVA-Algorithmus und die Simulation ermittelte Anzahl wartender Requests für unterschiedliches Lastverhalten.

Die beiden Modelle kommen zu recht ähnlichen Schätzungen der Warteschlangenlängen. Doch wie stichhaltig sind diese Zahlen? Dieser Frage gehen wir mit einem einfachen Test nach. Der HTTP Connector des Tom-

10.11 Zusammenfassung

263

cat-Servers besitzt ein parametrierbares Attribut namens acceptCount. In der Dokumentation ist dieses Attribut wie folgt beschrieben: acceptCount: The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. Der Standardwert für dieses Attribut beträgt im Tomcat-Server 100. Da in der Simulation für den Fall von 80 gleichzeitig aktiven Klienten die maximale Länge der Warteschlange 63 beträgt, ist in dem Lasttest hier kein Problem zu erwarten. Für unseren Test reduzieren wir nun den Wert der maximal erlaubten Queuelänge im Tomcat-Server auf 50 und führen das JMeter-Skript erneut aus. Und tatsächlich protokolliert JMeter nun zu 355 der insgesamt 8000 Requests folgende Meldung: Error opening socket: java.net.ConnectException: Connection refused: connect,ServiceUsers 1–4 Erhöhen wir den Wert von acceptCount auf 60, tritt dieses Phänomen nicht wieder auf. Die theoretisch ermittelten Größen für den zu konfigurierenden Wert der Variablen acceptCount sind also plausibel. Auch im Simulationsprogramm kann die maximale Länge der Queue begrenzt werden. Ein erneuter Lauf des Simulationsprogrammes, während dessen ebenfalls nur 50 wartende Anfragen zugelassen werden, zeigt aber signifikante Abweichungen, was die Anzahl der wegen einer Überfüllung der Queue abgewiesenen Anfragen betrifft. Statt 355 sind dies nach Schätzung der Simulation 2070.

10.11 Zusammenfassung Am Beispiel eines einfachen Webservice sind eine Reihe der im Buch vorgestellten Verfahren und Werkzeuge verwendet worden. Die Laufzeiten des Webservice wurden unter Einsatz des in Kap. 8 vorgestellten Performancemonitors ermittelt, ohne dass dazu ein programmatischer Aufwand entstanden ist. Das Performanceverhalten des Webservice unter verschiedenen Laststufen wurde mit dem MVA-Algorithmus prognostiziert und mit den Ergebnissen des Testes abgeglichen. Anschließend wurde auf Basis des Desmo-J Frameworks ein Programm zur diskreten Ereignissimulation entwickelt, mit dem der Webservice nachgespielt werden kann. Unter den einfach gestalteten Rahmenbedingungen und dem bewussten Verzicht auf Serviceaufrufe mit intensiver Belastung der Hardware konnte dabei eine enge Übereinstimmung zwischen den tatsächlich gemessenen Perfor-

264

10 Beispielszenario Webservice

mancemetriken und den durch die Simulation geschätzten erreicht werden. Damit Simulationen auch in jenen Situationen eingesetzt werden können, in denen eine oder mehrere Hardwareressource die natürlichen Engpässe darstellen, müssen weitaus komplexere Modelle entwickelt werden. Hier versteht sich das Kapitel auch als Anregung an Leser und Leserinnen, die diesem Thema grundsätzlich aufgeschlossen gegenüberstehen, vielleicht im Rahmen einer Open-Source-Initiative die Entwicklung einer solchen Software voranzutreiben.

Literatur Kreutzer W, Page B (2005) Simulating Discrete Event Systems with UML and Java. Shaker Verlag Aachen Seidmann P, Schweitzer P, Shalev-Oren S (1987) Computerized Closed Queueing Network Models of Flexible Manufacturing Systems. Large Scale Systems, Vol. 12, No. 4:91–107

Sachverzeichnis

A

D

Anforderung, 83 funktionale, 85 nicht-unktionale, 85 Antwortzeit Statistik, 92 Arrival Theorem, 55 Axis2, 238

Bedenkzeit, 51, 88, 121 Begriffsbildung, 44 Bottleneck. siehe Engpassressource Busytime, 47 Byte Code Engineering Library, 182 Byte-Code-Instrumentierung, 179

Delay Ressource, 244 Desmo-J, 247 Modellklasse in, 250 DESMO-J, 76 Diskrete Ereignissmulation, 71 Aktivität, 74 Behandlungsroutine, 76 Entität, 72 Ereignis, 74 Ereignisliste, 76 Prozess, 74 Ressource, 73 Weltsichten, 73 Zufallszahlen, 76 Durchsatz, 47, 95 Dynamisches System, 65

C

E

Comprehensive Perl Archive Network, 227 Contention, 200

End-To-End Antwortzeit, 89 Engpass, 54 Engpassressource, 58

B

266

Sachverzeichnis

Enterprise Server Bus, 113 Ergonomie, 91 F Forced Flow Law, 49 G Geschäftsprozessoptimierung, 129 GPRS Benchmark, 217 Grundlast, 49 H HiPODS, 109 Histogramm, 217 HProf, 169 HTTP Code 304, 226 I iostat, 235 J Java Agent, 197 Java Classloader, 183 Java Classverifier, 174 Java Deadlock, 174 Java Profiler, 49, 159 Java Virtual Machine Profiler Interface, 172 Java Virtual Machine Tools Interface, 196 JMeter, 94 L Lasttest. Siehe Performancetest Lasttyp, 113 Linux, 9 Little's Law, 50 log4J, 161 M Mean Value Analysis, 53 Mean-Time-To-Failure, 97 Mean-Time-To-Repair, 97

Mengengerüst, 87 Messframework, 160 Modellbildung, 247 N netstat, 235 Nichtlineares System. Siehe Dynamisches System O On Demand Performance Advisor, 107 Hardwareauswahl, 115 Lastszenario, 118 MVA-Erweiterung, 116 Performanceprojektion, 117 Performanceziel, 120 Sicherheitszuschlag, 121 Open Source, 9 P Performanceanforderungen, 7 Performancebudgetierung, 30 Performancetest, 32 Testdurchführung, 40 Testplan, 33 Testvorbereitung, 35 Perl, 227 Perl::PDQ, 126 Profiler, 7 Profileragent, 172 Profiling, 166 Prozessanalyse, 141 What-If Analyse, 147 Prozessmodellierung, 133 Prozessmonitoring, 132 Prozessoptimierung, 132 Prozessplanung, 133 Q Queue, 45, 46 Queueing Network, 45 Queueing-Netzwerk, geschlossenes, 55 offenes, 55

Sachverzeichnis Queuelength, 47 R Regressionsanalyse, 216 Response Time Law, 51 Ressource, 45 Risikomanagement, 8 S Sättigungspunkt, 54 Secure Socket Layer, 114 Service Level Agreement, 102 Servicezeit, 45 Servicezeitbedarf, 47 Simulation Modellbegriff, 70 Systembegriff, 70 Systemstatus, 70 Simulationsengine, 72 Simulationsmodell, 67 Simulationszeit, 252 Skalierbarkeit, 45, 100 SLA-Management, 7 Sonoma, 109 Streudiagramm, 211 Systemdurchsatz, 47 Systemmodellierung, 71

267

Testvorbereitung, 35 Treemap, 223 U Utilization, 47 Utilization Law, 47 V Verfügbarkeit, 95 Verweilzeit, 47 Visualisierung, 215 Automatisierung der, 227 vmstat, 235 W Warteschlangenmodell, 108 Warteschlangentheorie, 43, 45 Wartezeiten, 45 Webservice, 243 Warteschlangenmodell eines, 243 WebSphere Business Modeler, 132 Aktivität, 133 Business Item, 133 Dynamische Analyse, 145 Ressource, 134 Winter Simulation Conference, 81

T

Z

Testdurchführung, 40 Testplan, 33

Zusammenarbeit, 11 Zuverlässigkeit, 99