Im vorangegangenen Beitrag dieser Kolumne haben wir uns mit dem Profiling von Java-Anwendungen und insbesondere mit Profiler-Werkzeugen beschäftigt.  Beim Profiling geht es um Messungen, die u.a. Aussagen über die Performance einer gesamten Anwendung liefern.  Solche Messungen werden während der Entwicklung vorgenommen, um Schwachstellen im Programm, wie zum Beispiel Performance-HotSpots und –Bottlenecks, zu identifizieren und durch ein anschließendes Tuning zu beseitigen.   Für das Profiling verwendet man in der Regel  entsprechende Profiler-Tools.  Im letzten Beitrag haben wir uns angesehen, wie solche Profiler prinzipiell funktionieren und welche Art von Analysen man damit machen kann. In diesem und dem nächsten Beitrag diskutieren wir, wie man diese Tools verwendet, um verschiedene Profilings zu machen.  Diesmal geht es um das Aufspüren von Performance HotSpots.  Das nächste Mal diskutieren wir Memory HotSpots und Memory Leaks.

Ein Profiling  kann ganz unterschiedliche Aspekte eines Programms untersuchen.  Wir interessieren uns in erster Linie für die Identifikation von Schwachstellen, die die Performance der Anwendung negativ beeinflussen. Der offensichtlichste Ansatzpunkt für ein Performance-Tuning sind Methoden, die viel Zeit verbrauchen und oft aufgerufen werden - die sogenannten „Performance HotSpots“ (später in diesem Beitrag auch als „Functional HotSpots bezeichnet, weil es auch noch andere Arten von HotSpots gibt, die sich auf die Performance auswirken).  Wenn man die Performance eines solchen HotSpots verbessern kann, wirkt sich die Verbesserung spürbar auf die Performance der gesamten Anwendung aus. Man wird deshalb im Rahmen eines Profilings nach solchen Performance HotSpots suchen.

Ein Profiling kann aber noch ganz andere Schwachstellen im Programm aufdecken.  Beispielsweise ist exzessiver Speicherverbrauch ebenfalls ein Schwachpunkt, der sich indirekt über höheren Aufwand für die Garbage Collection negativ auf die Performance auswirkt.  Im Rahmen eines Profilings kann auch die Thread-Synchronisation (z.B. das Warten auf Locks und Signale) daraufhin überprüft werden, ob es so funktioniert, wie es im Design beabsichtigt wurde, oder ob sich Fehler (z.B: zuviel oder zu wenig Synchronisation) eingeschlichen haben.
 

Überblick über die verschiedenen Profiling-Tätigkeiten

• Functional-HotSpots. Performance-Profiling wird hauptsächlich gemacht, um funktionale Performance-Engpässe zu identifizieren, also Methoden, die sehr viel Zeit verbrauchen, weil sie entweder sehr oft aufgerufen werden, oder weil sie sehr lange brauchen für jeden einzelnen Ablauf.  Solche Methoden werden anschließend im Rahmen eines Performance-Tunings entsprechend überarbeitet und in Hinsicht auf ihre Performance optimiert.
• Memory-Allocation-HotSpots.    Hierbei versucht man sich einen Überblick über den Speicherverbrauch der Anwendung zu verschaffen, mit dem Ziel, den Memory Footprint des Programms insgesamt zu minimieren.  Dabei sucht man nach Object-Creation-HotSpots, also Stellen im Programm, wo auffallend hoher Speicherverbrauch festzustellen ist. Möglicherweise werden dort Objekte unnötig erzeugt und man kann diese Speicherverschwendung beseitigen.  Wenn die Objekte tatsächlich gebraucht werden, dann kann man immer noch überlegen, ob sich der Speicherverbrauch durch Wiederverwendung von bereits allozierten Objekten reduzieren lässt.
• Memory-Leaks. Zum Memory-Profiling gehört auch die Suche nach Memory Leaks, also nach Speicher, der logisch gar nicht mehr gebraucht wird, aber immer noch über eine unerwünschte Referenz erreichbar ist und damit vom Garbage Collector nicht aufgeräumt werden kann.  Das ist eigentlich ein Programmierfehler und kann mittels eines Memory.-Profilings gefunden werden.
• Thread-Aktivität. Mit Hilfe eines Profilers kann man prüfen, ob die Threads der Anwendung die CPU so nutzen, wie es geplant war.  Beispiel: bei einem Thread, der hauptsächlich rechnet und verarbeitet, würde man eine hohe CPU-Nutzung erwarten; bei einem Thread, der an einem Socket hängt und auf Requests wartet, wird man eher eine geringe CPU-Nutzung erwarten. Wenn der CPU-Verbrauch der Threads nicht den Erwartungen entspricht, dann hat man entweder die falschen Erwartungen was die Tätigkeiten der Threads angeht oder die Implementierung ist tatsächlich fehlerhaft und muss korrigiert werden.
• Thread-Contention. Dabei geht es um die Verfolgung der Thread-Zustände und insbesondere um die Identifikation und Vermeidung von Starvation und Deadlocks.  Es wird verfolgt, welche Threads welche Monitore halten und freigeben, und kann daran erkennen, ob sich Threads unnötig behindern oder blockieren.  Auf diese Weise können Fehler in der Synchronisierung, wie zum Beispiel Deadlocks, festgestellt werden.  Man kann mit dem Thread-Profiling auch überprüfen, ob alle Threads wie geplant und erwartet ausgelastet sind, oder ob einzelne Thread unerwünscht viel Zeit mit dem Warten auf irgendwelche Locks verbringen.  Diese unerwünschten Wartezustände kann man dann versuchen zu beseitigen.
• Code Coverage.   Das ist eigentlich eher ein Nebenprodukt des Profilings.  Hier wird der Testüberdeckungsgrad gemessen und man kann daran die Güte und Vollständigkeit einer Testsuite messen.  Dabei stellt man u.U. fest, dass das Programm toten Code enthält, den man vielleicht besser eliminieren sollte.  Oder aber man stellt fest, daß die Tests  nicht ausreichend sind und vervollständigt seine Testsuite.

Für die Demonstration haben wir einige kostenlose und ein kommerzielles Tool ausgewählt, nämlich den HPROF zusammen mit HPjmeter und einem Eclipse Profiler PlugIn namens EclipseColorer (alles Freeware) und Borland’s OptimizeIt (kommerzielles Produkt).  Leider funktionieren derzeit noch nicht alle Tools mit Java 5.0.  Beispielsweise gibt es keinen EclipseColorer für die Eclipse-Version 3.1; das ist die Version von Eclipse, die Java 5.0 unterstützt.  HPROF, HPjmeter und OptimizeIt stehen für Java 5.0 aber bereits zur Verfügung.  Die Versionsabhängigkeiten sind lästig, aber auf die generelle Vorgehensweise beim Profiling habe sie keinen Einfluß.
 

Vorbereitungen für ein Profiling

Repräsentativer Programmablauf

Starten des Profiler-Tools

HPROF/HPjmeter

EclipseColorer

OptimizeIt

Nach diesen Vorbereitungen können wir nun diverse Profilings durchführen.  Sehen wir uns als erstes die Performance HotSpots an.

Funktionale Performance-HotSpots aufspüren

Profiling-Information

• Inclusive vs.Exclusive.   Bei der Ablaufzeit wird unterschieden nach dem Zeitverbrauch der Methode allein (engl. exclusive method time) und dem Zeitverbrauch der Methode insgesamt, d.h. inklusive aller Methoden, die von dieser obersten Methode aufgerufen werden (engl. inclusive method time).  Eine Methode kann beispielsweise einen hohen inklusiven, aber einen geringen exklusiven Zeitverbrauch haben. Das passiert, wenn die Methode selber nichts weiter tut, als lediglich andere Methode aufzurufen, die den hohen Zeitverbrauch verursacht.
• CPU vs. Elapsed.  Bei der Zeitangabe kann es sich um die Angabe der verbrauchten CPU-Zeit (engl. cpu time) oder aber um die tatsächlich abgelaufene Zeit (engl. elapsed oder clock time) handeln.  Eine Methode, die sehr viel Zeit mit Warten (auf I/O, im Zusammenhang mit Thread-Synchronisation, etc.) verbringt, wird einen hohen Elapsed-Zeitwert haben, aber einen geringen CPU-Zeitwert.
• Milli vs. Micro.  Die Maßeinheit für die Zeitangabe kann in Millisekunden oder Microsekunden sein.  Normalerweise wird in Millisekunden gemessen.  Die Messung in Microsekunden erfordert häufig mehr Zeit für die Messungen selbst, was stärker zu einer möglichen Verfälschung der Meßergebnisse beiträgt.
• Samples vs. Instrumentation. Es gibt zwei Arten, um Daten über die Ablaufzeiten der Methoden zu beschaffen: Stichproben (engl. samples) und Instrumentierung (engl. instrumentation).  Weil die beiden Techniken zu unterschiedlichen Ergebnissen führen können und unterschiedlich bewertet werden müssen, sehen wir sie uns genauer an.

Stichproben vs. Instrumentierung

Bei der Instrumentierung wird der Eintritt in jede Methode und der Austritt aus jeder Methode erfaßt.  Damit gehen, anders als bei den Stichproben, alle aufgerufenen Methoden präzise in die Zeitmessung ein.  Für die Erfassung von Methodeneintritt und –austritt gibt es zwei Techniken.  Die eine ist die Vorgehensweise über Callbacks, wie wir sie im vorangegangenen Artikel beschrieben haben:  der Methodenein- und austritt sind Events, die den Aufruf einer Callback-Methode des Profiler-Agenten auslösen.  Daneben gibt es die Byte Code Insertion (BCI), bei der der Bytecode selbst, typischerweise beim Laden der Klasse, geändert wird, indem zusätzliche Anweisungen für die Zeitmessung eingefügt werden.  Auch die Byte Code Insertion wird über den Event-Callback-Mechanismus bewerkstelligt. Das Laden und Entladen sind nämlich ebenfalls Events, für die der Profiler Callback-Methoden einhängen kann.  Ein solcher Callback kann beim Laden der Klasse den Bytecode der Klasse instrumentieren und in jede Methode Instruktionen einfügen, die den Eintritt und Austritt aus der Methode erfassen.

BCI ist heutzutage die Standardtechnik, mit der Profiler-Tools die Instrumentierung machen.  Die Callback-Technik wurde in älteren HPROF-Versionen (vor Java 5.0) verwendet, weil die alte JVMPI-Schnittstelle die Byte Code Insertion nicht optimal unterstützt hat.  Die neue JVMTI-Schnittstelle unterstützt BCI besser als früher und der HPROF in Java 5.0 nutzt diese Möglichkeit.  Kommerzielle Tools haben auch schon vorher mit Byte Code Insertion gearbeitet, weil BCI tendenziell weniger Overhead erzeugt als die Callbacks (aber immer noch mehr als das Sampling). BCI ist schneller, weil die eingefügten Bytecode-Instruktionen in der Regel weniger Zeit brauchen, als die Erzeugung von Events für den Methodeneintritt und –austritt und der anschließende Aufruf der dazu registrierten Callback-Methoden.  Wie groß der Unterschied zwischen Callback und Byte Code Insertion ist, hängt natürlich davon ab, was der eingefügte Bytecode tut.

Generell muss man sagen, daß sich die Instrumentierung negativ auf die Performance des zu messenden Programms auswirkt, weil nun plötzlich alle Methodenaufrufe langsamer werden.  Das allein kann bei großen Anwendungen durchaus zum Problem werden; die Instrumentierung skaliert nicht.  Zusätzlich muß man berücksichtigen, dass bei einer Instrumentierung wesentlich mehr Daten erfaßt werden als beim Sampling, so daß u.U. sehr große Messprotokolle entstehen.

Darüber hinaus kann die Instrumentierung die Messergebnisse verfälschen und läßt dann insbesondere kurze Methoden schlimmer aussehen, als sie wirklich sind.  Das liegt daran, dass alle Methoden um denselben Mess-Overhead langsamer werden.  In einer Liste, die die Methoden sortiert nach der Ablaufzeit jeder einzelnen Methode auflistet, tauchen alle Methoden noch in der richtigen Reihenfolge auf, weil der Overhead bei allen Methoden gleich ist. Zwei Methoden, die eigentlich 10 ms und 100 ms lang dauern, tauchen dann mit 15 ms bzw. 105 ms in der Liste auf, wenn der Mess-Overhead 5 ms beträgt. Wenn aber akkumulierte Werte berechnet werden, z.B. „durchschnittliche Ablaufzeit x Anzahl der Aufrufe“, dann sehen die eigentlich kurzen Methoden deutlich schlimmer aus, als sie in Wirklichkeit sind, weil der Mess-Overhead für eine kurze, häufig gerufene Methode eben häufiger mit in die Berechnung eingeht.  Wenn die 10ms-Methode 10.000 mal und die 100ms-Methode 1.000 mal gerufen wird, dann sind die akkumulierten Werte für beide Methoden eigentlich gleich, nämlich 100 s.  Mit dem Mess-Overhead taucht die 10ms-Methode aber akkumuliert mit 150 s in der Statistik auf, die 100ms-Methode aber nur noch mit 105 s. Man sieht also deutlich die Messwertverfälschung.  Wie stark die Verzerrung ist, hängt von der gewählten Implementierungstechnik des Profilers ab (Callback oder BCI).

Mit der Auswahl zwischen Sampling und Instrumentierung hat man also einen Trade-Off zwischen fehlender Präzision (bei den Stichproben) und Messwertverfälschung plus Skalierungsproblemen (bei der Instrumentierung).  Die Stichproben sind sinnvoll, wenn ein Programm gemessen wird, das sehr lange (z.B. über Nacht) läuft; die hohe Anzahl der Stichproben kompensiert dann das Zufallsmoment.  Die Instrumentierung ist sinnvoll, wenn relativ kurz laufende Programme gemessen werden, oder solche die hauptsächlich aus Methoden mit kurzen Laufzeiten (im 100 msec-Bereich) bestehen.
 

Such- und Optimierungsstrategie

Im ersten Ansatz wird die Liste der exklusiven, akkumulierten CPU-Verbrauchswerte (siehe Abbildung 1) angeschaut. Wenn eine Methode in dieser Liste ganz oben steht, dann bedeutet es, daß die Methode entweder lang läuft oder sehr oft gerufen wird oder beides.  Eine solche Methode ist ein aussichtsreicher Kandidat für ein erfolgreiches Performance-Tuning.
 
 

In unserem Beispiel sind die vorderen Ränge dieser Liste mit Methoden belegt, die entweder aus dem Java JDK (Packages java.lang, java.net, java.util, etc.) oder aus einer Bibliothek (Package cvu.html) stammen.  Die eigenen Methoden (Package util.html) kommen erst sehr viel weiter unten in der Liste.  Für unsere Tuning-Anstrengungen ist das einerseits gut und andererseits schlecht.
Es ist gut, weil keine unserer projekteigenen Methoden ein unübersehbares Performance-Bottleneck darstellt.  Es ist schlecht, weil wir jetzt nicht wissen, wo wir mit dem Tuning ansetzen sollen.  Methoden, die aus dem JDK stammen, oder aus dem Webserver, dem ApplicationServer oder aus irgendeinem verwendeten Framework, wollen und/oder können wir nicht tunen.  Eigentlich suchen wir nach Tuning-Kandidaten aus unserem eigenen Projekt.

In einer solchen Situation sieht man sich die Liste der inklusiven CPU-Verbrauchswerte an.  Hier finden sich in der Regel auch die Methoden der projekteigenen Klassen in den oberen Rängen wieder.  Man sucht nun nach Methoden des eigenen Projekts, die einen hohen inklusiven CPU-Verbrauchswert haben und häufig aufgerufen werden.  Um einen solchen projekteigenen Tuning-Kandidaten zu optimieren, schaut man in die Methode hinein und ermittelt, welche Methoden der Tuning-Kandidat seinerseits aufruft und welche von den aufgerufenen Methoden viel CPU-Zeit exklusiv in Anspruch nehmen.

In unserem Beispiel springen in der Liste der inklusiven CPU-Verbrauchswerte (siehe Abbildung 2) die main-Methode und die Methode processHtmlFile ins Auge.  Sie werden aber beide nicht gerade häufig aufgerufen.  Wenn man die Liste der Aufrufhäufigkeiten (siehe Abbildung 3) daneben legt, sieht man, dass der Konstruktor der Klasse cvu.html.TagToken viel Zeit verbraucht und relativ häufig aufgerufen wird.  Dieser Konstruktor wäre ein aussichtsreicher Tuning-Kandidat.  Das bestätigt sich, wenn die Aufrufbeziehungen (siehe Abbildung 4) überprüft werden: es stellt sich nämlich heraus, dass der TagToken-Konstruktor genau die Methode aufruft, die Spitzenreiter in der Liste der exklusiven Methoden ist, nämlich die Methode cvu.html.TagToken.tokenizeString.  Hier kann man nun ein Tuning versuchen, dass die Zahl der Aufrufe der „teuren“ tokenizeString-Methode reduziert.

Ganz allgemein hat eine Optimierungsstrategie also 3 Schritte: (a) man identifiziert einen Tuning-Kandidaten, (b) schaut nach Tuningmöglichkeiten im Inneren des Kandidaten und (c) dann nach Tuningmöglichkeiten in der Umgebung des Kandidaten.
Im Schritt (b) wird versucht, den Tuning-Kandidaten durch performantere Alternativen zu ersetzen.  An dieser Stelle greift man auf jene Tuning-Tips zurück, die man in Büchern und Artikeln für Java-Programmierer findet.  Zum Beispiel könnte man eine ungepufferte I/O durch eine gepufferte I/O ersetzen, falls es um I/O geht. Oder man könnte Arrays statt Collections verwenden, oder StringBuilder anstelle von StringBuffer, usw.  Es geht ganz allgemein gesprochen darum, einen besseren Algorithmus zu finden.

Wenn es keine bessere Implementierung für die betroffene Methode gibt, dann sieht man sich in Schritt (c) die Methode von Außen an und schaut, ob sich vielleicht die Zahl der Aufrufe der Methode selbst reduzieren läßt, durch Umstrukturierungen an anderen Stellen im Programm.

CPU Time vs. Elapsed Time

Zusammenfassung

Literaturverweise und weitere Informationsquellen

Die gesamte Serie über Java Performance:

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   High-Performance Java - programming, monitoring, profiling, and tuning techniques 4 day seminar ( open enrollment and on-site)