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 Tue, 06 Jul 2010 08:12:03 GMT
Hello Srinath,
Can you please forward the comparison you made between Axis2 and CXF to the
list? I remember you compared the axis2 and cxf methods based on profiler
screenshots.

Thanks,
KasunBG


On Mon, Jul 5, 2010 at 5:30 PM, Kasun Gajasinghe <kasunbg@gmail.com> wrote:

> 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