Date: Thu, 24 Jun 2010 16:24:48 +0530
Subject: Improving Axis2/Rampart performance.
From: kasu...@gmail.com
To: java-dev@axis.apache.org
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?
MG>in either case are you saying the OMTree was never built? or that you
redirected around the OMTree build?
MG>please clarify behaviour found on OMTree build testcases
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/rampart-...@ws.apache.org/msg04375.html
Thanks & Regards,
/KasunBG
MG>thanks
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3
