On Mon, Jul 12, 2010 at 7:35 AM, Samisa Abeysinghe < [email protected]> wrote:
> Have you been able to make any code level improvements? > > Yes. We did a DOOM code improvement. In NodeImpl class, it has a hashtable variable called userData which stores user objects. The previous implementation has a huge flow that it creates a new hashtable for every node creation which is highly inefficient. I went through xerces DOM code to see how they do this. What it does is, when a userData object wants to be set (in NodeImpl class), it gets the top ancestor of the tree (node.getOwnerDocument()) and puts user data object to it. So, I changed the code and reduced Hashtable object initialization for every request. This object amounted to nearly 4-6%, so this improves the efficiency pretty much. Further, we replaced StringBuffers objects with Strings in TextNodeImpl, CommentImpl and CharacterImpl classes. As, number of requests are higher, and string modifications needed (concatanation, deletion, modification) are less, String is faster in this context. We saw some objects that get created every time a new request comes, which can be replaced with class variables. So, I replaced them accordingly. regards, --KasunBG 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 > >
