| Author |
Message
|
| klabran |
 Posted: Thu Jan 18, 2007 9:00 am Post subject: Speed up FLow with XSLT transform.... |
 |
|
Master
Joined: 19 Feb 2004
Posts: 259
Location: Flagstaff AZ
|
I am using WBIM 6. I have two flows. The first flow is completely using ESQL to transform my messages. The second one is using an XSLT to do the job.
Running these two I ran into a startling speed difference. The XSLT is order of magnitudes slower. The XSLT transform takes 5 minutes to run on my batches whereas the ESQL can complete the same batch in a minute or so.
Any ideas on how to improve the efficiency of the XSLT transform.
Thanks,
Kevin |
|
| Back to top |
|
 |
| mqmatt |
| Posted: Thu Jan 18, 2007 9:41 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
The reason why you're seeing better performance in ESQL is that the XML Transformation node farms out the processing to a separate component (XALAN); it has to create a DOM tree of your entire input message, transform it and spit out a BLOB.
Compare that to the ESQL which works directly with the message tree.
Of course, while ESQL may generally perform better, your up-front development may be smaller with XSL. You make the choice.
Take a look at the performance reports for a more detailed investigation. http://www.ibm.com/support/docview.wss?uid=swg27007150
Hope this helps
-Matt |
|
| Back to top |
|
|
| klabran |
| Posted: Thu Jan 18, 2007 10:11 am Post subject: |
|
|
Master
Joined: 19 Feb 2004
Posts: 259
Location: Flagstaff AZ
|
Matt thanks but in general I understand why. I was entirely shocked at how vast the performance difference was.
I was hoping that someone had found some tweaks in doing this to help reduce the performance gap.
I did this to lesson the coding required up front but honestly it wasn't vastly easier because the XSLT had to do some tricky stuff. It would have been faster to code in ESQL for me because I am more familiar with that and now with the performance degradation I am nearly convinced that XSLT is bad for me. Which is a shame....
Thanks,
Kevin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 18, 2007 10:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you cache the XSLT, you should get better performance than 5 minutes on the second run.
But if it's a complicated XSLT, you're not going to get great performance.
My opinion on using XSLT with Broker - in the current incarnation of the XMLTransformation node - is that it's only useful to do when the XSLT is already written and tested.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| klabran |
| Posted: Thu Jan 18, 2007 10:35 am Post subject: |
|
|
Master
Joined: 19 Feb 2004
Posts: 259
Location: Flagstaff AZ
|
Thanks Jeff. I am caching it. 
I would have to concur with your general rule of using XSLT with the current broker. I was doing an upgrade for this flow from a previously ESQL only implementation so I specifically wrote this XSLT in hopes it would be easier to maintain in the long run for us but my experience so far is saying not necessarily easier to maintain and with the perf hit OUCH....
All in all a great experiment with unexpected results. That of course is not a surprise! 
Thanks,
Kevin |
|
| Back to top |
|
|
|
|
