Ähnlich einem mechanischen Uhrwerks muss aber eine Vielzahl von Einzelkomponenten perfekt zusammen spielen, damit eine Applikation stabil und schnell ist. Dieser Vergleich verdeutlicht zudem, dass Optimierungen zwar auch ganz am Schluss mit ein paar Stellschrauben durchgeführt werden können; nachhaltige und intelligente Performance wird aber bereits auf dem Reissbrett geplant und definiert.

Wichtigstes Merkmal eines effektiven APM Prozesses ist aber der Grand an Effizienz: nur wenn der Aufwand gering (relativ zum Ergebnis) ist, wird sich ein APM durchsetzen. Sowohl Manager wie auch Mitarbeiter wollen und können sich keinen absoluten Mehraufwand leisten. Ein hoher Automatisierungsgrad ist hierzu der Schlüssel.

 

Damit diese Effizienz gewährleistet wird, muss aber auch skaliert werden: in die Tiefe wie in die Breite. Daher ist der LifeCycle Gedanke die Grundlage eines jeden APM Prozess. Es geht nicht darum eine zentrale Abteilung mit x Performance Spezialisten aufzubauen, sondern den bestehenden Mitarbeitern die Mittel in die Hand zu geben, um Performance und Stabilitätsfragen in ihrem Umkreis zu beantworten. Zudem müssen team-/abteilungsübergreifend die offenen Fragen besprochen werden und Lösungen interaktiv gefunden werden. Der Nutzen in einem solchen Szenario überwiegt dabei den Aufwand erheblich und ist durch zahlreiche Beispiele belegt.
 

Die Rechnung dabei ist einfach und an einem Beispiel veranschaulicht:
Wieviel ein Fehler/Ausfall kostet, hängt davon ab wie früh und wie schnell er gefunden wird. Ein Performance Problem, welches bereits während der Entwicklung gefunden wird, kostet ca. 1/1000 dessen, was es in der Produktion verursacht hätte. Umgekehrt, ein Produktionsausfall bindet rasch teure Spezialisten für Tage und Wochen. Eine schnelle root cause Analyse des Problems ist daher zwindend.

Über den LifeCycle gesehen, müssen folgende Punkte für ein APM berücksichtig werden:

Nicht-funktionale Anforderungen an die Applikationen gehen sehr oft vergessen. SLAs, ein Mengengerüst über Anzahl Transaktionen und User und der geschätzte Ressourcen Bedarf sind aber wichtige Kenngrössen, die unbedingt erfasst werden sollten. Dies nicht nur aus technischen Überlegenen (Design, Architektur, Erfolgskriterien für Testing), sondern auch aus betriebswirtschaftlichen Gründen. Denn, eine höhere Performance kostet grundsätzlich mehr und es macht keinen Sinn Geld für etwas auszugeben ohne ersichtlichen Mehrwert für die Unternehmung.

In der Entwicklung konzentrieren wir uns vor allem auf automatisierte Performance Reports. Diese werden am besten in eine Continuous Intergration (CI) Umgebung generiert.

Die Adressierung von Performance Problemen in der Entwicklung ist besonders nachhaltig, da zu diesem Zeitpunkt die Engpässe sehr viel einfacher und kostengünstiger zu optimieren sind als zu späteren Zeitpunkten. Eine weniger ideale Implementierung eines Frameworks (z.B. Hibernate) ist ein sehr häufig angetroffenes Beispiel für „einfache“ Probleme mit grosser Wirkung. Aber auch extensives Remoting, auf dem Entwicklerarbeitsplatz noch unauffällig, später aber in einer verteilten Umgebung tödlich, ist ein typisches Beispiel für Probleme, die wir häufig antreffen. Und je früher diese Probleme gefunden werden, desto einfacher sind sie zu lösen.

Zusammen mit unserem Partner Codecentric bieten wir langjähriges und explizites Knowhow an.

Auch hier gilt, dass nur eine geplante und intelligente Herangehensweise zum Erfolg führt und Kosten minimiert: welche Applikationen müssen/können/sollen getestet werden? Zu welchem Zeitpunkt wird getestet? Welche Last soll erzeugt werden? Welche UseCases sind sinnvoll? Wie können sinnvolle UseCases definiert werden?

Dies sind nur ein paar der wichtigen Fragen. Entscheidend ist aber auch, wie die Last- und Performance Tests analysiert und ausgewertet werden. Dabei geht es nicht nur um die Auswertung und statistische Verarbeitung der Antwortzeiten. Welche Komponente/Klasse/Methode hat am meisten Zeit verbraucht? Gibt es unter Last Synchronisationsprobleme? Wie ist der Memory Verbrauch einer Transaktion? Wieviel Datenbank Anfragen wurden gemacht? Wie viele Remote Calls? Wie skaliert die Applikation unter Last? U.a.

Antworten auf diese Fragen sind entscheidend, um einerseits dem Entwickler qualifizierten Input für weitere Optimierungen zu geben und andererseits für das Sizing der Produktion. Unter Sizing ist hier nicht (nur) die Stärke der Hardware gemeint, sondern auch die Einstellungen des Applikationsserver (Memory der JVM, Session Pool, Wahl des Garbage Collectors, DB connectors etc).

Die Ergebnisse der Tests werden nicht nur mit früheren Tests verglichen (Regressions Analyse), sondern fliessen auch in das Capacity Management ein. Mit relativ einfachen Q-Modellen kann man das spätere Antwortzeitverhalten erstaunlich genau vorhersagen.

Auch die beste Vorbereitung kann unvorhergesehene Fehler in der Produktion nicht verhindern. Und wird es in absehbarer Zeit auch nicht können. Gewisse Rahmenbedingungen sind einfach nicht bekannt. Umso wichtiger ist das rasche und genaue Lokalisieren dieser Probleme, damit eine schnelle Lösung möglich wird. Denn typischerweise geht am meisten Zeit bei der Lokalisierung der Fehler verloren; viele Tage, sogar Wochen kann dies dauern, was entsprechend viel Ressourcen verschlingt und das Vertrauen der Endbenutzer nachhaltig beeinträchtigen kann.

 

Wichtige Fragen in der Produktion sind:

 

Daraus abgeleitet sind folgende Punkte für ein modernes Monitoring- und Analyse System ausschlaggebend:  

 

a)   Einfach und schnell
Dies ist nur durch einen sehr hohen Automatisierungsgrad zu erreichen. Automatische Instrumentierung und Fehlererkennung sowie die Gruppierung von Business Transaktionen, sind hier die entscheidenden Stichworte, um mit reduziertem Aufwand einen maximalen Nutzen zu erzielen. Das Monitoring einer typische Produktionsumgebung mit -zig oder sogar hunderten von Servern kann manuell nur mit grossem Ressourceneinsatz auf einem sinnvollen Stand gehalten werden. Abgesehen davon ist es für den Betrieb in den meisten Fällen nicht möglich, eine Applikation zu instrumentieren und für den Entwickler ist eine spezielle Instrumentierung für den Betrieb ein zusätzlicher und ungewollter Aufwand.

 

b)   Weit und breit
Gemeint ist hier eine Vogelperspektive auf das aktuelle Geschehen in der Produktion. Grosse Zusammenhänge sollen klar und eindeutig dargestellt werden. Blinde flecken werden somit vermieden. Ein übersichtliches GUI mit klaren Symbolen zeigen rasch auf, in welcher Ecke es brennt.

 

c)   Tief und Detailliert
Im Gegensatz zu oben, ist hier eine Perspektive mit einem Vergrösserungsglas gemeint. Die kleinsten Details sollten bei Bedarf rasch sichtbar gemacht werden. Dies ist für eine schnelle Analyse der eigentlichen Ursache unabdingbar. Durch Automatisierung werden Details teilweise auch direkt an die Oberfläche befördert.

d)   Business Transaktionen
Entscheidend für das Verständnis moderner Applikationen sind die Auswirkungen auf die Enduser. Wer ist wann durch welchen Fehler betroffen? Umgekehrt, nur wenn User von einem Problem wirklich direkt betroffen sind, lohnt eine Analyse. Business Transaktions-Monitoring ist das richtige Mittel um effiziente Optimierung durchzuführen.

 

e)   Verteilt und dynamisch

Ein modernes Monitoring Tool ist dafür ausgelegt, hochdynamische und verteilte Applikationen zu verstehen. Heutige Applikationen basieren höchstens noch logisch auf 3 Tiers. Die Ansprüche, die im Extremfall mit Cloud Computing gestellt werden, sollten in eine Evaluierung mit einfliessen.

Eine gute Stabilität & Performance ist kein Selbstzweck, sondern die Grundlage für den Erfolg vieler Unternehmungen. Und dies immer mehr.

Mit einzelnen und gezielten Eingriffen in den Applikationslbenszyklus überlässt man diese geschäftskritischen Themen nicht mehr dem Zufall, sondern steuert diese proaktiv. Das Ziel ist immer einerseits Kosten zu sparen und andererseits zufriedene Benutzer zu haben.