Mule ESB: XSLT Transformers or Java Transformers?

0
votes

Is there any performance improvement if I use a custom Java transformer in place of an XSLT transformer in Mule?

I have a cxf proxy-service and proxy-client pattern, and my transformers are being used to change the payload so that it is a valid input for subsequent SOAP web-service calls.

1
xmlperformanceesbmule
How will you write your XML transformer in Java? Using DOM, SAX, Stax or ... ? The Mule XSL-T transformer is pooled behind the scene while your Java transformer won't probably be... so the overall performance will also depend on how concurrent is your application. Hard to tell upfront, the best is probably to load test XSL-T and consider your own transformer if it's been proven not fast/concurrent enough. - David Dossot
I am planning to use SAX, but then, Mule itself uses SAX to parse the transformers that I write. Is there something extra that Mule does in this process? I want to make sure that I am not missing out on some advantage of using XSLT transformers, when I move to using Java transformers. About pooling, what exactly is being pooled here? Is the XSLT compiled into a Java transformer and that is pooled, or is the XSLT file pooled itself? It probably won't make much sense if the file is pooled. I am planning to check the performance with LoadUI. Thanks. You rescue me as always. :) - r3st0r3
The transformer keeps a pool of javax.xml.transform.Transformer objects behind the scene, so the XSL-T file is pre-loaded and cached that way. I think using XSL-T would be more maintainable than an ad-hoc Java-based transformer. My advice is: try XSL-T and only go custom code if you've proven that it doesn't perform to your requirements. - David Dossot

1 Answers

4
votes

Measure it and see. You should never make a change to your system for performance reasons unless you can measure the effect. Focus your efforts on instrumentation, and good performance will follow naturally.