XSL-Performance Tuning

In den letzten Tagen habe ich mich intensiv mit dem Tuning von XSLs beschäftigen dürfen, die innerhalb einer Web-Anwendung zur Erzeugung der HTML-Masken eingesetzt werden. Prinzipiell stellten die XSLs in diesem Fall kein Antwortzeit-Problem dar, jedoch verbrauchte eine XSL-Transformation einfach zu viel CPU. Dies wollten wir optimieren.

Nach ein wenig googlen habe ich dann festgestellt, dass das Thema XSL-Tuning im Vergleich zu Java-Tuning/-Profiling dünn besetzt ist. Die meisten Einträge sind schon relativ alt zu diesem Thema. Auch gibt es relativ wenige Werkzeuge, die man einsetzen kann. Es gibt zwar einige XSL-Profiler (z.B. Stylusstudio , Oxygen ), jedoch war in unserem Fall die XSL-Transformation in einer Web-Anwendung vollständig eingebettet. Daher wollten wir nicht das dynamisch erzeugte XML in Dateien schreiben und dann einzelnd profilen. Einige XSLT-Implementierungen bieten selber schon Profiling-Informationen an, z.B. kann man bei Saxon einen entsprechenden Parameter setzen. Wir setzen Xalan ein und dort gibt es eine solche Option nicht.

Wir sind daher unseren „normalen“ Weg gegangen, d.h. wir haben einen Java-Profiler benutzt und die Xalan-Klassen instrumentiert. Xalan (wenn XSLTC verwendet wird) generiert Bytecode für die XSLs zur Laufzeit (Translets), die wir ebenfalls profilen konnten. Im Profiler konnte man dann recht gut erkennen, welche Templates (bei Verwendung von includes/call-template/apply-templates) die meiste Zeit verbraucht haben und hatten dann entsprechende Ansatzpunkte, bei denen wir optimieren konnten.

Wir haben dabei festgestellt, dass XSL-Tuning grundlegendes Verständnis einer XSL-Transformation voraussetzt, d.h. nicht nur, welche XSL-Tags verwendet werden können und welche Alternativen es gibt, sondern insbesondere auch, wie ein XSL-Tag /XPath-Ausdrück funktioniert. So arbeitet eine XSL-Transformation grundsätzlich auf einem XML-Baum (auch wenn nicht alle XSLT-Implementierungen DOM benutzen und auch Xalan durch das eigene DTM optimiert) und alle Operationen zur Navigation innerhalb eines XML-Baums sind relativ teuer , z.B. „..“, „//“ oder „descandant::“-Ausdrücke. Je nach Komplexität des XML-Baums konnte man hierdurch schon optimieren. Es hilft auch, diesen XML-Baum möglichst klein zu halten, d.h. Datenmenge zu reduzieren. Im Endeffekt waren es solche „Baumoperationen“, die wir weg-optimiert haben. Aus Performance-Sicht teuer war auch der Umgang mit „nodeset()“, diese Funktion haben wir benutzt selber nochmal innerhalb der XSL XML zu parsen….

Ansonsten haben wir auch einige andere Optimierungen probiert:

1. Umsetzung der Maßnahmen aus den offiziellen Xalan-FAQs
2. Austauschen von Xalan durch andere Implementierungen (z.B. Saxon)
3. Auslagern von „teuren“ Teilen in eigene Java-Implementierungen. Hier bietet Xalan Mechanismen für eigene Extensions

Auch bei XSL-Tuning gilt : Immer nur eine Maßnahme durchführen und dann nachmessen. Je nach XSL kann eine Maßnahme auch schlecht sein, daher vermeide ich hier auch generelle Regeln…

Wenn alles Tuning nicht helfen sollte, gibt es noch die Möglichkeit, die XSL-Transformation komplett auszulagern auf ein dafür optimiertes System (z.B. IBM Datapower , Layer7).  Hier haben wir die IBM Datapower getestet und diese hat die XSL-Transformation in einer wahnsinnigen Geschwindigkeit ausgeführt. Hier spielen natürlich andere Gründe eine Rolle, ob man eine solche Appliance einsetzen möchte.