I'm still trying to understand why StaxSource causes a performance
degradation. I don't see why serializing the message to a byte array
and then parsing it again gives better performance than pulling a
stream of StAX events and transform them into SAX events. I tried to
reproduce this with a simple test (executing the XSLT in a loop and
measuring the average time), but in this case StaxSource shows a
slightly better performance than StreamSource. Any idea about what
could be the explanation for this?
Anyway, instead of simply replacing StaxSource by StreamSource I would
like to refactor the XSLTMediator to allow to easily plug in different
strategies to construct the Source object and make this a configurable
setting. I already wrote some code along these lines for the simple
benchmark I implemented this morning and I could easily integrate this
into XSLTMediator. Also I started to write a Source implementation
that transforms directly from an Axiom tree to SAX (instead of going
through StAX). It is not yet complete but I was able to use this
successfully with both Xalan and Saxon.
Andreas
On 25 juin 08, at 18:48, [EMAIL PROTECTED] wrote:
Andreas,
I have used serialize method, but it would be possible to use the
serializeAndConsume method as well and also should improve the
performance a little more.
Thanks,
Ruwan
On 6/25/08, Andreas Veithen <[EMAIL PROTECTED]> wrote:
Ruwan,
When you did the test with TemporaryData, how did you serialize the
source tree? Using serialize or serializeAndConsume?
Andreas
On 25 juin 08, at 10:12, Ruwan Linton wrote:
Hi devs,
From the performance test figures on this article I found that
performance for the XSLT transformations shows a drastic drop in
performance with increasing the message size. There fore I did some
research on improving the performance of XSLTMediator.
First I though of trying to switch to SAXON as the XSLT processor
thinking that it will be faster than XALAN, but when I try to switch
the transformer it gives an error because of the fact that we create
a StaxSource as the default javax.xml.transform.Source to the
transformer, which seems to be not compatible with SAXON.
Then I have used the dom feature to enable DOMSource as the
transform source and the DOMResult as the result, which was
successful but at the same time was unable to improve the
performance with compared to the xsltc transformer
(org.apache.xalan.xsltc.trax.TransformerFactoryImpl) of XALAN.
Then I did some more tests and thought of removing the StaxSource
and giving the Source as a StreamSource with using the TemporaryData
class backed data source. This has shown a considerable improvement
to the XSLT transformation and now for 5K messages Synapse is 3-4
times faster than the one we are currently having. Also for 1K
messages it shows some improvement. (There is no clear difference
between XALAN xsltc and SAXON-b, though SAXON-b shows a little
better figures)
There for I propose to remove the StaxSource and use the
StreamSource due to the following 2 reasons;
It seems like StaxSource is not compatible with some of the XSLT
processors (SAXON)
Using StreamSource we can get a vast improvement in the performance
for large messages
I would like to use SAXON-b (open source version of SAXON) as the
default XSLT processor, but it has a limitation on Schema awareness.
Well, it doesn't do much harm even though we keep XALAN but
StaxSource has to be replaced with the StreamSource
WDYT?
Thanks,
Ruwan
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
