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