Performanceanalyse mit VisualVM: ein Fallbeispiel

Run, Java, run!

Horst-Günther Barzik


Java Performance Mythbuster

Die Kenntnis über die Verfügbarkeit von VisualVM scheint nicht sehr verbreitet zu sein [1]. Dabei lassen sich mithilfe dieses Tools Performanceprobleme, die durch Unachtsamkeit erzeugt wurden, schnell und einfach beheben. Wie so oft gilt: Gefahr erkannt, Gefahr gebannt. Die entsprechende, allgemein zur Verfügung stehende Dokumentation [2] des Tools muss nicht unnötig rezitiert werden, der detaillierte fachliche Hintergrund ist zum Verständnis irrelevant.

Der Analyzer – eine einfache Java-Anwendung

Für die Anzeige eines Protokolls von asynchronen, in XML erstellten Log-Einträgen sollte eine Anzeigemöglichkeit geschaffen werden, die dem Betrachter den umfangreichen, fachlich komplexen Zusammenhang in einer komprimierten und bereits aufbereiteten Form präsentiert, um hierdurch deren Analyse zu erleichtern. Die Anwendung sammelt die Einträge in einer ersten Phase mittels SAXParser auf, erzeugt adäquate Objekte und legt diese nach bestimmten Ordnungskriterien in einer Struktur von verschiedenen Collections (TreeMap, TreeSet etc.) ab. In einer zweiten Phase erfolgt eine Analyse, die eine Reihe weiterer, ordnungsabhängiger Information ermittelt und zusammenfasst, bevor zuletzt das Resultat in Tabellen als HTML-Datei ausgegeben wird.

Das Problem

Nachdem die geforderte Funktionalität ausreichend geprüft zur Verfügung stand, galt es, die Handhabung größerer Datenmengen zu gewährleisten, da die Log-Dateien potenziell eine Größe von 2 GB erreichen können. Zu Testzwecken stand eine Datei von etwa 3 MB zur Verfügung. Überraschenderweise war sofort klar: Die zeitlichen Anforderungen können nicht erfüllt werden. Das Programm benötigte für die Bearbeitung der Daten im Mittel etwa drei Sekunden für die Erfassung, etwa 30 Sekunden für die Analyse und weitere 30 Sekunden für die Ausgabe. Diese Werte liegen weit über dem, was bei der Menge der Daten und der Komplexität der Anwendung zu erwarten gewesen wäre. Wo lag das Problem? Gab es überhaupt eines? Oder war die Erwartungshaltung doch zu hoch?

Problemanalyse (1. Ansatz)

In einem ersten Schritt wurden die vermeintlichen Engpässe im Code identifiziert und zur Verifizierung Zeitmessungen in den entsprechenden Methoden implementiert. Kurioserweise konnte jedoch keine dieser Methoden als Kandidat für einen Engpass bestätigt werden. Weitere Kandidaten konnten auf diese Weise nicht isoliert werden. Sollte die Komplexität der geforderten Funktionalität doch höher sein? Nach weiterer Überlegung war Sk...

Performanceanalyse mit VisualVM: ein Fallbeispiel

Run, Java, run!

Horst-Günther Barzik


Java Performance Mythbuster

Die Kenntnis über die Verfügbarkeit von VisualVM scheint nicht sehr verbreitet zu sein [1]. Dabei lassen sich mithilfe dieses Tools Performanceprobleme, die durch Unachtsamkeit erzeugt wurden, schnell und einfach beheben. Wie so oft gilt: Gefahr erkannt, Gefahr gebannt. Die entsprechende, allgemein zur Verfügung stehende Dokumentation [2] des Tools muss nicht unnötig rezitiert werden, der detaillierte fachliche Hintergrund ist zum Verständnis irrelevant.

Der Analyzer – eine einfache Java-Anwendung

Für die Anzeige eines Protokolls von asynchronen, in XML erstellten Log-Einträgen sollte eine Anzeigemöglichkeit geschaffen werden, die dem Betrachter den umfangreichen, fachlich komplexen Zusammenhang in einer komprimierten und bereits aufbereiteten Form präsentiert, um hierdurch deren Analyse zu erleichtern. Die Anwendung sammelt die Einträge in einer ersten Phase mittels SAXParser auf, erzeugt adäquate Objekte und legt diese nach bestimmten Ordnungskriterien in einer Struktur von verschiedenen Collections (TreeMap, TreeSet etc.) ab. In einer zweiten Phase erfolgt eine Analyse, die eine Reihe weiterer, ordnungsabhängiger Information ermittelt und zusammenfasst, bevor zuletzt das Resultat in Tabellen als HTML-Datei ausgegeben wird.

Das Problem

Nachdem die geforderte Funktionalität ausreichend geprüft zur Verfügung stand, galt es, die Handhabung größerer Datenmengen zu gewährleisten, da die Log-Dateien potenziell eine Größe von 2 GB erreichen können. Zu Testzwecken stand eine Datei von etwa 3 MB zur Verfügung. Überraschenderweise war sofort klar: Die zeitlichen Anforderungen können nicht erfüllt werden. Das Programm benötigte für die Bearbeitung der Daten im Mittel etwa drei Sekunden für die Erfassung, etwa 30 Sekunden für die Analyse und weitere 30 Sekunden für die Ausgabe. Diese Werte liegen weit über dem, was bei der Menge der Daten und der Komplexität der Anwendung zu erwarten gewesen wäre. Wo lag das Problem? Gab es überhaupt eines? Oder war die Erwartungshaltung doch zu hoch?

Problemanalyse (1. Ansatz)

In einem ersten Schritt wurden die vermeintlichen Engpässe im Code identifiziert und zur Verifizierung Zeitmessungen in den entsprechenden Methoden implementiert. Kurioserweise konnte jedoch keine dieser Methoden als Kandidat für einen Engpass bestätigt werden. Weitere Kandidaten konnten auf diese Weise nicht isoliert werden. Sollte die Komplexität der geforderten Funktionalität doch höher sein? Nach weiterer Überlegung war Sk...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang