Thomas Mahringer ist Senior Performance Architect & Training Manager bei dynaTrace Software.

Praxisorientiertes, kosteneffizientes Application Performance Engineering bedingt, dass Architektur- und Leistungsschwachstellen früh erkannt und Diagnosedaten effizient zwischen allen Beteiligten ausgetauscht werden. Werden indes die fachlichen Anforderungen zu stark priorisiert und die Performance zu stiefmütterlich behandelt, führt ein unternehmenskritisches Software-Projekt nicht selten auf dem direkten Weg in die Verdammnis. Ein Szenario, das jedem Entwickler bekannt vorkommen dürfte.

Schon die Erfassung aller funktionalen und nicht-funktionalen Anforderungen sowie deren Nachverfolgbarkeit (Traceability) im Rahmen des Requirements Engineering bedingt die intensive Zusammenarbeit unterschiedlicher Stakeholder in einem Software-Projekt. Zunächst müssen die funktionalen Anforderungen verstanden und - basierend auf der geeigneten Software-Architektur - in geeignete Abläufe gegossen werden. Im Erwartungsdreieck «Ressourcen - Anforderungen - Qualität» wird dabei den nichtfunktionalen Anforderungen oft zu wenig Priorität eingeräumt. Vor allem die Performance wird oft vernachlässigt, da sie als zusätzliches «Deliverable» empfunden wird, das man auch in späteren Phasen nachreichen kann.

Ein fataler Fehler. Denn besonders in modernen Enterprise-Systemen, in denen viele Komponenten ineinander greifen und Frameworks einen guten Teil der Basis-Software-Infrastruktur abdecken, ist exaktes Verständnis der Performance-Implikationen dieses Zusammenspiels nötig. So kann zum Beispiel ein in serviceorientierte Komponenten zerlegtes System hervorragend wartbar, gut verständlich, leicht konfigurierbar und gut deploybar sein. Es mag überdies auch bei 100 konkurrenzierenden Anwendern hervorragend funktionieren. Doch wollen 500 User gleichzeitig damit arbeiten, treten plötzlich Performance- oder Speicherprobleme auf.

Grund für solche Probleme ist das Vorhandensein einer Art «transitiver Hülle» der in diesem System beteiligten Komponenten: Das Verhalten der Komponente N hat erheblichen Einfluss auf das Verhalten der Komponente N+M und umgekehrt. Die Gesamtleistung des Systems korreliert direkt mit dessen Gesamtarchitektur. Und zwar nicht nur mit der statischen Architektur, sondern vor allem auch mit dem anwendungsbezogenen Ablauf durch das Gesamtsystem. Abbildung 1 verdeutlicht den Sachverhalt: Jede Benutzeraktion löst einen Ablauf durch verschiedene verteilte Komponenten aus.

Diese Korrelation zwischen Leistung und Architekur bedingt, dass die dynamischen Zusammenhänge des Systems und deren Auswirkungen auf die Systemleistung bereits während der Architektur- und Designphase verstanden werden müssen. Eine zu späte Berücksichtigung führt unweigerlich zu umfangreichem Refactoring und damit zu neuerlichen Durchläufen von Entwicklung, Test und Integration. Die Folge sind wesentlich höhere Kosten.

Performance ist also kein «Deliverable», das nach der Umsetzung der fachlichen Requirements nachgeliefert werden kann. Und schlechte Performance führt nicht nur zu unzufriedenen oder verlorenen Kunden, sondern auch zu höheren Hardware- und Software-Investitionen.

Zum besseren Verständnis der dynamischen Zusammenhänge eines Systems reichen klassische Ansätze wie Profiling oder Monitoring alleine nicht aus. Profiling ist in Produktionssystemen nicht einsetzbar und beide Herangehensweisen liefern im Wesentlichen statistische Durchschnittswerte. Damit bereits in frühen Phasen das dyna-mische Verhalten der Architektur auch hinsichtlich der Performance nicht nur statistisch beobachtet, sondern validiert und optimiert werden kann, müssen die einzelnen Abläufe vom Beginn einer (Benutzer)aktion, über die verschiedenen verteilten Komponenten hinweg, bis hin zum Data Store nachvollziehbar gemacht werden. Besondere Herausforderungen dabei sind die (Un)Übersichtlichkeit der Datenmengen respektive das Nachverfolgen über verteilte JVMs (Java Virtual Machines) und .NET CLRs (.NET Common Language Runtimes) hinweg.

Es ist leicht nachvollziehbar, dass in einem System mit mehreren verteilten und womöglich geclusterten Komponenten eine rein statistische Rekonstruktion der einzelnen Traces aussichtslos ist. Nötig ist vielmehr ein Mechanismus, der den Zusammenhang der einzelnen verteilten Abläufe erkennt und protokolliert, ohne dabei das zu analysierende System zu überlasten. Zweiter Teil, neben dem Protokollieren der Einzeltraces, ist die Möglichkeit, die Daten auswerten zu können, ohne sich in den grossen Datenmengen zu verlieren. Hier kommen Diagnosewerkzeuge der zweiten Generation ins Spiel. Sie können die gesammelten Daten der Einzeltransaktion (Einzeltrace) samt der zugehörigen Kontextinformation (Parameter-Werte, Rückgabewerte, HTTP-Parameter-und Attribute, Session-Attribute usw.) analysieren oder auf Wunsch auch statistisch aggregieren (siehe Abbildung 2).

Diagnose-Werkzeuge der zweiten Generation entlasten das zu analysierende System, indem sie die Auswertung der Einzeltraces, Ressourcen-Informationen (Memory, Pools usw.) sowie die statistische Auswertung auf einen Correlation-Server auslagern. Dieser überträgt alle relevanten Informationen dauerhaft in ein Repository und schnürt bei Bedarf Diagnose-Packages, die sodann an die entsprechenden Stakeholder versendet werden können.

Neben dieser technischen Fragestellung des Application-Life-Cycles ist die organisatorische Komponente von entscheidender Bedeutung. Denn für hohe Effizienz ist es wichtig, dass die gewonnenen Diagnosedaten allen Stakeholdern aller Phasen zeitnah zur Verfügung stehen. Damit sprechen alle die gleiche Sprache und können Ergebnisse interaktiv austauschen und verfeinern.

So können beispielsweise Probleme, die in der Produktion unter Last auftreten und sich von den Entwicklern kaum oder nur mit extremem Aufwand reproduzieren lassen, anhand der Einzeltraces wesentlich schneller punktgenau lokalisiert werden. Der Austausch und die Analyse von mehreren GByte grossen Logfiles entfällt, das «Fingerpointing» zwischen Betrieb und Entwicklern sinkt und die Mean Time To Repair wird drastisch verkürzt.

Die Architektur der zweiten Generation lässt dieses Wunschszenario zur Realität werden: Die Daten können ebenso vom Betriebsteam (Service- und Ressourcen-Monitoring) als auch vom QA-Team (Test und Triage) oder den Architekten/Entwicklern (Diagnose und Profiling) verwendet werden. Jeder Beteiligte erhält die für seine Aufgabe nützlichste Abstraktionsebene. Durch die Einzeltraces liegen den Entwicklern schlussendlich genügend Informationen vor, die ihnen eine exakte Problemlokalisierung ermöglichen, ohne dass sie die Problemfälle reproduzieren müssen.

Zuletzt muss erkannt werden, dass auch die Konfiguration des Diagnose-Systems zwingend in den Application Lifecycle eingebettet werden muss.
Parallel zum eigentlichen Softwaresystem wird die Monitoring/Diagnose/Analyse-Konfiguration schrittweise vorbereitet, definiert, getestet und dann in die Produktionsumgebung deployed. Die Monitoring/Diagnose/Analyse-Ergebnisse jeder Phase fliessen zurück in vorhergehenden Phasen. Natürlich verursacht die Verwendung verschiedener Werkzeuge und Methoden (Profiling, Diagnose, Logging, Monitoring) Medienbrüche im Kommunikationszyklus und beeinträchtigt damit die effiziente Datenweitergabe, Datenauswertung und somit die Problemlösung. Ein übergreifender Ansatz und ein zentraler Konfigurationsmechanismus für sämtliche beteiligten JVMs oder CLRs ist daher unerlässlich.

Praxisorientiertes und kostensparendes A-pplication Performance Engineering und Management bedingt die frühzeitige Erkennung von Architektur- und Performance-Problemen, einen effizienten Austausch der Diagnosedaten, schnelle Fehlerlokation und eine zentrale, in mehreren Umgebungen verwendbare Konfiguration des Monitoring/Diagnose-Systems. Alles zusammen ergibt in der Entwicklung und im Betrieb komplexer Software-Systeme ein markantes Sparpotenzial bei Personal-, Hardware- und Software-Ressourcen.

Begriffserklärung

Tools, die dieser Bezeichnung gerecht werden, vereinen Profiling-, Tracing-, Diagnose- und -Monitoring-Funktionen und bieten damit erstmals allen Stakeholdern des Application Lifecycles eine gemeinsame Sprache und ein gemeinsames Kommunikationsmittel. Ihre Architektur ermöglicht ein laufendes Mitverfolgen, Aufzeichnen und Auswerten von Benutzertransaktionen, ohne das überwachte oder diagnostizierte System zu überlasten.