Hi Andreas, On Wed, Jun 25, 2008 at 11:39 PM, Andreas Veithen <[EMAIL PROTECTED]> wrote:
> 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? Well, I don't have a reasonable explanation, if I have used serializeAndConsume may be there have been an one :-). Any way I think there is some performance problem in the transformations when it uses the StaxSource. I can consistently see a performance improvement in the large messages. You can run the same test that I have run, all the contents are there in the svn location that I have pointed earlier. Or I can do it for all methodologies after the implementation. > > > 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. +1 for this idea. Well we can change the source implementations by providing a synapse specific feature for the XSLT mediator. We already do this to switch to DOMSource and DOMResult. > 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. Interesting I also started to write AXIOMSource and AXIOResult classes but didn't go in to much in the implementation and hanging on. I have no deep understanding on transformer implementations and hence you better continue and I am gonna drop this in. After you have completed this work please do let me know so that I can provide a performance comparison of different methodologies to do XSLT transformations in Synapse. Thanks, Ruwan > > > 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] > > -- Ruwan Linton http://wso2.org - "Oxygenating the Web Services Platform" http://ruwansblog.blogspot.com/
