axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasun Gajasinghe <>
Subject Re: Improving Axis2/Rampart performance.
Date Mon, 05 Jul 2010 12:00:56 GMT
As I said before, DOOM methods in axiom-dom takes a lot of time to execute.
Specially, findNamePoint(String, String) method in NamedNodeMapImpl is
taking enormous time, due to a linear search in it. The linear search
searches for a node in the 'nodes' Vector variable for a given NameSpaceURI
and a name.

One solution is to replace the nodes variable with a HashMap, effectively
reducing the searching time. But the concerns are HashMaps takes a lot of
memory than Vectors. And to use the hashmap, we have to add a key. in this
case, a concatenated name from namespaceuri and name have to be used. This
will add another overhead from string operations.

I wrote a sample code with 10,000 vectors and hashmaps. Then did a profiling
for it. By that, we can compare the memory usages of HashMaps and Vectors.
According to that, it takes a some memory for HashMap. This is the pastebin
of the sample:

HashMaps with the initial size of 10 and 20 were ran separately along with
Vectors. (10k objects from each.)

An extract of a profiling for 10k Vector objects and 10k  HashMaps of
initial size 10.

*Object type             --- Memory size  --- Instance Count*
HashMap                --- 397KB           --- 10k
HashMap$Entry[]     --- 799KB           --- 10k
HashMap$Entry       --- 479KB           --- 20k

Vector                    --- 234KB           --- 10k

i will try to replace Vector with a HashMap update the list soon about the


Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.

On Thu, Jun 24, 2010 at 11:57 PM, Tharindu Mathew <> wrote:

> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <>wrote:
>> ------------------------------
>> Date: Thu, 24 Jun 2010 16:24:48 +0530
>> Subject: Improving Axis2/Rampart performance.
>> From:
>> To:
>> Hi,
>> 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.
>> MG>please specify reference to StaxReader.. do you mean
>> org.apache.axis2.jaxws.message.util.StackableReader OR
> 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:
>> Enable Crypto Caching:
>> Thanks & Regards,
>> /KasunBG
>> MG>thanks
>> ------------------------------
>> The New Busy is not the old busy. Search, chat and e-mail from your inbox.
>> Get started.<>
> --
> Regards,
> TharinduM

View raw message