Applikationsmanagement

Nur im Sichtflug zur Punktlandung

7. März 2006, 23:00 Uhr | Jens Steinborn/wg Jens Steinborn ist Sales Director Central Europe bei Wily Technology, deren Übernahme CA zu Jahresbeginn angekündigt hat.

Viele Unternehmen betreiben ihre Systeme und Applikationen ohne konkreten Einblick in deren Verfügbarkeit. So deckt oft erst der Anruf eines entzürnten Benutzers auf, dass eine Anwendung nicht funktioniert. Untersuchungen von Forrester Research zufolge trifft dies auf gut zwei Drittel aller Unternehmen mit J2EE-Applikationen (Java 2 Enterprise Edition) zu.

Entgegen weit verbreiteter Annahmen ist es selten die Applikation selbst, die Probleme bereitet:
Nur einer von acht Ausfällen ist durch Fehler im Applikations-Code begründet, während sich 57
Prozent der Performance- und Verfügbarkeitsprobleme auf unzureichenden Datenzugriff zurückführen
lassen. Klassisches Systemmanagement greift bei komplexen Java-Applikationen häufig zu kurz.

Eine Studie bei 360 IT-Administratoren in Europa und den USA ergab, dass die Hälfte der
Befragten zwar Systemmanagement-Frameworks nutzt, aber nur wenige J2EE-Tools in das Framework
integriert haben. Die Folge: Die Systemmanagementlösung liefert lediglich Aufschluss darüber, ob
eine Applikation online ist. Dabei prüft sie aber nicht das Zusammenspiel der verschiedenen
Komponenten, die eine Anwendung ausmachen – sprich: die gesamte logische Einheit. Dazu gehören der
Code mit der Geschäftslogik, die Applikationsserver und die Verbindungen, über die die Systeme
integriert sind. Allein die Warnung, dass die Applikation hängt, hilft den Administratoren nicht
bei der Fehlersuche: Nach Berechnungen der Newport Group dauert es durchschnittlich 25,8 Stunden,
bis ein Bug im J2EE-Umfeld gefunden und behoben ist.

Was macht die Betreuung von J2EE-Applikationen so kompliziert? Eines der populärsten
Versäumnisse ist es, erst beim Liveeinsatz einer Anwendung Application-Performance-Management zu
verwenden. Dabei dürfen die fünf Lifecycle-Schritte einer Applikation – von der Leistungsdefinition
über das Design und die Entwicklung bis hin zum Testen und dem endgültigen Deployment – nicht
isoliert voneinander betrachtet werden. Denn Performance-Probleme, die in einem bestimmten Stadium
entstehen, tauchen oft erst in einer nachgelagerten Phase auf. Hier erschweren sie es dann dem
zuständigen Systembetreuer, die Fehlerquelle zu bestimmen: Die IT-Abteilung verwaltet eine
Anwendung, über deren Entwicklung sie nicht viel weiß. Das Testteam hat vom Definitionsteam nicht
erfahren, wie eine Applikation auf unterschiedliche Belastungen reagieren wird, und die
Deployment-Gruppe kennt nicht die Abhängigkeiten zwischen der Applikation und anderen Systemen,
über die die Designer mehr sagen könnten.

Die Applikationsplattform, das Betriebssystem und andere Komponenten liefern so gut wie keine
Performance-Informationen automatisch. Dies erschwert das Performance-Management ebenso wie der
Umstand, dass die Verantwortung für die einzelnen Komponenten, die die Applikation umgeben, in
unterschiedlichen Abteilungen liegt: angefangen von der Entwicklung über die Betreuung der
Datenbank und des Netzwerks bis hin zum Main-frame-Betrieb. Entscheidendes Manko für die Qualität
der Kommunikation und damit der Leistungsfähigkeit einer Applikation ist es, dass jedes Team
entlang der Entwicklungskette mit unabhängigen Monitoring- und Managementwerkzeugen arbeitet.

Vielzahl der Werkzeuge als Problemquelle

Grundsätzlich gilt: Um Performance langfristig zu verbessern, müssen die Verantwortlichen
potenzielle Flaschenhälse rechtzeitig aufspüren und beseitigen. Entwickler nutzen dafür in erster
Linie Profiler. Open-Source-Tools wie Extensible Java Profiler (EJP) basieren auf dem Java Virtual
Machine Profiler Interface (JVMPI) und speichern jede einzelne Abfrage, anstatt statistische
Informationen zu generieren. Auf diese Weise lässt sich jeder kleine Ausführungsschritt innerhalb
der J2EE-Anwendung nachvollziehen und in hierarchischen Baumdiagrammen darstellen. Sinnvoll ist der
Einsatz eines Profilers allerdings nur, wenn er Probleme vor der eigentlichen Live-Schaltung der
Applikation entdeckt. Zu einem späteren Zeitpunkt im Applikations-Lifecycle kann der Profiler in
den meisten Fällen nicht schnell genug helfen: Bis sich aus seinen Rohdaten die Fehlerquelle
identifizieren und lokalisieren lässt, sind Performance und Verfügbarkeit der Applikation und damit
Kunden und Umsätze bereits in Mitleidenschaft gezogen.

Ähnlich verhält es sich mit Belastungstests, die sowohl während der Testphase als auch nach der
Live-Schaltung einer Applikation zum Einsatz kommen. Damit lassen sich Problemquellen für die
Applikations-Performance auffinden und in Abhängigkeit zu anderen Systemressourcen wie CPU oder
Memory beseitigen. Allerdings decken diese Tests selbst bei hohem Testaufwand maximal 30 Prozent
der möglichen Geschäftsvorfälle ab. Viele Probleme entstehen zudem erst, wenn die Anwendung in der
Produktion läuft – und sind folglich auch erst dann zu entdecken.

Testumgebungen entsprechen nur selten eins zu eins der Produktionsumgebung. Die meisten
Performance-Probleme ergeben sich durch Schwierigkeiten bei der Integration mit der Liveumgebung
und lassen sich im Vorfeld nicht testen. Kommen Belastungstests in der Produktionsumgebung zum
Einsatz, liefern sie gemäß ihrer iterativen Natur Daten für die langfristig
Performance-Verbesserung. Außerdem nutzen Stresstests feste Pfade durch die Applikationslogik und
können nur ansatzweise das echte Lastverhalten simulieren. Das bedeutet gleichzeitig, dass sie in
einer Ausfallsituation im Tagesgeschäft nutzlos sind.

Die Klammer, die alle Bereiche im Applikations-Lifecycle umfasst und abgestimmt auf jeden
einzelnen Bereich Informationen liefern kann, ist ein Tool für das Application Performance
Monitoring. Solche Werkzeuge sammeln rund um die Uhr Daten über die verschiedenen
Performance-Indikatoren für alle betreffenden Knotenpunkte in der Netzwerktopologie. Zwar bieten
viele Belastungstest-Tools gleichzeitig Monitoring-Funktionen; sie entziehen aber mit der
Datensammlung den CPUs so viel Leistung, dass sich ein gesondertes Werkzeug anbietet.

Monitoring und Management aus einem Guss

Hersteller von Managementlösungen bieten derzeit in erster Linie so genannte End-to-End-Monitore
an. Diese simulieren Transaktionen, um die Antwortzeit einer Applikation als Black Box zu messen.
Der Nachteil: Solche Lösungen machen zwar generell auf bereits entstandene Probleme aufmerksam,
aber nicht exakt auf die Fehlerquelle. Zudem kommen auch sie in der Regel nicht in der
Entwicklungs-, sondern erst in der Produktionsumgebung zum Einsatz.

Eine mögliche Lösung für diese Diskrepanz ist ein Tool, das gezielt Informationen über das
Zusammenspiel der einzelnen Komponenten einer Applikation von innen heraus liefert und dabei die
tatsächlich ablaufenden Transaktionen misst. Solche Werkzeuge arbeiten mit so genannter
Byte-Code-Instrumentierung und sind damit unabhängig von der Plattform und der Version der Java
Virtual Machine (JVM). Eine JVM interpretiert den kompilierten Java-Binär-Code – auch Byte-Code
genant – für den Prozessor eines Rechners beziehungsweise die Hardwareplattform, um so die
Instruktionen eines Java-Programms ausführen zu können.

Der Einsatz von Byte-Code-Instrumentierung bedeutet, dass Messfühler direkt auf dieser
Code-Ebene arbeiten. Sie sammeln dort Rohdaten über die Performance einer Applikation und leiten
die Daten an das Herzstück der Managementlösung weiter. Dieser übersetzt die Informationen und
stellt sie für für Nicht-Java-Experten verständlich in Grafiken dar, zum Beispiel als Ampelsystem,
das bei Problemen erst gelbes, im Ernstfall rotes Licht zeigt. Dabei lassen sich zahlreiche
Parameter – vom Ressourcenverbrauch über Pools bis zu Parallelitäten (Concurrencies) – gezielt
überwachen, um Performance-Probleme zu lösen und so die Verfügbarkeit zu erhöhen. Das muss keine
zusätzliche Belastungen der Plattform bedeuten, wie sie häufig unter anderem durch weitere native
Bibliotheken auf der JVM zustande kommen.

Je ausgereifter ein solches Monitoring- und Management-Tool ist, desto mehr Ansichten liefert
es: Die grafische Umsetzung der Performance-Anzeige lässt sich je nach Benutzer individuell
gestalten. Denn häufig betreuen verschiedenen Teams die Applikation, den Applikationsserver, die
Datenbank, das Netzwerk oder verschiedene Backend-Komponenten. Diese Teams können sich im
Optimalfall genau jene Informationen auf einem Monitor anzeigen lassen, die für ihren
Arbeitsbereich entscheidend sind. Das gilt auch für die Mitarbeiter entlang des Applikationszyklus:
Intelligente Applikations-Monitoring-Lösungen lassen alle Teams, die an der J2EE-Anwendung
beteiligt sind, enger zusammenrücken. Denn vom ersten Designtag bis zum Deployment greifen alle
Mitarbeiter auf durchgängige Informationen über potenzielle Probleme bei Servlets, Java Server
Pages (JSPs), Enterprise Java Beans (EJBs), Klassen und Methoden sowie auf deren Lösungsansätze
zu.

Zwei J2EE-Applikations-Charakteristika tragen häufig zu Datenstaus bei, lassen sich mit
Monitoring-Tools aber schnell aufspüren: erstens die Zahl der Datenobjekte, die die Komplexität des
objektbezogenen Mappings – also des Mappings der Applikationskomponenten zu einer relationalen
Datenbank – ausmacht; zweitens die Transaktionrate während einer Höchstbelastung, die das Volumen
der Datenbankanfragen bestimmt. Um diese drohenden Ausfallrisiken zu reduzieren, müssen die
verschiedenen IT-Administratoren bereichsübergreifend – vor allem im Datenbank- und
Applikationsumfeld – vorsorgen: Je weiter Applikationsobjektmodelle wachsen, desto schwieriger wird
es, ein effizientes, objektbezogenes Mapping zu definieren. Allerdings kann nur ein höchst
wirksames Mapping Flaschenhälse vermeiden. Nehmen die Datenbankanfragen zu, steigt die Gefahr, dass
die Datenbank die Leistung der Applikation durch das schiere Volumen an Anfragen nicht einwandfrei
unterstützen kann. Intelligentes Caching kann hier weiterhelfen.

Für Applikationen, die sowohl komplexe Objektmodelle als auch zahlreiche Datenbankanfragen
bewältigen müssen, erfordert die Beseitigung von Ausfallrisiken einen systematischeren Ansatz. Hier
bietet sich beispielsweise ein Daten-Services-Layer an, eine Software für eine
Zugriffsinfrastruktur, die Mapping und Caching transparent in den J2EE-Server integriert.

Als Faustregel gilt: Weisen J2EE-Applikationen mehr als 50 Datenklassen und/oder mehr als 50
Transaktionen pro Sekunde in Peak-Zeiten auf, dann drohen ernsthafte Performance-Probleme. Sind die
möglichen Fehlerquellen mit- hilfe eines Monitoring- und Management-Tools identifiziert und
lokalisiert, helfen Best-Practice-Ansätze, Probleme langfristig auszuräumen.


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Lampertz GmbH & Co. KG

Matchmaker+