Sparen mit Application Performance Engineering

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.

Abbildung 2: Die Arbeitsweise von Diagnosewerkzeugen der zweiten Generation.

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.

Diagnosedaten effizient austauschen

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.