Detektiv auf Javas Fährte

Was ist «unnormal»?

Bei der Analyse kommt es darauf an, die technische Skalierungsgrenze zu analysieren. Um zu wissen, was in der Anwendung passiert, wenn sie zu skalieren aufhört, muss man wissen, welche Metriken beginnen, überproportional zu skalieren. Deshalb braucht es für jede Metrik einen Vergleichspunkt - einen Basiswert, der auf allen System- und Anwendungsschichten zu definieren ist. Das Vorgehen: Man fährt mit dem Lastgenerator eine Last, die unter der Bruchstelle der technischen Skalierung liegt. Bei dieser Last definiert man für alle Metriken: Der jetzige Wert sei Normalwert, die CPUAuslastung auf allen Servern sei normal, die Antwortzeit aller Java-Klassen und Servlets sei normal und so weiter. Dann lässt sich feststellen, welche Komponenten bei steigender Last überpropor-tional skalieren. Damit grenzt sich die Anzahl der für die Problemlösung überhaupt relevanten Indizien ein.

Bei welcher Last der Basiswert kalibriert wird, hängt von der jeweiligen Fragestellung ab. Eine Last von 50 bis 75 Prozent der Skalierungsgrenze eignet sich, um zu analysieren, was sich verändert, wenn die Skalierung aufhört. Aber auch ein Wert jenseits der Grenze kann wertvolle Ergebnisse liefern. Denn dann werden Metriken der Komponenten, die in der problema-tischen Transaktion vor dem Flaschenhals liegen, relativ konstant bleiben, die Metriken hinter dem Flaschenhals jedoch deutliche Abweichungen aufweisen. Auf diese Weise kann bereits eine einfache Analyse sehr schnell auf die Problemursache deuten. Die Voraussetzung für ein solches Verfahren ist eine integrierte Agentensteuerung. Agenten auf allen Tiers müssen synchron in einen speziellen Modus versetzt werden, in dem sie eine «normale» Bandbreite von Werten kalibrieren.

Rangliste der Abweichler

Nachdem für alle Metriken ein Normalwert definiert wurde, ist für die verschiedenen Laststufen eine Analyse der am stärksten vom Normalwert abweichenden Metriken möglich (siehe Bild S. 18.). Denn diese sind es, die direkt mit dem Flaschenhals zu tun haben oder davon betroffen sind. Dabei eröffnen sich häufig Zusammenhänge, an die man zuvor nie gedacht hätte. Bei diesem Schritt muss das Analysewerkzeug allerdings differenziert arbeiten: Es muss sowohl Ausmass als auch Dauer der Abweichungen berücksichtigen. Sonst verfälschen einzelne Ausreisser das Bild.

Als nächstes wird für eine Laststufe eine Rangliste der schwerwiegendsten Abweichungen erstellt. Hat man schon eine Idee, auf welcher Systemschicht das Problem angesiedelt sein könnte, kann man die Analyse darauf fokussieren. Sonst fährt man sie über alle Komponenten hinweg. Die Aussagekraft der Rangliste ist aber auch dann beträchtlich, denn in der Regel erhält man eine relativ kleine Zahl von Metriken, die signifikant stärker als alle anderen abweichen. Jetzt kann der Analyst mit grosser Wahrscheinlichkeit darauf schliessen, dass eine bestimmte Anzahl von Komponenten mit dem Performance-Problem zusammenhängen. Wie, weiss er allerdings noch nicht genau.