Hi Andreas, I have created a JIRA issue for this.
https://issues.apache.org/jira/browse/SYNAPSE-378 Thanks, Ruwan On Thu, Jun 26, 2008 at 2:15 PM, Ruwan Linton <[EMAIL PROTECTED]> wrote: > 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/ > -- Ruwan Linton http://wso2.org - "Oxygenating the Web Services Platform" http://ruwansblog.blogspot.com/
