Detektiv auf Javas Fährte

Zeitliche und kausale Korrelation

Die Abweichungsrangliste sagt zunächst nur, dass innerhalb einer Laststufe eine Korrelation zwischen unterschiedlichen Komponenten besteht. Es könnte sich um eine zufällige Koinzidenz handeln - weshalb eine Korrelationsanalyse über mehrere Laststufen hinweg erfolgen muss. Im Unterschied zur Abweichungsrangliste untersucht diese, ob zwei Metriken innerhalb eines eng definierten Zeitfensters, zum Beispiel fünf Sekunden, analog skalieren. Einmal angewandt, liefert die Analyse also nur einen zeitlichen Zusammenhang. Deshalb speichert das Werkzeug alle Korrelationspaare in einer Datenbank. In der nächsten Laststufe folgt eine erneute Korrelationsanalyse, deren Ergebnisse wiederum gespeichert werden und so weiter. Das Ergebnis ist eine Gewichtung nach der «Stärke» der Korrelation. Beispiel: In 95 Prozent aller Fälle korreliert A mit B. Hier liegt ein kausaler Zusammenhang nahe. A korreliert aber nur in 20 Prozent aller Fälle mit C. Hier besteht ein unklarer Kausalzusammenhang. Übrig bleiben vielleicht ein oder zwei Dutzend Komponenten, bei denen klar ist, dass sie kausal mit dem Performance-Problem verknüpft sind.

Java-Transaktionen aufgeschlüsselt

Bei komplexen Problemkonstellationen kann es jedoch mitunter notwendig sein, den exakten Ablauf der Methodenaufrufe innerhalb der Java Virtual Machine transparent zu machen. Damit lässt sich der Ursache-Wirkungs-Mechanismus innerhalb einer Transaktion präzise rekonstruieren. Sinnvoll ist dies aber erst, wenn die relevanten Parameter bereits bekannt sind. Denn dazu gilt es, einen Schnappschuss des aktiven Java-Codes in dem Augenblick zu erstellen, in welchem die problematische Transaktion abläuft. Zu diesem Zweck werden Trigger auf bestimmte Systemereignisse angesetzt, etwa die Aktivität einer Java-Klasse oder das Überschreiten von Performance-Grenzwerten. Im Anschluss stellt das Analysetool dar, in welcher Reihenfolge welche Komponenten einander aufgerufen und wie lange die einzelnen Transaktionsschritte gedauert haben. Man erkennt so in etwa, welche Methoden besonders lange Laufzeiten hatten, von wo diese aufgerufen wurden und welche anderen Komponenten wegen der Verzögerung warten mussten. Wurden einzelne Komponenten als Ursache identifiziert, kann der Analyst mittels Drill-Down auf einzelne Programmsequenzen verzweigen, um die Transaktion genauer zu untersuchen.

Die Performance-Analyse von Java-EE-Anwendungen muss eben nicht nur die Kluft zwischen den einzelnen Tiers und Applikationen überwinden, sondern auch die zwischen System und Netzwerk.

In der Praxis

Der Workflow der Performance-Analyse

o Lasttest zur Erstellung einer Performance-Prognose

Werden geforderte Antwortzeiten erreicht?

Wenn nein:

o einzelne Transaktion auswählen

o kurzer, stufenweise gesteigerter Lasttest zur Bestimmung der technischen Skalierungsgrenze

o Kalibrieren eines Basisschwellenwerts für alle Agenten einer Laststufe

o Stufenlasttest bis über die Grenze der technischen Skalierbarkeit hinaus

o Analyse der Ergebnisse

o Änderungen beziehungsweise Korrekturen

o neuer Stufenlasttest für diese Transaktion

o neuer gemischt-realistischer Lasttest