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. - 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
