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 >
