Detektiv auf Javas Fährte

Die Performance-Analyse von Java-EE-Anwendungen ist eine Detektivarbeit, bei der Tausende von Indizien zu berücksichtigen sind. Systematisches Vorgehen ist unerlässlich.

Martin Klapdor ist Senior Applications Engineer bei Opnet Technologies, Frankfurt am Main.

Eine klassische Situation: Ein Softwareprojekt steht kurz vor dem Abschluss. Im Lasttest wird geprüft, ob die neue Anwendung die geplante Nutzeranzahl mit der geforderten Antwortzeit bedienen kann. Treten jetzt Performance-Probleme auf, müssen sie schnell und präzise analysiert werden. Handelt es sich bei der neuen Anwendung um eine Java-EE-Applikation (Enterprise Edition), ist das allerdings eine knifflige Aufgabe. Denn die Performance-Analyse solcher Anwendungen kämpft mit einem spezifischen Problem: der Überfülle heterogener Zustandsinformationen.

Die Performance-Probleme äussern sich durch parallele Auslastungs- und Abweichungsphänomene auf mehreren Tiers und Applikationen, die in der Regel von verschiedenen Abteilungen mittels diverser Werkzeuge aufgezeichnet werden. Begleitet werden die Symptome von einem «Grund-rauschen» unzähliger weiterer Metriken, die in irgendeiner Form ein abnormales Verhalten aufweisen, mit dem Problem jedoch nichts zu tun haben. Eine erfolgreiche Performance-Analyse muss daher jene Informa-tionen herausfischen, die mit den mangelhaften Antwortzeiten kausal korrelieren.

Java EE: Kniffliger als üblich

Die systematische Analyse darf nicht von vornherein eine bestimmte Perspektive einnehmen, sondern muss von einem Panoramablick auf alle Tiers, Applikationen und gegebenenfalls auch Netzwerke ausgehen – und erst danach die Ursache schrittweise eingrenzen. Die technische Voraussetzung dafür ist eine integrierte Steuerung des Monitorings auf allen Tiers und die Möglichkeit der Korrelation der erhobenen Daten.

Die Performanceanalyse erfordert eine spezifischere Vorgehensweise als herkömmliche Lasttests. Man lässt jeweils nur eine bestimmte Transaktion laufen, um einzelne Parameter bewerten zu können. Man eliminiert Denkpausen, um die Gleichzeitigkeit der Transaktionen sicherzustellen. Und: Es werden nicht die Antwortzeiten, sondern Performance-Metriken innerhalb der verschiedenen Tiers und Applikationen überwacht.

Dabei ist die grundlegende Unterscheidung zwischen technischer Skalierung und steigender Antwortzeit wichtig. Wird die Last auf eine Anwendung kontinuierlich gesteigert, hört irgendwann die Durchsatzmenge auf, proportional zur Laststeigerung zu skalieren: Die Anwendung hat ihren Sättigungspunkt erreicht, die Durchsatzkurve geht in ein Plateau über. Steigt die Last weiter, fängt die Durchsatzkurve sogar an zu fallen.

Die Antwortzeitkurve verläuft meist ganz anders. Beispiel: Die Grenze der noch akzeptablen Antwortzeit wird erst bei knapp 160 An--wendern durchbrochen, obwohl die Anwendung technisch gesehen schon bei 70 Anwendern zu skalieren aufhörte. Ein dramatischer Anstieg der Antwortzeit ist erst zu verzeichnen, wenn die Durchsatzkurve sinkt, während gleichzeitig die Last weiter ansteigt.