You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Kasun Gajasinghe <ka...@gmail.com> on 2010/07/05 14:00:56 UTC
Re: Improving Axis2/Rampart performance.
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 <th...@wso2.com> wrote:
>
>
> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello,
This is regarding the final results (1st-phase) of Axis2/Axiom/Rampart
performance improvement. We wrapped up the improvements done so far, and ran
final test runs to compare the running times of Axis2 compared to CXF. There
are further improvements that can be done. We are aware about some of them,
so hopefully if it needs any further improvements, that can be done.
Basically, now we are trying to bring Rampart2 forward by replacing current
Rampart1. We need to complete it and there are some legal things to be
carried out as the coding happened outside the Apache Version Control (It
was a final year project done by four students at University of Moratuwa
namely, Sameera, Isuru, Saliya and Kalani).
In Rampart2, there is Rampart xml-security which is built on OM model. If we
use it, then there is no need of DOOM (the axiom-dom module). Hopefully,
this should improve performance considerably, as DOOM was the main culprit
in slowing down Axis2 as of now.
And, with these improvements, we are glad to say that Axis2 is now more than
30% faster than CXF for small samples as of the latest test result shows
:) This still need to be confirmed though! Overall, DOOM is now much
improved and is very closer to CXF in other usecases, in performance-wise.
[0], [1] contains the final result charts, comparing Axis2 trunk version
vs. Axis2 with Improvements vs. CXF. We were mainly focused on improving
Sign & Encrypt (signencr) usecase for large samples, because improving it
will improve other scenarios as well, as it involves all the scenarios and
handlers (signing, encryption, tree building etc.)
We have submitted the Patch for Axiom module at WS-Commons Jira [2]. Patch
for Rampart to be uploaded soon.
[0] http://imagebin.ca/view/NzqFZNAR.html
[1] http://imagebin.ca/view/0NDzdKp.html
[2] https://issues.apache.org/jira/browse/WSCOMMONS-556
Thank you!
--KasunBG
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Tue, Jul 13, 2010 at 2:29 PM, Kasun Gajasinghe <ka...@gmail.com> wrote:
> Hello Devs,
> One more iteration on Axis2 and CXF Profiles revealed an interesting point.
> This is in the call tree, in the point which
> "org.apache.xml.security.c14n.implementations.CanonicalizerBase"
> class' canonicalizeSubTree() method calls to DOOM methods.
> In that method, handleAttributesSubtree() calls DOOM's
> ElementImpl.getAttributes() method. The Time spent on getAttributes()
> has amounted to around 10% of total cpu time. When, I looked at the time
> taken by the same method of CXF, it only used less than 1% of cpu time. So,
> clearly there's something wrong in here.
>
> I attached a screen shot to have a look at.
> i went through the source of Axis2 and CXF. I pasted the method so, all of
> you can have look. Please analyze them and suggest what we can do to remove
> this overhead.
>
> Thanks & Regards,
> --KasunBG
>
> =========================================================================
> CXF:
> /**
> * Retrieve all the Attributes as a set. Note that this API is
> inherited
> * from Node rather than specified on Element; in fact only Elements
> will
> * ever have Attributes, but they want to allow folks to "blindly"
> operate
> * on the tree as a set of Nodes.
> */
> public NamedNodeMap getAttributes() {
>
> if (needsSyncData()) {
> synchronizeData();
> }
> if (attributes == null) {
> attributes = new AttributeMap(this, null);
> }
> return attributes;
>
> } // getAttributes():NamedNodeMap
>
>
> =========================================================================
> Axis2:
> /** Returns the set of attributes of this node and the namespace
> declarations available. */
> public NamedNodeMap getAttributes() {
> AttributeMap attributeMap = new AttributeMap(this);
>
> // Add the set of existing attrs
> for (int i = 0; i < this.attributes.getLength(); i++) {
> attributeMap.addItem((Attr) this.attributes.getItem(i));
> }
>
> // Add the NS declarations
> if (this.namespaces != null) {
> Iterator nsDecls = this.namespaces.keySet().iterator();
> while (nsDecls.hasNext()) {
> String prefix = (String) nsDecls.next();
> if (prefix != null && !"".equals(prefix)
> && !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
> OMNamespace ns = (OMNamespace)
> this.namespaces.get(prefix);
> AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
> .getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
>
> // Set the default NS attr if any
> if (this.namespace != null
> && (this.namespace.getPrefix() == null || ""
> .equals(this.namespace.getPrefix()))
> && this.namespace.getNamespaceURI() != null) {
>
> // check if the parent of this element has the same
> namespace
> // as the default and if NOT add the attr
> boolean parentHasSameDefaultNS = this.parentNode != null &&
> this.parentNode.getNamespaceURI() != null &&
>
> this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
> (this.parentNode.getPrefix() == null ||
> this.parentNode.getPrefix().equals(""));
>
> if (!parentHasSameDefaultNS) {
> AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
>
> this.namespace.getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
> }
>
> return attributeMap;
> }
>
> =========================================================================
>
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://kasunbg.blogspot.com
> Twitter: http://twitter.com/kasunbg
>
>
> On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
> kshanth2101@gmail.com> wrote:
>
>> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
>> <sa...@gmail.com> wrote:
>> > Can you guys provide patches for these improvements?
>>
>> Ok, we will do.
>>
>> Thanks,
>> Kishanthan.
>> >
>> > Thanks,
>> > Samisa...
>> >
>> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
>> > <ks...@gmail.com> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> We also did some changes in DOMUtil class. We combined the getName and
>> >> getPrefix methods to one method. Because there were quite large calls
>> >> to these methods which took quite large time. So by combining these
>> >> methods to one and reducing the number of calls to the method, we were
>> >> able to get some improvements in time values.
>> >>
>> >> Thanks,
>> >> --
>> >> Kishanthan.T
>> >> University of Moratuwa.
>> >> SriLanka.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> > Thanks,
>> > Samisa...
>> >
>> > Samisa Abeysinghe
>> > VP Engineering
>> > WSO2 Inc.
>> > http://wso2.com
>> > http://wso2.org
>> >
>>
>>
>>
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello,
This is regarding the final results (1st-phase) of Axis2/Axiom/Rampart
performance improvement. We wrapped up the improvements done so far, and ran
final test runs to compare the running times of Axis2 compared to CXF. There
are further improvements that can be done. We are aware about some of them,
so hopefully if it needs any further improvements, that can be done.
Basically, now we are trying to bring Rampart2 forward by replacing current
Rampart1. We need to complete it and there are some legal things to be
carried out as the coding happened outside the Apache Version Control (It
was a final year project done by four students at University of Moratuwa
namely, Sameera, Isuru, Saliya and Kalani).
In Rampart2, there is Rampart xml-security which is built on OM model. If we
use it, then there is no need of DOOM (the axiom-dom module). Hopefully,
this should improve performance considerably, as DOOM was the main culprit
in slowing down Axis2 as of now.
And, with these improvements, we are glad to say that Axis2 is now more than
30% faster than CXF for small samples as of the latest test result shows
:) This still need to be confirmed though! Overall, DOOM is now much
improved and is very closer to CXF in other usecases, in performance-wise.
[0], [1] contains the final result charts, comparing Axis2 trunk version
vs. Axis2 with Improvements vs. CXF. We were mainly focused on improving
Sign & Encrypt (signencr) usecase for large samples, because improving it
will improve other scenarios as well, as it involves all the scenarios and
handlers (signing, encryption, tree building etc.)
We have submitted the Patch for Axiom module at WS-Commons Jira [2]. Patch
for Rampart to be uploaded soon.
[0] http://imagebin.ca/view/NzqFZNAR.html
[1] http://imagebin.ca/view/0NDzdKp.html
[2] https://issues.apache.org/jira/browse/WSCOMMONS-556
Thank you!
--KasunBG
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Tue, Jul 13, 2010 at 2:29 PM, Kasun Gajasinghe <ka...@gmail.com> wrote:
> Hello Devs,
> One more iteration on Axis2 and CXF Profiles revealed an interesting point.
> This is in the call tree, in the point which
> "org.apache.xml.security.c14n.implementations.CanonicalizerBase"
> class' canonicalizeSubTree() method calls to DOOM methods.
> In that method, handleAttributesSubtree() calls DOOM's
> ElementImpl.getAttributes() method. The Time spent on getAttributes()
> has amounted to around 10% of total cpu time. When, I looked at the time
> taken by the same method of CXF, it only used less than 1% of cpu time. So,
> clearly there's something wrong in here.
>
> I attached a screen shot to have a look at.
> i went through the source of Axis2 and CXF. I pasted the method so, all of
> you can have look. Please analyze them and suggest what we can do to remove
> this overhead.
>
> Thanks & Regards,
> --KasunBG
>
> =========================================================================
> CXF:
> /**
> * Retrieve all the Attributes as a set. Note that this API is
> inherited
> * from Node rather than specified on Element; in fact only Elements
> will
> * ever have Attributes, but they want to allow folks to "blindly"
> operate
> * on the tree as a set of Nodes.
> */
> public NamedNodeMap getAttributes() {
>
> if (needsSyncData()) {
> synchronizeData();
> }
> if (attributes == null) {
> attributes = new AttributeMap(this, null);
> }
> return attributes;
>
> } // getAttributes():NamedNodeMap
>
>
> =========================================================================
> Axis2:
> /** Returns the set of attributes of this node and the namespace
> declarations available. */
> public NamedNodeMap getAttributes() {
> AttributeMap attributeMap = new AttributeMap(this);
>
> // Add the set of existing attrs
> for (int i = 0; i < this.attributes.getLength(); i++) {
> attributeMap.addItem((Attr) this.attributes.getItem(i));
> }
>
> // Add the NS declarations
> if (this.namespaces != null) {
> Iterator nsDecls = this.namespaces.keySet().iterator();
> while (nsDecls.hasNext()) {
> String prefix = (String) nsDecls.next();
> if (prefix != null && !"".equals(prefix)
> && !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
> OMNamespace ns = (OMNamespace)
> this.namespaces.get(prefix);
> AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
> .getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
>
> // Set the default NS attr if any
> if (this.namespace != null
> && (this.namespace.getPrefix() == null || ""
> .equals(this.namespace.getPrefix()))
> && this.namespace.getNamespaceURI() != null) {
>
> // check if the parent of this element has the same
> namespace
> // as the default and if NOT add the attr
> boolean parentHasSameDefaultNS = this.parentNode != null &&
> this.parentNode.getNamespaceURI() != null &&
>
> this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
> (this.parentNode.getPrefix() == null ||
> this.parentNode.getPrefix().equals(""));
>
> if (!parentHasSameDefaultNS) {
> AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
>
> this.namespace.getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
> }
>
> return attributeMap;
> }
>
> =========================================================================
>
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://kasunbg.blogspot.com
> Twitter: http://twitter.com/kasunbg
>
>
> On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
> kshanth2101@gmail.com> wrote:
>
>> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
>> <sa...@gmail.com> wrote:
>> > Can you guys provide patches for these improvements?
>>
>> Ok, we will do.
>>
>> Thanks,
>> Kishanthan.
>> >
>> > Thanks,
>> > Samisa...
>> >
>> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
>> > <ks...@gmail.com> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> We also did some changes in DOMUtil class. We combined the getName and
>> >> getPrefix methods to one method. Because there were quite large calls
>> >> to these methods which took quite large time. So by combining these
>> >> methods to one and reducing the number of calls to the method, we were
>> >> able to get some improvements in time values.
>> >>
>> >> Thanks,
>> >> --
>> >> Kishanthan.T
>> >> University of Moratuwa.
>> >> SriLanka.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> > Thanks,
>> > Samisa...
>> >
>> > Samisa Abeysinghe
>> > VP Engineering
>> > WSO2 Inc.
>> > http://wso2.com
>> > http://wso2.org
>> >
>>
>>
>>
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello,
This is regarding the final results (1st-phase) of Axis2/Axiom/Rampart
performance improvement. We wrapped up the improvements done so far, and ran
final test runs to compare the running times of Axis2 compared to CXF. There
are further improvements that can be done. We are aware about some of them,
so hopefully if it needs any further improvements, that can be done.
Basically, now we are trying to bring Rampart2 forward by replacing current
Rampart1. We need to complete it and there are some legal things to be
carried out as the coding happened outside the Apache Version Control (It
was a final year project done by four students at University of Moratuwa
namely, Sameera, Isuru, Saliya and Kalani).
In Rampart2, there is Rampart xml-security which is built on OM model. If we
use it, then there is no need of DOOM (the axiom-dom module). Hopefully,
this should improve performance considerably, as DOOM was the main culprit
in slowing down Axis2 as of now.
And, with these improvements, we are glad to say that Axis2 is now more than
30% faster than CXF for small samples as of the latest test result shows
:) This still need to be confirmed though! Overall, DOOM is now much
improved and is very closer to CXF in other usecases, in performance-wise.
[0], [1] contains the final result charts, comparing Axis2 trunk version
vs. Axis2 with Improvements vs. CXF. We were mainly focused on improving
Sign & Encrypt (signencr) usecase for large samples, because improving it
will improve other scenarios as well, as it involves all the scenarios and
handlers (signing, encryption, tree building etc.)
We have submitted the Patch for Axiom module at WS-Commons Jira [2]. Patch
for Rampart to be uploaded soon.
[0] http://imagebin.ca/view/NzqFZNAR.html
[1] http://imagebin.ca/view/0NDzdKp.html
[2] https://issues.apache.org/jira/browse/WSCOMMONS-556
Thank you!
--KasunBG
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Tue, Jul 13, 2010 at 2:29 PM, Kasun Gajasinghe <ka...@gmail.com> wrote:
> Hello Devs,
> One more iteration on Axis2 and CXF Profiles revealed an interesting point.
> This is in the call tree, in the point which
> "org.apache.xml.security.c14n.implementations.CanonicalizerBase"
> class' canonicalizeSubTree() method calls to DOOM methods.
> In that method, handleAttributesSubtree() calls DOOM's
> ElementImpl.getAttributes() method. The Time spent on getAttributes()
> has amounted to around 10% of total cpu time. When, I looked at the time
> taken by the same method of CXF, it only used less than 1% of cpu time. So,
> clearly there's something wrong in here.
>
> I attached a screen shot to have a look at.
> i went through the source of Axis2 and CXF. I pasted the method so, all of
> you can have look. Please analyze them and suggest what we can do to remove
> this overhead.
>
> Thanks & Regards,
> --KasunBG
>
> =========================================================================
> CXF:
> /**
> * Retrieve all the Attributes as a set. Note that this API is
> inherited
> * from Node rather than specified on Element; in fact only Elements
> will
> * ever have Attributes, but they want to allow folks to "blindly"
> operate
> * on the tree as a set of Nodes.
> */
> public NamedNodeMap getAttributes() {
>
> if (needsSyncData()) {
> synchronizeData();
> }
> if (attributes == null) {
> attributes = new AttributeMap(this, null);
> }
> return attributes;
>
> } // getAttributes():NamedNodeMap
>
>
> =========================================================================
> Axis2:
> /** Returns the set of attributes of this node and the namespace
> declarations available. */
> public NamedNodeMap getAttributes() {
> AttributeMap attributeMap = new AttributeMap(this);
>
> // Add the set of existing attrs
> for (int i = 0; i < this.attributes.getLength(); i++) {
> attributeMap.addItem((Attr) this.attributes.getItem(i));
> }
>
> // Add the NS declarations
> if (this.namespaces != null) {
> Iterator nsDecls = this.namespaces.keySet().iterator();
> while (nsDecls.hasNext()) {
> String prefix = (String) nsDecls.next();
> if (prefix != null && !"".equals(prefix)
> && !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
> OMNamespace ns = (OMNamespace)
> this.namespaces.get(prefix);
> AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
> .getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
>
> // Set the default NS attr if any
> if (this.namespace != null
> && (this.namespace.getPrefix() == null || ""
> .equals(this.namespace.getPrefix()))
> && this.namespace.getNamespaceURI() != null) {
>
> // check if the parent of this element has the same
> namespace
> // as the default and if NOT add the attr
> boolean parentHasSameDefaultNS = this.parentNode != null &&
> this.parentNode.getNamespaceURI() != null &&
>
> this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
> (this.parentNode.getPrefix() == null ||
> this.parentNode.getPrefix().equals(""));
>
> if (!parentHasSameDefaultNS) {
> AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
>
> this.namespace.getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
> }
>
> return attributeMap;
> }
>
> =========================================================================
>
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://kasunbg.blogspot.com
> Twitter: http://twitter.com/kasunbg
>
>
> On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
> kshanth2101@gmail.com> wrote:
>
>> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
>> <sa...@gmail.com> wrote:
>> > Can you guys provide patches for these improvements?
>>
>> Ok, we will do.
>>
>> Thanks,
>> Kishanthan.
>> >
>> > Thanks,
>> > Samisa...
>> >
>> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
>> > <ks...@gmail.com> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> We also did some changes in DOMUtil class. We combined the getName and
>> >> getPrefix methods to one method. Because there were quite large calls
>> >> to these methods which took quite large time. So by combining these
>> >> methods to one and reducing the number of calls to the method, we were
>> >> able to get some improvements in time values.
>> >>
>> >> Thanks,
>> >> --
>> >> Kishanthan.T
>> >> University of Moratuwa.
>> >> SriLanka.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> > Thanks,
>> > Samisa...
>> >
>> > Samisa Abeysinghe
>> > VP Engineering
>> > WSO2 Inc.
>> > http://wso2.com
>> > http://wso2.org
>> >
>>
>>
>>
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello,
This is regarding the final results (1st-phase) of Axis2/Axiom/Rampart
performance improvement. We wrapped up the improvements done so far, and ran
final test runs to compare the running times of Axis2 compared to CXF. There
are further improvements that can be done. We are aware about some of them,
so hopefully if it needs any further improvements, that can be done.
Basically, now we are trying to bring Rampart2 forward by replacing current
Rampart1. We need to complete it and there are some legal things to be
carried out as the coding happened outside the Apache Version Control (It
was a final year project done by four students at University of Moratuwa
namely, Sameera, Isuru, Saliya and Kalani).
In Rampart2, there is Rampart xml-security which is built on OM model. If we
use it, then there is no need of DOOM (the axiom-dom module). Hopefully,
this should improve performance considerably, as DOOM was the main culprit
in slowing down Axis2 as of now.
And, with these improvements, we are glad to say that Axis2 is now more than
30% faster than CXF for small samples as of the latest test result shows
:) This still need to be confirmed though! Overall, DOOM is now much
improved and is very closer to CXF in other usecases, in performance-wise.
[0], [1] contains the final result charts, comparing Axis2 trunk version
vs. Axis2 with Improvements vs. CXF. We were mainly focused on improving
Sign & Encrypt (signencr) usecase for large samples, because improving it
will improve other scenarios as well, as it involves all the scenarios and
handlers (signing, encryption, tree building etc.)
We have submitted the Patch for Axiom module at WS-Commons Jira [2]. Patch
for Rampart to be uploaded soon.
[0] http://imagebin.ca/view/NzqFZNAR.html
[1] http://imagebin.ca/view/0NDzdKp.html
[2] https://issues.apache.org/jira/browse/WSCOMMONS-556
Thank you!
--KasunBG
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Tue, Jul 13, 2010 at 2:29 PM, Kasun Gajasinghe <ka...@gmail.com> wrote:
> Hello Devs,
> One more iteration on Axis2 and CXF Profiles revealed an interesting point.
> This is in the call tree, in the point which
> "org.apache.xml.security.c14n.implementations.CanonicalizerBase"
> class' canonicalizeSubTree() method calls to DOOM methods.
> In that method, handleAttributesSubtree() calls DOOM's
> ElementImpl.getAttributes() method. The Time spent on getAttributes()
> has amounted to around 10% of total cpu time. When, I looked at the time
> taken by the same method of CXF, it only used less than 1% of cpu time. So,
> clearly there's something wrong in here.
>
> I attached a screen shot to have a look at.
> i went through the source of Axis2 and CXF. I pasted the method so, all of
> you can have look. Please analyze them and suggest what we can do to remove
> this overhead.
>
> Thanks & Regards,
> --KasunBG
>
> =========================================================================
> CXF:
> /**
> * Retrieve all the Attributes as a set. Note that this API is
> inherited
> * from Node rather than specified on Element; in fact only Elements
> will
> * ever have Attributes, but they want to allow folks to "blindly"
> operate
> * on the tree as a set of Nodes.
> */
> public NamedNodeMap getAttributes() {
>
> if (needsSyncData()) {
> synchronizeData();
> }
> if (attributes == null) {
> attributes = new AttributeMap(this, null);
> }
> return attributes;
>
> } // getAttributes():NamedNodeMap
>
>
> =========================================================================
> Axis2:
> /** Returns the set of attributes of this node and the namespace
> declarations available. */
> public NamedNodeMap getAttributes() {
> AttributeMap attributeMap = new AttributeMap(this);
>
> // Add the set of existing attrs
> for (int i = 0; i < this.attributes.getLength(); i++) {
> attributeMap.addItem((Attr) this.attributes.getItem(i));
> }
>
> // Add the NS declarations
> if (this.namespaces != null) {
> Iterator nsDecls = this.namespaces.keySet().iterator();
> while (nsDecls.hasNext()) {
> String prefix = (String) nsDecls.next();
> if (prefix != null && !"".equals(prefix)
> && !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
> OMNamespace ns = (OMNamespace)
> this.namespaces.get(prefix);
> AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
> .getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
>
> // Set the default NS attr if any
> if (this.namespace != null
> && (this.namespace.getPrefix() == null || ""
> .equals(this.namespace.getPrefix()))
> && this.namespace.getNamespaceURI() != null) {
>
> // check if the parent of this element has the same
> namespace
> // as the default and if NOT add the attr
> boolean parentHasSameDefaultNS = this.parentNode != null &&
> this.parentNode.getNamespaceURI() != null &&
>
> this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
> (this.parentNode.getPrefix() == null ||
> this.parentNode.getPrefix().equals(""));
>
> if (!parentHasSameDefaultNS) {
> AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
>
> this.namespace.getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
> }
>
> return attributeMap;
> }
>
> =========================================================================
>
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://kasunbg.blogspot.com
> Twitter: http://twitter.com/kasunbg
>
>
> On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
> kshanth2101@gmail.com> wrote:
>
>> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
>> <sa...@gmail.com> wrote:
>> > Can you guys provide patches for these improvements?
>>
>> Ok, we will do.
>>
>> Thanks,
>> Kishanthan.
>> >
>> > Thanks,
>> > Samisa...
>> >
>> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
>> > <ks...@gmail.com> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> We also did some changes in DOMUtil class. We combined the getName and
>> >> getPrefix methods to one method. Because there were quite large calls
>> >> to these methods which took quite large time. So by combining these
>> >> methods to one and reducing the number of calls to the method, we were
>> >> able to get some improvements in time values.
>> >>
>> >> Thanks,
>> >> --
>> >> Kishanthan.T
>> >> University of Moratuwa.
>> >> SriLanka.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> > Thanks,
>> > Samisa...
>> >
>> > Samisa Abeysinghe
>> > VP Engineering
>> > WSO2 Inc.
>> > http://wso2.com
>> > http://wso2.org
>> >
>>
>>
>>
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello,
This is regarding the final results (1st-phase) of Axis2/Axiom/Rampart
performance improvement. We wrapped up the improvements done so far, and ran
final test runs to compare the running times of Axis2 compared to CXF. There
are further improvements that can be done. We are aware about some of them,
so hopefully if it needs any further improvements, that can be done.
Basically, now we are trying to bring Rampart2 forward by replacing current
Rampart1. We need to complete it and there are some legal things to be
carried out as the coding happened outside the Apache Version Control (It
was a final year project done by four students at University of Moratuwa
namely, Sameera, Isuru, Saliya and Kalani).
In Rampart2, there is Rampart xml-security which is built on OM model. If we
use it, then there is no need of DOOM (the axiom-dom module). Hopefully,
this should improve performance considerably, as DOOM was the main culprit
in slowing down Axis2 as of now.
And, with these improvements, we are glad to say that Axis2 is now more than
30% faster than CXF for small samples as of the latest test result shows
:) This still need to be confirmed though! Overall, DOOM is now much
improved and is very closer to CXF in other usecases, in performance-wise.
[0], [1] contains the final result charts, comparing Axis2 trunk version
vs. Axis2 with Improvements vs. CXF. We were mainly focused on improving
Sign & Encrypt (signencr) usecase for large samples, because improving it
will improve other scenarios as well, as it involves all the scenarios and
handlers (signing, encryption, tree building etc.)
We have submitted the Patch for Axiom module at WS-Commons Jira [2]. Patch
for Rampart to be uploaded soon.
[0] http://imagebin.ca/view/NzqFZNAR.html
[1] http://imagebin.ca/view/0NDzdKp.html
[2] https://issues.apache.org/jira/browse/WSCOMMONS-556
Thank you!
--KasunBG
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Tue, Jul 13, 2010 at 2:29 PM, Kasun Gajasinghe <ka...@gmail.com> wrote:
> Hello Devs,
> One more iteration on Axis2 and CXF Profiles revealed an interesting point.
> This is in the call tree, in the point which
> "org.apache.xml.security.c14n.implementations.CanonicalizerBase"
> class' canonicalizeSubTree() method calls to DOOM methods.
> In that method, handleAttributesSubtree() calls DOOM's
> ElementImpl.getAttributes() method. The Time spent on getAttributes()
> has amounted to around 10% of total cpu time. When, I looked at the time
> taken by the same method of CXF, it only used less than 1% of cpu time. So,
> clearly there's something wrong in here.
>
> I attached a screen shot to have a look at.
> i went through the source of Axis2 and CXF. I pasted the method so, all of
> you can have look. Please analyze them and suggest what we can do to remove
> this overhead.
>
> Thanks & Regards,
> --KasunBG
>
> =========================================================================
> CXF:
> /**
> * Retrieve all the Attributes as a set. Note that this API is
> inherited
> * from Node rather than specified on Element; in fact only Elements
> will
> * ever have Attributes, but they want to allow folks to "blindly"
> operate
> * on the tree as a set of Nodes.
> */
> public NamedNodeMap getAttributes() {
>
> if (needsSyncData()) {
> synchronizeData();
> }
> if (attributes == null) {
> attributes = new AttributeMap(this, null);
> }
> return attributes;
>
> } // getAttributes():NamedNodeMap
>
>
> =========================================================================
> Axis2:
> /** Returns the set of attributes of this node and the namespace
> declarations available. */
> public NamedNodeMap getAttributes() {
> AttributeMap attributeMap = new AttributeMap(this);
>
> // Add the set of existing attrs
> for (int i = 0; i < this.attributes.getLength(); i++) {
> attributeMap.addItem((Attr) this.attributes.getItem(i));
> }
>
> // Add the NS declarations
> if (this.namespaces != null) {
> Iterator nsDecls = this.namespaces.keySet().iterator();
> while (nsDecls.hasNext()) {
> String prefix = (String) nsDecls.next();
> if (prefix != null && !"".equals(prefix)
> && !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
> OMNamespace ns = (OMNamespace)
> this.namespaces.get(prefix);
> AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
> .getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
>
> // Set the default NS attr if any
> if (this.namespace != null
> && (this.namespace.getPrefix() == null || ""
> .equals(this.namespace.getPrefix()))
> && this.namespace.getNamespaceURI() != null) {
>
> // check if the parent of this element has the same
> namespace
> // as the default and if NOT add the attr
> boolean parentHasSameDefaultNS = this.parentNode != null &&
> this.parentNode.getNamespaceURI() != null &&
>
> this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
> (this.parentNode.getPrefix() == null ||
> this.parentNode.getPrefix().equals(""));
>
> if (!parentHasSameDefaultNS) {
> AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
>
> this.namespace.getNamespaceURI(), this.factory);
> attr.setOMNamespace(new NamespaceImpl(
> OMConstants.XMLNS_NS_URI,
> OMConstants.XMLNS_NS_PREFIX));
> attributeMap.addItem(attr);
> }
> }
> }
>
> return attributeMap;
> }
>
> =========================================================================
>
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://kasunbg.blogspot.com
> Twitter: http://twitter.com/kasunbg
>
>
> On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
> kshanth2101@gmail.com> wrote:
>
>> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
>> <sa...@gmail.com> wrote:
>> > Can you guys provide patches for these improvements?
>>
>> Ok, we will do.
>>
>> Thanks,
>> Kishanthan.
>> >
>> > Thanks,
>> > Samisa...
>> >
>> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
>> > <ks...@gmail.com> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> We also did some changes in DOMUtil class. We combined the getName and
>> >> getPrefix methods to one method. Because there were quite large calls
>> >> to these methods which took quite large time. So by combining these
>> >> methods to one and reducing the number of calls to the method, we were
>> >> able to get some improvements in time values.
>> >>
>> >> Thanks,
>> >> --
>> >> Kishanthan.T
>> >> University of Moratuwa.
>> >> SriLanka.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> > Thanks,
>> > Samisa...
>> >
>> > Samisa Abeysinghe
>> > VP Engineering
>> > WSO2 Inc.
>> > http://wso2.com
>> > http://wso2.org
>> >
>>
>>
>>
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello Devs,
One more iteration on Axis2 and CXF Profiles revealed an interesting point.
This is in the call tree, in the point which
"org.apache.xml.security.c14n.implementations.CanonicalizerBase"
class' canonicalizeSubTree() method calls to DOOM methods.
In that method, handleAttributesSubtree() calls DOOM's
ElementImpl.getAttributes() method. The Time spent on getAttributes()
has amounted to around 10% of total cpu time. When, I looked at the time
taken by the same method of CXF, it only used less than 1% of cpu time. So,
clearly there's something wrong in here.
I attached a screen shot to have a look at.
i went through the source of Axis2 and CXF. I pasted the method so, all of
you can have look. Please analyze them and suggest what we can do to remove
this overhead.
Thanks & Regards,
--KasunBG
=========================================================================
CXF:
/**
* Retrieve all the Attributes as a set. Note that this API is inherited
* from Node rather than specified on Element; in fact only Elements
will
* ever have Attributes, but they want to allow folks to "blindly"
operate
* on the tree as a set of Nodes.
*/
public NamedNodeMap getAttributes() {
if (needsSyncData()) {
synchronizeData();
}
if (attributes == null) {
attributes = new AttributeMap(this, null);
}
return attributes;
} // getAttributes():NamedNodeMap
=========================================================================
Axis2:
/** Returns the set of attributes of this node and the namespace
declarations available. */
public NamedNodeMap getAttributes() {
AttributeMap attributeMap = new AttributeMap(this);
// Add the set of existing attrs
for (int i = 0; i < this.attributes.getLength(); i++) {
attributeMap.addItem((Attr) this.attributes.getItem(i));
}
// Add the NS declarations
if (this.namespaces != null) {
Iterator nsDecls = this.namespaces.keySet().iterator();
while (nsDecls.hasNext()) {
String prefix = (String) nsDecls.next();
if (prefix != null && !"".equals(prefix)
&& !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
OMNamespace ns = (OMNamespace)
this.namespaces.get(prefix);
AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
// Set the default NS attr if any
if (this.namespace != null
&& (this.namespace.getPrefix() == null || ""
.equals(this.namespace.getPrefix()))
&& this.namespace.getNamespaceURI() != null) {
// check if the parent of this element has the same
namespace
// as the default and if NOT add the attr
boolean parentHasSameDefaultNS = this.parentNode != null &&
this.parentNode.getNamespaceURI() != null &&
this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
(this.parentNode.getPrefix() == null ||
this.parentNode.getPrefix().equals(""));
if (!parentHasSameDefaultNS) {
AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
this.namespace.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
}
return attributeMap;
}
=========================================================================
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
> <sa...@gmail.com> wrote:
> > Can you guys provide patches for these improvements?
>
> Ok, we will do.
>
> Thanks,
> Kishanthan.
> >
> > Thanks,
> > Samisa...
> >
> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> > <ks...@gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> We also did some changes in DOMUtil class. We combined the getName and
> >> getPrefix methods to one method. Because there were quite large calls
> >> to these methods which took quite large time. So by combining these
> >> methods to one and reducing the number of calls to the method, we were
> >> able to get some improvements in time values.
> >>
> >> Thanks,
> >> --
> >> Kishanthan.T
> >> University of Moratuwa.
> >> SriLanka.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> > Thanks,
> > Samisa...
> >
> > Samisa Abeysinghe
> > VP Engineering
> > WSO2 Inc.
> > http://wso2.com
> > http://wso2.org
> >
>
>
>
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello Devs,
One more iteration on Axis2 and CXF Profiles revealed an interesting point.
This is in the call tree, in the point which
"org.apache.xml.security.c14n.implementations.CanonicalizerBase"
class' canonicalizeSubTree() method calls to DOOM methods.
In that method, handleAttributesSubtree() calls DOOM's
ElementImpl.getAttributes() method. The Time spent on getAttributes()
has amounted to around 10% of total cpu time. When, I looked at the time
taken by the same method of CXF, it only used less than 1% of cpu time. So,
clearly there's something wrong in here.
I attached a screen shot to have a look at.
i went through the source of Axis2 and CXF. I pasted the method so, all of
you can have look. Please analyze them and suggest what we can do to remove
this overhead.
Thanks & Regards,
--KasunBG
=========================================================================
CXF:
/**
* Retrieve all the Attributes as a set. Note that this API is inherited
* from Node rather than specified on Element; in fact only Elements
will
* ever have Attributes, but they want to allow folks to "blindly"
operate
* on the tree as a set of Nodes.
*/
public NamedNodeMap getAttributes() {
if (needsSyncData()) {
synchronizeData();
}
if (attributes == null) {
attributes = new AttributeMap(this, null);
}
return attributes;
} // getAttributes():NamedNodeMap
=========================================================================
Axis2:
/** Returns the set of attributes of this node and the namespace
declarations available. */
public NamedNodeMap getAttributes() {
AttributeMap attributeMap = new AttributeMap(this);
// Add the set of existing attrs
for (int i = 0; i < this.attributes.getLength(); i++) {
attributeMap.addItem((Attr) this.attributes.getItem(i));
}
// Add the NS declarations
if (this.namespaces != null) {
Iterator nsDecls = this.namespaces.keySet().iterator();
while (nsDecls.hasNext()) {
String prefix = (String) nsDecls.next();
if (prefix != null && !"".equals(prefix)
&& !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
OMNamespace ns = (OMNamespace)
this.namespaces.get(prefix);
AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
// Set the default NS attr if any
if (this.namespace != null
&& (this.namespace.getPrefix() == null || ""
.equals(this.namespace.getPrefix()))
&& this.namespace.getNamespaceURI() != null) {
// check if the parent of this element has the same
namespace
// as the default and if NOT add the attr
boolean parentHasSameDefaultNS = this.parentNode != null &&
this.parentNode.getNamespaceURI() != null &&
this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
(this.parentNode.getPrefix() == null ||
this.parentNode.getPrefix().equals(""));
if (!parentHasSameDefaultNS) {
AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
this.namespace.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
}
return attributeMap;
}
=========================================================================
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
> <sa...@gmail.com> wrote:
> > Can you guys provide patches for these improvements?
>
> Ok, we will do.
>
> Thanks,
> Kishanthan.
> >
> > Thanks,
> > Samisa...
> >
> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> > <ks...@gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> We also did some changes in DOMUtil class. We combined the getName and
> >> getPrefix methods to one method. Because there were quite large calls
> >> to these methods which took quite large time. So by combining these
> >> methods to one and reducing the number of calls to the method, we were
> >> able to get some improvements in time values.
> >>
> >> Thanks,
> >> --
> >> Kishanthan.T
> >> University of Moratuwa.
> >> SriLanka.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> > Thanks,
> > Samisa...
> >
> > Samisa Abeysinghe
> > VP Engineering
> > WSO2 Inc.
> > http://wso2.com
> > http://wso2.org
> >
>
>
>
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello Devs,
One more iteration on Axis2 and CXF Profiles revealed an interesting point.
This is in the call tree, in the point which
"org.apache.xml.security.c14n.implementations.CanonicalizerBase"
class' canonicalizeSubTree() method calls to DOOM methods.
In that method, handleAttributesSubtree() calls DOOM's
ElementImpl.getAttributes() method. The Time spent on getAttributes()
has amounted to around 10% of total cpu time. When, I looked at the time
taken by the same method of CXF, it only used less than 1% of cpu time. So,
clearly there's something wrong in here.
I attached a screen shot to have a look at.
i went through the source of Axis2 and CXF. I pasted the method so, all of
you can have look. Please analyze them and suggest what we can do to remove
this overhead.
Thanks & Regards,
--KasunBG
=========================================================================
CXF:
/**
* Retrieve all the Attributes as a set. Note that this API is inherited
* from Node rather than specified on Element; in fact only Elements
will
* ever have Attributes, but they want to allow folks to "blindly"
operate
* on the tree as a set of Nodes.
*/
public NamedNodeMap getAttributes() {
if (needsSyncData()) {
synchronizeData();
}
if (attributes == null) {
attributes = new AttributeMap(this, null);
}
return attributes;
} // getAttributes():NamedNodeMap
=========================================================================
Axis2:
/** Returns the set of attributes of this node and the namespace
declarations available. */
public NamedNodeMap getAttributes() {
AttributeMap attributeMap = new AttributeMap(this);
// Add the set of existing attrs
for (int i = 0; i < this.attributes.getLength(); i++) {
attributeMap.addItem((Attr) this.attributes.getItem(i));
}
// Add the NS declarations
if (this.namespaces != null) {
Iterator nsDecls = this.namespaces.keySet().iterator();
while (nsDecls.hasNext()) {
String prefix = (String) nsDecls.next();
if (prefix != null && !"".equals(prefix)
&& !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
OMNamespace ns = (OMNamespace)
this.namespaces.get(prefix);
AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
// Set the default NS attr if any
if (this.namespace != null
&& (this.namespace.getPrefix() == null || ""
.equals(this.namespace.getPrefix()))
&& this.namespace.getNamespaceURI() != null) {
// check if the parent of this element has the same
namespace
// as the default and if NOT add the attr
boolean parentHasSameDefaultNS = this.parentNode != null &&
this.parentNode.getNamespaceURI() != null &&
this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
(this.parentNode.getPrefix() == null ||
this.parentNode.getPrefix().equals(""));
if (!parentHasSameDefaultNS) {
AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
this.namespace.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
}
return attributeMap;
}
=========================================================================
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
> <sa...@gmail.com> wrote:
> > Can you guys provide patches for these improvements?
>
> Ok, we will do.
>
> Thanks,
> Kishanthan.
> >
> > Thanks,
> > Samisa...
> >
> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> > <ks...@gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> We also did some changes in DOMUtil class. We combined the getName and
> >> getPrefix methods to one method. Because there were quite large calls
> >> to these methods which took quite large time. So by combining these
> >> methods to one and reducing the number of calls to the method, we were
> >> able to get some improvements in time values.
> >>
> >> Thanks,
> >> --
> >> Kishanthan.T
> >> University of Moratuwa.
> >> SriLanka.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> > Thanks,
> > Samisa...
> >
> > Samisa Abeysinghe
> > VP Engineering
> > WSO2 Inc.
> > http://wso2.com
> > http://wso2.org
> >
>
>
>
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello Devs,
One more iteration on Axis2 and CXF Profiles revealed an interesting point.
This is in the call tree, in the point which
"org.apache.xml.security.c14n.implementations.CanonicalizerBase"
class' canonicalizeSubTree() method calls to DOOM methods.
In that method, handleAttributesSubtree() calls DOOM's
ElementImpl.getAttributes() method. The Time spent on getAttributes()
has amounted to around 10% of total cpu time. When, I looked at the time
taken by the same method of CXF, it only used less than 1% of cpu time. So,
clearly there's something wrong in here.
I attached a screen shot to have a look at.
i went through the source of Axis2 and CXF. I pasted the method so, all of
you can have look. Please analyze them and suggest what we can do to remove
this overhead.
Thanks & Regards,
--KasunBG
=========================================================================
CXF:
/**
* Retrieve all the Attributes as a set. Note that this API is inherited
* from Node rather than specified on Element; in fact only Elements
will
* ever have Attributes, but they want to allow folks to "blindly"
operate
* on the tree as a set of Nodes.
*/
public NamedNodeMap getAttributes() {
if (needsSyncData()) {
synchronizeData();
}
if (attributes == null) {
attributes = new AttributeMap(this, null);
}
return attributes;
} // getAttributes():NamedNodeMap
=========================================================================
Axis2:
/** Returns the set of attributes of this node and the namespace
declarations available. */
public NamedNodeMap getAttributes() {
AttributeMap attributeMap = new AttributeMap(this);
// Add the set of existing attrs
for (int i = 0; i < this.attributes.getLength(); i++) {
attributeMap.addItem((Attr) this.attributes.getItem(i));
}
// Add the NS declarations
if (this.namespaces != null) {
Iterator nsDecls = this.namespaces.keySet().iterator();
while (nsDecls.hasNext()) {
String prefix = (String) nsDecls.next();
if (prefix != null && !"".equals(prefix)
&& !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
OMNamespace ns = (OMNamespace)
this.namespaces.get(prefix);
AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
// Set the default NS attr if any
if (this.namespace != null
&& (this.namespace.getPrefix() == null || ""
.equals(this.namespace.getPrefix()))
&& this.namespace.getNamespaceURI() != null) {
// check if the parent of this element has the same
namespace
// as the default and if NOT add the attr
boolean parentHasSameDefaultNS = this.parentNode != null &&
this.parentNode.getNamespaceURI() != null &&
this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
(this.parentNode.getPrefix() == null ||
this.parentNode.getPrefix().equals(""));
if (!parentHasSameDefaultNS) {
AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
this.namespace.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
}
return attributeMap;
}
=========================================================================
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
> <sa...@gmail.com> wrote:
> > Can you guys provide patches for these improvements?
>
> Ok, we will do.
>
> Thanks,
> Kishanthan.
> >
> > Thanks,
> > Samisa...
> >
> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> > <ks...@gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> We also did some changes in DOMUtil class. We combined the getName and
> >> getPrefix methods to one method. Because there were quite large calls
> >> to these methods which took quite large time. So by combining these
> >> methods to one and reducing the number of calls to the method, we were
> >> able to get some improvements in time values.
> >>
> >> Thanks,
> >> --
> >> Kishanthan.T
> >> University of Moratuwa.
> >> SriLanka.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> > Thanks,
> > Samisa...
> >
> > Samisa Abeysinghe
> > VP Engineering
> > WSO2 Inc.
> > http://wso2.com
> > http://wso2.org
> >
>
>
>
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
Hello Devs,
One more iteration on Axis2 and CXF Profiles revealed an interesting point.
This is in the call tree, in the point which
"org.apache.xml.security.c14n.implementations.CanonicalizerBase"
class' canonicalizeSubTree() method calls to DOOM methods.
In that method, handleAttributesSubtree() calls DOOM's
ElementImpl.getAttributes() method. The Time spent on getAttributes()
has amounted to around 10% of total cpu time. When, I looked at the time
taken by the same method of CXF, it only used less than 1% of cpu time. So,
clearly there's something wrong in here.
I attached a screen shot to have a look at.
i went through the source of Axis2 and CXF. I pasted the method so, all of
you can have look. Please analyze them and suggest what we can do to remove
this overhead.
Thanks & Regards,
--KasunBG
=========================================================================
CXF:
/**
* Retrieve all the Attributes as a set. Note that this API is inherited
* from Node rather than specified on Element; in fact only Elements
will
* ever have Attributes, but they want to allow folks to "blindly"
operate
* on the tree as a set of Nodes.
*/
public NamedNodeMap getAttributes() {
if (needsSyncData()) {
synchronizeData();
}
if (attributes == null) {
attributes = new AttributeMap(this, null);
}
return attributes;
} // getAttributes():NamedNodeMap
=========================================================================
Axis2:
/** Returns the set of attributes of this node and the namespace
declarations available. */
public NamedNodeMap getAttributes() {
AttributeMap attributeMap = new AttributeMap(this);
// Add the set of existing attrs
for (int i = 0; i < this.attributes.getLength(); i++) {
attributeMap.addItem((Attr) this.attributes.getItem(i));
}
// Add the NS declarations
if (this.namespaces != null) {
Iterator nsDecls = this.namespaces.keySet().iterator();
while (nsDecls.hasNext()) {
String prefix = (String) nsDecls.next();
if (prefix != null && !"".equals(prefix)
&& !prefix.equals(OMConstants.XMLNS_NS_PREFIX)) {
OMNamespace ns = (OMNamespace)
this.namespaces.get(prefix);
AttrImpl attr = new AttrImpl(this.ownerNode, prefix, ns
.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
// Set the default NS attr if any
if (this.namespace != null
&& (this.namespace.getPrefix() == null || ""
.equals(this.namespace.getPrefix()))
&& this.namespace.getNamespaceURI() != null) {
// check if the parent of this element has the same
namespace
// as the default and if NOT add the attr
boolean parentHasSameDefaultNS = this.parentNode != null &&
this.parentNode.getNamespaceURI() != null &&
this.parentNode.getNamespaceURI().equals(this.getNamespaceURI()) &&
(this.parentNode.getPrefix() == null ||
this.parentNode.getPrefix().equals(""));
if (!parentHasSameDefaultNS) {
AttrImpl attr = new AttrImpl(this.ownerNode, "xmlns",
this.namespace.getNamespaceURI(), this.factory);
attr.setOMNamespace(new NamespaceImpl(
OMConstants.XMLNS_NS_URI,
OMConstants.XMLNS_NS_PREFIX));
attributeMap.addItem(attr);
}
}
}
return attributeMap;
}
=========================================================================
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://kasunbg.blogspot.com
Twitter: http://twitter.com/kasunbg
On Mon, Jul 12, 2010 at 9:25 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
> <sa...@gmail.com> wrote:
> > Can you guys provide patches for these improvements?
>
> Ok, we will do.
>
> Thanks,
> Kishanthan.
> >
> > Thanks,
> > Samisa...
> >
> > On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> > <ks...@gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> We also did some changes in DOMUtil class. We combined the getName and
> >> getPrefix methods to one method. Because there were quite large calls
> >> to these methods which took quite large time. So by combining these
> >> methods to one and reducing the number of calls to the method, we were
> >> able to get some improvements in time values.
> >>
> >> Thanks,
> >> --
> >> Kishanthan.T
> >> University of Moratuwa.
> >> SriLanka.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> > Thanks,
> > Samisa...
> >
> > Samisa Abeysinghe
> > VP Engineering
> > WSO2 Inc.
> > http://wso2.com
> > http://wso2.org
> >
>
>
>
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> Can you guys provide patches for these improvements?
Ok, we will do.
Thanks,
Kishanthan.
>
> Thanks,
> Samisa...
>
> On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> <ks...@gmail.com> wrote:
>>
>> Hi All,
>>
>> We also did some changes in DOMUtil class. We combined the getName and
>> getPrefix methods to one method. Because there were quite large calls
>> to these methods which took quite large time. So by combining these
>> methods to one and reducing the number of calls to the method, we were
>> able to get some improvements in time values.
>>
>> Thanks,
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> Can you guys provide patches for these improvements?
Ok, we will do.
Thanks,
Kishanthan.
>
> Thanks,
> Samisa...
>
> On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> <ks...@gmail.com> wrote:
>>
>> Hi All,
>>
>> We also did some changes in DOMUtil class. We combined the getName and
>> getPrefix methods to one method. Because there were quite large calls
>> to these methods which took quite large time. So by combining these
>> methods to one and reducing the number of calls to the method, we were
>> able to get some improvements in time values.
>>
>> Thanks,
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> Can you guys provide patches for these improvements?
Ok, we will do.
Thanks,
Kishanthan.
>
> Thanks,
> Samisa...
>
> On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> <ks...@gmail.com> wrote:
>>
>> Hi All,
>>
>> We also did some changes in DOMUtil class. We combined the getName and
>> getPrefix methods to one method. Because there were quite large calls
>> to these methods which took quite large time. So by combining these
>> methods to one and reducing the number of calls to the method, we were
>> able to get some improvements in time values.
>>
>> Thanks,
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> Can you guys provide patches for these improvements?
Ok, we will do.
Thanks,
Kishanthan.
>
> Thanks,
> Samisa...
>
> On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> <ks...@gmail.com> wrote:
>>
>> Hi All,
>>
>> We also did some changes in DOMUtil class. We combined the getName and
>> getPrefix methods to one method. Because there were quite large calls
>> to these methods which took quite large time. So by combining these
>> methods to one and reducing the number of calls to the method, we were
>> able to get some improvements in time values.
>>
>> Thanks,
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
On Mon, Jul 12, 2010 at 8:58 PM, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> Can you guys provide patches for these improvements?
Ok, we will do.
Thanks,
Kishanthan.
>
> Thanks,
> Samisa...
>
> On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah
> <ks...@gmail.com> wrote:
>>
>> Hi All,
>>
>> We also did some changes in DOMUtil class. We combined the getName and
>> getPrefix methods to one method. Because there were quite large calls
>> to these methods which took quite large time. So by combining these
>> methods to one and reducing the number of calls to the method, we were
>> able to get some improvements in time values.
>>
>> Thanks,
>> --
>> Kishanthan.T
>> University of Moratuwa.
>> SriLanka.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Can you guys provide patches for these improvements?
Thanks,
Samisa...
On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> Hi All,
>
> We also did some changes in DOMUtil class. We combined the getName and
> getPrefix methods to one method. Because there were quite large calls
> to these methods which took quite large time. So by combining these
> methods to one and reducing the number of calls to the method, we were
> able to get some improvements in time values.
>
> Thanks,
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Can you guys provide patches for these improvements?
Thanks,
Samisa...
On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> Hi All,
>
> We also did some changes in DOMUtil class. We combined the getName and
> getPrefix methods to one method. Because there were quite large calls
> to these methods which took quite large time. So by combining these
> methods to one and reducing the number of calls to the method, we were
> able to get some improvements in time values.
>
> Thanks,
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Can you guys provide patches for these improvements?
Thanks,
Samisa...
On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> Hi All,
>
> We also did some changes in DOMUtil class. We combined the getName and
> getPrefix methods to one method. Because there were quite large calls
> to these methods which took quite large time. So by combining these
> methods to one and reducing the number of calls to the method, we were
> able to get some improvements in time values.
>
> Thanks,
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Can you guys provide patches for these improvements?
Thanks,
Samisa...
On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> Hi All,
>
> We also did some changes in DOMUtil class. We combined the getName and
> getPrefix methods to one method. Because there were quite large calls
> to these methods which took quite large time. So by combining these
> methods to one and reducing the number of calls to the method, we were
> able to get some improvements in time values.
>
> Thanks,
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Can you guys provide patches for these improvements?
Thanks,
Samisa...
On Mon, Jul 12, 2010 at 12:16 PM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> Hi All,
>
> We also did some changes in DOMUtil class. We combined the getName and
> getPrefix methods to one method. Because there were quite large calls
> to these methods which took quite large time. So by combining these
> methods to one and reducing the number of calls to the method, we were
> able to get some improvements in time values.
>
> Thanks,
> --
> Kishanthan.T
> University of Moratuwa.
> SriLanka.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
Hi All,
We also did some changes in DOMUtil class. We combined the getName and
getPrefix methods to one method. Because there were quite large calls
to these methods which took quite large time. So by combining these
methods to one and reducing the number of calls to the method, we were
able to get some improvements in time values.
Thanks,
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
Hi All,
We also did some changes in DOMUtil class. We combined the getName and
getPrefix methods to one method. Because there were quite large calls
to these methods which took quite large time. So by combining these
methods to one and reducing the number of calls to the method, we were
able to get some improvements in time values.
Thanks,
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
Hi All,
We also did some changes in DOMUtil class. We combined the getName and
getPrefix methods to one method. Because there were quite large calls
to these methods which took quite large time. So by combining these
methods to one and reducing the number of calls to the method, we were
able to get some improvements in time values.
Thanks,
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
Hi All,
We also did some changes in DOMUtil class. We combined the getName and
getPrefix methods to one method. Because there were quite large calls
to these methods which took quite large time. So by combining these
methods to one and reducing the number of calls to the method, we were
able to get some improvements in time values.
Thanks,
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
Hi All,
We also did some changes in DOMUtil class. We combined the getName and
getPrefix methods to one method. Because there were quite large calls
to these methods which took quite large time. So by combining these
methods to one and reducing the number of calls to the method, we were
able to get some improvements in time values.
Thanks,
--
Kishanthan.T
University of Moratuwa.
SriLanka.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Mon, Jul 12, 2010 at 7:35 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> 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 <ka...@gmail.com>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 <ka...@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 <th...@wso2.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>>
>>>
>>>
>> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Mon, Jul 12, 2010 at 7:35 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> 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 <ka...@gmail.com>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 <ka...@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 <th...@wso2.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>>
>>>
>>>
>> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Mon, Jul 12, 2010 at 7:35 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> 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 <ka...@gmail.com>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 <ka...@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 <th...@wso2.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>>
>>>
>>>
>> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Mon, Jul 12, 2010 at 7:35 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> 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 <ka...@gmail.com>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 <ka...@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 <th...@wso2.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>>
>>>
>>>
>> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Mon, Jul 12, 2010 at 7:35 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> 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 <ka...@gmail.com>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 <ka...@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 <th...@wso2.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>>
>>>
>>>
>> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Have you been able to make any code level improvements?
Samisa...
On Tue, Jul 6, 2010 at 1:42 PM, Kasun Gajasinghe <ka...@gmail.com> 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 <ka...@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 <th...@wso2.com>wrote:
>>
>>>
>>>
>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>
>>
>>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Have you been able to make any code level improvements?
Samisa...
On Tue, Jul 6, 2010 at 1:42 PM, Kasun Gajasinghe <ka...@gmail.com> 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 <ka...@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 <th...@wso2.com>wrote:
>>
>>>
>>>
>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>
>>
>>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Have you been able to make any code level improvements?
Samisa...
On Tue, Jul 6, 2010 at 1:42 PM, Kasun Gajasinghe <ka...@gmail.com> 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 <ka...@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 <th...@wso2.com>wrote:
>>
>>>
>>>
>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>
>>
>>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Have you been able to make any code level improvements?
Samisa...
On Tue, Jul 6, 2010 at 1:42 PM, Kasun Gajasinghe <ka...@gmail.com> 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 <ka...@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 <th...@wso2.com>wrote:
>>
>>>
>>>
>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>
>>
>>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Have you been able to make any code level improvements?
Samisa...
On Tue, Jul 6, 2010 at 1:42 PM, Kasun Gajasinghe <ka...@gmail.com> 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 <ka...@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 <th...@wso2.com>wrote:
>>
>>>
>>>
>>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>>
>>
>>
> Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
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 <ka...@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 <th...@wso2.com>wrote:
>
>>
>>
>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
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 <ka...@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 <th...@wso2.com>wrote:
>
>>
>>
>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
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 <ka...@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 <th...@wso2.com>wrote:
>
>>
>>
>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
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 <ka...@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 <th...@wso2.com>wrote:
>
>>
>>
>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>
>
>
Re: Improving Axis2/Rampart performance.
Posted by Kasun Gajasinghe <ka...@gmail.com>.
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 <ka...@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 <th...@wso2.com>wrote:
>
>>
>>
>> On Thu, Jun 24, 2010 at 5:45 PM, Martin Gainty <mg...@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
>>
>
>