XSL-Performance Tuning

During the last days I have intensivley worked on performance tuning of XSLs. These XSL are used within an web application to render HTML for presenting screens to the user. In this case, the response time of the XSL processing was not really a problem, but its need of ressources, e.g. CPU time. We wanted to optimze the XSLs or the processing itself to fix this issue.

First (of course) we “googled” about this. But we realized, that there is not much material about the topic XSL-Tuning in comparison to Java-tuning/-profiling. The most of the entries/sites are old. Also, there are not many tools you can use to profile/tune a XSL transformation. There are some tools (like Stylusstudio , Oxygen ), but in our case the XSL transformationen is done within the web application. Even the XML ist dynamically produced at runtime and we didn’t want to change the application to write an XML output which could have been used to profile it “offline”. Some XSL processors have the possibility to trace profile informations, e.g. you can use a specific parameter for Saxon to log these informationes. We were using Xalan and don’t have this option. Acutally we have tested Saxon with our XSLs, but there was not a performance improvement in our case.

So we have done it our “normal” way. We used a Java profiler and instrumented the Xalan-classes. We also instrumented the classes (translets) Xalan generates during processing, if you have enabled XSLTC. With the visualisation done by the profiler we could easily recognize, which templates were responsible for the heavy CPU usage. The advantage for us was, that we have structured our XSLs in many templates und used includes/call-templates to call them. You can see this in the profiler. So after we knew, which templates had to be focussed, we tried to optimize them.

During the optimization we found out, that you need fundamental knowledge of a XSL-transformation, not only the knowledge about which XSL-tags you can alternativley use, but also how a XSL-tag or XPath expression works. The main thing is, that the whole XSLT consist of tree processing and tree operations. It doesn’t matter, if the concrete implementation uses SAX instead of DOM, even Xalan uses an optimzed model (DTM). All tree operations, which navigation through the tree are expensive (e.g. “..”,”//”,”descandant:”). In our case it was worth trying to minize this kind of navigation. We also reduced the size of the XML-input (= the tree is smaller), which increased performance. Other operations on the tree (e.g. “nodeSet()”, which we have used to parse XML within XSL) werde also not cheap in terms of performance.

In general we have tried out the following optimizations:

1. Read the Xalan FAQ und follow the performance recommendations.
2. We have tested other XSLT implementations (e.g. Saxon)
3. Xalan provides Mechanisms to include own Jaca-Code in your XSL. It’s not the best design-style, but you can in some cases replace “hot” XSL-operations.

Even für XSL-tuning there ist still the #1-performance tuning rule: Always implement one (only !) optimzation and the measure the success of this step.

In case of XSLT processing, there are no general rules you can apply (despite of the avoidance of tree operations), because in one XSL (with specific XML data) a operation can be problematic, in other cases it won’t.

If all the XSL tuning does not help enough, then there is the possibility to let optimized systems/products do the XSL transformations for you (e.g. IBM Datapower , Layer7). We tested the IBM Datapower appliance and the speed of the XSL transformations was incredible. Of course, if you want to use such an appliance, there are other things which are worth to think about (administration, integration in the application architecture, etc.)