axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasun Gajasinghe <kasu...@gmail.com>
Subject Re: Improving Axis2/Rampart performance.
Date Mon, 05 Jul 2010 12:00:56 GMT
Hello,
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: http://pastebin.com/mh4d47A6

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

Regards,
KasunBG

~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg


On Thu, Jun 24, 2010 at 11:57 PM, Tharindu Mathew <tharindu@wso2.com> wrote:

>
>
> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mgainty@hotmail.com>wrote:
>
>>
>>
>>
>>
>> ------------------------------
>> Date: Thu, 24 Jun 2010 16:24:48 +0530
>> Subject: Improving Axis2/Rampart performance.
>> From: kasunbg@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?
>>
> 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/rampart-dev@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.
>> Get started.<http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3>
>>
>
>
>
> --
> Regards,
>
> TharinduM
>

Mime
View raw message