Typischerweise treten Systemengpässe besonders dann auf, wenn eine neue Applikation oder ein neues Release installiert wird. Die klassischen Anzeichen sind, dass sich Web-Seiten nicht erreichen lassen, User sich nicht mehr einloggen können oder überlastete Server und Anwendungen ungewöhnlich langsam reagieren. Mit der Verteilung von Software auf unterschiedliche Systeme, insbesondere bei großen Architekturen, entstehen sehr komplexe, kaum noch zu überschauende IT-Landschaften. Selbst die Entwickler kennen nur noch die von ihnen bearbeiteten Teilbereiche, größere Zusammenhänge aber bleiben verborgen. Treten innerhalb des Gesamtsystems Performance-Probleme auf, ist es dann sogar für Experten schwierig, die Flaschenhälse (Bottlenecks) zu finden und ihre Ursachen zu beseitigen. In der unternehmerischen Praxis fehlen dafür häufig die erforderlichen personellen Ressourcen und das Know-how.

Im Dschungel der IT-Landschaft

Die Suche nach den Performance-Problemen gleicht dann einer Odyssee durch den Dschungel der Systemlandschaft. Die Ursachen werden nicht richtig erkannt, zusätzliche Hardware soll den Engpass beseitigen. Im besten Fall wird damit das Leiden gelindert, aber nicht beseitigt. Die Erfahrung aus zahlreichen Projekten zeigt, dass deutlich mehr als die Hälfte der Performance-Probleme durch Software verursacht werden: mangelhafte Programmierung oder falsche Konfigurationen der einzelnen Komponenten.

Effektiver als das intuitive Suchen nach der Nadel im Heuhaufen sind systematisierte, methodische Performance-Analysen, die einen Bottleneck simulieren, während gleichzeitig die Antwortzeiten des Systems gemessen werden. Die Suchstrategie folgt dabei einem Drill-down-Ansatz: Das Gesamtsystem wird, ausgehend von ersten, oberflächlichen Tests, immer tiefer und detailreicher durchdrungen. Anhand der gewonnenen Testdaten lassen sich einzelne Komponenten isolieren, mittels Referenzwerten prüfen und gegebenenfalls anpassen.

Um einen Engpass nachhaltig zu beseitigen, müssen auch dessen Ursachen erforscht werden. In Betracht kommen beispielsweise: Benutzungsfehler, Hardwaredefekte, verkehrtes Hardware-Sizing, falsch eingesetzte Technik, Architektur- und Softwareprobleme sowie Seiteneffekte, beispielsweise verursacht durch benachbarte Applikationen.

Fehler summieren sich

In der Praxis gibt es nur selten einen einzigen Bottleneck. Es sind vielmehr zahlreiche kleine, manchmal auch harmlos erscheinende Fehler, die sich summieren und die Antwortzeiten des Systems verlängern. Das Tuning des Gesamtsystems ist ein iterativer Prozess, der abgebrochen werden sollte, wenn die gewünschten Zielwerte erreicht sind.

Die Qualität der Performance-Analyse hängt entscheidend davon ab, wie genau eine Bottleneck-Situation nachgebildet werden kann. In der Regel wird eine Performance-Analyse mit einem Lasttest gekoppelt, der wirklichkeitsnah die reale Situation simuliert. Dies ist nicht nur zeitintensiv, sondern muss auch sorgfältig vorbereitet und geplant werden. Zu klären ist beispielsweise, wie das Gesamtszenario definiert sein muss, wie genau das eingesetzte Tool die Anwender nachbilden kann, mit welcher User-Anzahl man testen soll und welche Geschäftsprozesse einzubeziehen sind. Empfehlenswert sind an dieser Stelle auch Automatisierungs-Tools, um Testläufe rasch und in gleich bleibender Qualität wiederholen zu können.

Die Qualität der Analyse wird ferner davon beeinflusst, wie genau sich ein Ereignis einem Zeitpunkt zuordnen lässt. Schließlich geht es noch darum, die ermittelten Korrelationen möglichst exakt zu interpretieren. Hilfreich sind dabei Metriken, die in der einschlägigen Fachliteratur zu finden sind. Sie dienen als Kompass und geben Hinweise auf mögliche Engpässe. Die Reichweite ist jedoch begrenzt: einerseits durch die Unterschiedlichkeit der Systeme, die nicht in universal gültige Werte gefasst werden können, andererseits durch die limitierte Anzahl der verfügbaren Metriken. Weil die Systeme so komplex sind, können die Daten ohne Expertenwissen und einschlägige Erfahrung nicht fachgerecht interpretiert werden. Beispielsweise bietet schon ein Applikations-Server unzählige Parameter und Konfigurationsmöglichkeiten, so dass auch Experten gelegentlich an die Grenzen ihres Wissens stoßen. In solchen Fällen reduziert sich der Gewinn neuer Erkenntnisse auf seine archaische Form: Ausprobieren und abwarten, was passiert.

Techniken der Datenerfassung

Für den Test der Performance ist letztlich die Antwortzeit des Systems während der Simulation entscheidend. Im Kern messen die hier vorgestellten Techniken nichts anderes, sie unterscheiden sich aber in der Messtiefe. Die Wahl der Technik hängt vom Testziel ab. Ein Beispiel: Soll ermittelt werden, wie sich die Antwortzeiten im Verhältnis zur Zahl der Benutzer verhalten, ist die Betrachtung des Systems aus der Perspektive des Endbenutzers unter Umständen völlig ausreichend. Bei einer solchen End-to-End-Sicht wird die Zeit gemessen, die benötigt wird, bis die komplette Antwort auf eine vom Benutzer an das System gerichtete Anfrage zurückgesendet wird.

Betrachtet man neben der reinen Antwortzeit auch die allgemeine Auslastung der Systeme zum gleichen Zeitpunkt, so könnte man dieses erweiterte Messszenario auch als "Edge-to-Edge"-Monitoring bezeichnen. Viele Performance-Tools bieten zudem die Möglichkeit, die gemessene Gesamtantwortzeit in einen Client-, einen Server- und einen Netzanteil aufzuspalten. Dies liefert gute Hinweise für eine tiefer gehende Analyse. Will man jedoch die Frage beantworten, wo die Zeit eigentlich genau bleibt, so muss man sich mit einem so genannten Profiler auf die Spur etwaiger Bottlenecks begeben. Ein Profiler ist ein Analyse-Tool, das die Gesamtantwortzeit in die kleinstmöglichen Teilschritte zerlegt: Es zoomt sich tief in eine Applikation und deckt Schwachstellen auf, die nur in solch kleinem Maßstab offensichtlich werden. Profiling setzt allerdings ein hohes Maß an Experten-Know-how voraus und ist meist mit hohem Aufwand verbunden. Es wird seltener in proaktiven Testphasen eingesetzt, sondern meistens erst dann, wenn es bereits Performance-Probleme im produktiven Umfeld gibt.

Kommunikation ist der Schlüssel

Die Komplexität der IT-Systeme spiegelt sich in Form differenzierter und arbeitsteiliger Rollen beziehungsweise Funktionen innerhalb der IT-Abteilungen wider. Abhängig von der jeweiligen Unternehmenskultur sind die einzelnen Unterabteilungen bisweilen streng getrennt und konkurrieren nicht selten um die stets knappen Ressourcen. Optimierungsstrategien, die sich allein auf die technische Dimension der Performance beschränken, sind zum Scheitern verurteilt. Weil Bottleneck-Probleme immer das Gesamtsystem betreffen, müssen organisatorische und kommunikative Strukturen eingerichtet werden, die die Verantwortlichkeiten klar regeln und ein interdisziplinäres Ar- beiten und Kommunizieren erlauben.

Ein Tagebuch empfohlen

Um diese Probleme zu lösen, haben sich in der Praxis zwei Bausteine bewährt: ein Performance-Tagebuch und ein moderierter Dialog. Das Tagebuch hält sämtliche Änderungen und Aktionen während des Projekts fest, womit die einzelnen Schritte für alle Mitglieder eines Performance-Projekts transparent und nachvollziehbar bleiben. Außerdem dient es dazu, im Fall eines Wiederholungstests das System zurück in den ursprünglichen Zustand zu versetzen. So trivial dies zunächst erscheinen mag, in der Praxis zeigt sich, wie hilfreich ein Tagebuch sein kann - aber auch, wie schwierig es ist, konsequent eine lückenlose Dokumentation zu führen.

Für den Dialog übernimmt die Rolle des Moderators idealerweise derjenige, der den Test ausführt. Er ist nicht nur verantwortlich für das Gesamtprojekt, sondern hält auch die Fäden in der Hand, treibt den Prozess voran und strukturiert eine zielführende Kommunikation.

Aufgaben des Moderators

Anhand der Testergebnisse entscheidet der Moderator, für welche IT-Abteilung die vorliegenden Daten interessant sein könnten, um die entsprechenden Meetings zu koordinieren. Er bereitet außerdem die erzielten Ergebnisse als Diskussionsgrundlage auf. Das ist deshalb wichtig, weil ein Entwickler nicht nur eine andere Fachterminologie, sondern auch einen anderen Blickwinkel hat als beispielsweise ein Datenbankadministrator oder Netzwerkspezialist. Insofern fördert ein Moderator den interdisziplinären Austausch zwischen den Arbeitsgruppen und fungiert quasi als Dolmetscher. Voraussetzung dafür ist, dass der Zugang zu allen relevanten Informationen sichergestellt ist und die verschiedenen IT-Gruppen den Moderator unterstützen.