Have you been able to make any code level improvements? Samisa...
On Tue, Jul 6, 2010 at 1:42 PM, Kasun Gajasinghe <[email protected]> wrote: > 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 <[email protected]>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 <[email protected]>wrote: >> >>> >>> >>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <[email protected]>wrote: >>> >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> Date: Thu, 24 Jun 2010 16:24:48 +0530 >>>> Subject: Improving Axis2/Rampart performance. >>>> From: [email protected] >>>> To: [email protected] >>>> >>>> >>>> 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/[email protected]/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 >>> >> >> > Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
