Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@synapse.apache.org
Received-SPF: pass (athena.apache.org: domain of ruwan.linton@gmail.com
 designates 209.85.142.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type;
        b=ompY/pKwGZRN2bEYlk9dfFP5Glkj1dn4erkkV6Nm6XnWMcdQCcisrd5NhpeVecXFFj
         Bl4OwBT/ArZYQ4JUtwHOl3eUe5pXCSoD/Yab68JeqpBRJM+fhQBthIBvPS91ORo6YLUB
         DX4QlVreNvZpoVRtcZ6LeyumMGqpummhUKbtE=
Message-ID: <672a01200806250112h3b305f54ka760bba1f2daf5df@mail.gmail.com>
Date: Wed, 25 Jun 2008 13:42:40 +0530
From: "Ruwan Linton" <ruwan.linton@gmail.com>
To: dev@synapse.apache.org
Subject: Proposal to improve the XSLT performance
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_90_18547191.1214381561372"

------=_Part_90_18547191.1214381561372
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi devs,

>From the performance test figures on this
article<http://wso2.org/library/3740>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;

   1. It seems like StaxSource is not compatible with some of the XSLT
   processors (SAXON)
   2. 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/

------=_Part_90_18547191.1214381561372
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi devs,<br><br>From the performance test figures on <a href="http://wso2.org/library/3740">this article</a> 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.<br>
<br>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.<br>
<br>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.<br>
<br>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)<br>
<br>There for I propose to remove the StaxSource and use the StreamSource due to the following 2 reasons;<br><ol><li>It seems like StaxSource is not compatible with some of the XSLT processors (SAXON)</li><li>Using StreamSource we can get a vast improvement in the performance for large messages&nbsp;<br>
</li></ol>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&#39;t do much harm even though we keep XALAN but StaxSource has to be replaced with the StreamSource<br>
<br>WDYT?<br><br>Thanks,<br>Ruwan<br><br>-- <br>Ruwan Linton<br><a href="http://wso2.org">http://wso2.org</a> - &quot;Oxygenating the Web Services Platform&quot;<br><a href="http://ruwansblog.blogspot.com/">http://ruwansblog.blogspot.com/</a>

------=_Part_90_18547191.1214381561372--