axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasun Gajasinghe <>
Subject Improving Axis2/Rampart performance.
Date Thu, 24 Jun 2010 10:54:48 GMT
We had gone through the article from Dennis Sosnoski, about "Java Web
services: CXF performance comparison" with respect to Axis2 and Metro (Link: ).
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.

The sample used for comparison:
Enable Crypto Caching:

Thanks & Regards,

View raw message