On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <[email protected]> wrote:
> > > > > ------------------------------ > Date: Thu, 24 Jun 2010 16:24:48 +0530 > Subject: Improving Axis2/Rampart performance. > From: [email protected] > To: [email protected] > > > Hi, > We had gone through the article from Dennis Sosnoski, about "Java Web > services: CXF performance comparison" with respect to Axis2 and Metro (Link: > http://www.ibm.com/developerworks/java/library/j-jws14/index.html ). > According to the test results of that sample, Axis2 is pretty slow in > performance-wise. For, small messages, Axis2 is more than twice as slow than > CXF, and Axis2 is around 60% slow for larger messages. Based on the test > results, it is understood that the difference is not due to the WS-Security > implementation code, but because of the way Axis2 and Rampart handle > messages that are being passed to and from WSS4J. > > After this observation, we started optimizing the code of Axis2. First, we > did a profiling of Axis2 to find what consumes more CPU time. We found some > possible optimizations that we can have which will have a fairly better > improvement in performance. > Then, we looked in to Rampart module for looking at possible > implementations that could affect performance. We came into aware of > following things. > > > - RampartEngine always loads the Crypto object (specifically the > signatureCypto), which adds a lot of overhead. Reloading the object for > every request (and in some cases multiple times per request) is very > inefficient. So, it is highly recommended to enable caching of crypto > objects. Caching is per service base. The tests done in the article had run > With Out caching. With caching, there is a significant performance > increase. > > > - Rampart OM -- DOOM conversion at inFlow happens like this. Build OM > tree --> get the StAX Reader from OMTree --> build DOOM tree. Here, it is > possible to build the DOOM tree directly by getting the StAX reader without > building OM tree. In this case, OM gives the underline stax reader without > building the om tree. - Fixed. > > MG>please specify reference to StaxReader.. do you mean > org.apache.axis2.jaxws.message.util.StackableReader OR > org.apache.axiom.om.impl.builder.StAXOMBuilder? > The StaxOMBuilder > MG>in either case are you saying the OMTree was never built? or that you > redirected around the OMTree build? > The OMTree was built before converting it to a DOOM tree. This was unnecessary and has been removed. Now we get the reference to the reader and directly build the DOOM tree > MG>please clarify behaviour found on OMTree build testcases > I'm not clear about your request. There is no issue with OMTree building. For this particular case it has been avoided. Does this answer your question? > > > > - Right now Axis2 do the following conversion due to an OM bug. " > Object -> OM -> DOOM -> Goes a DOOM to WS-Security (Comes out the DOOM) > *->OM* " > DOOM to OM conversion at the end is unnecessary. So, we optimized it > too. > > > - A detailed look at the profile suggests that the most of the overhead > is caused by DOOM methods than object conversions. But the good thing is, > there's still room to optimize the code. - we are currently > analyzing/improving this. > > > From these optimizations so far, we were able to get performance increase > of around 20%. > We should gather around and discuss them further and see what are other > possible improvements we can take to increase performance. > > > Resources: > The sample used for comparison: > http://www.ibm.com/developerworks/apps/download/index.jsp?contentid=484864&filename=j-jws14-src.zip&method=http > Enable Crypto Caching: > http://www.mail-archive.com/[email protected]/msg04375.html > > > Thanks & Regards, > /KasunBG > MG>thanks > > > ------------------------------ > The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get > started.<http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3> > -- Regards, TharinduM
