You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Dennis Sosnoski <dm...@sosnoski.com> on 2010/01/31 00:12:53 UTC
Axis2/Rampart WS-Security performance
Following up on some earlier discussions of Axis2/Rampart WS-Security
performance, devWorks has now published my latest article in the Java
Web Services series, comparing Axis2/Rampart with Metro WS-Security
performance: http://www.ibm.com/developerworks/java/library/j-jws11/ The
results are very bad for Axis2/Rampart, with Metro more than twice as
fast overall in the WS-Security tests.
As mentioned in the article, some timing tests with
org.apache.rampart.TIME logging seemed to indicate that a lot of the
overhead is actually occurring outside the Rampart handler. I suspect
that Axis2 has fallen into the same performance pit as Axis in doing
conversions to and from different forms of the message.
If anyone is interested in investigating further, the full source code
for the performance comparison is available as a download from the article.
- Dennis
--
Dennis M. Sosnoski
Java XML and Web Services
Axis2 Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
Re: Axis2/Rampart WS-Security performance
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Prabath,
I just tried a couple of simple tests, using the signing+encryption
policy on the server and trying different variations of policy
(including no policy) on the client with both Metro and Axis2. All the
client variations were rejected by the server in both cases, so at least
at this basic level both Metro and Axis2/Rampart are enforcing the
server policy.
What sort of shortfalls did you see in Metro's policy-based validations?
- Dennis
Prabath Siriwardena wrote:
> Hi Dennis;
>
> Nice analysis...
>
> Does Metro do policy based validations?
>
> Rampart does validations at two levels - first validation at the
> message level with info gathered from the message it self - and then
> validate the entire message with the defined policy.
>
> If somebody skips the second step - it could open up holes for attacks
> like XML wrapping attacks.
>
> I found few occasions that Metro doesn't do policy based validations.
> Would be glad if you could please confirm it.
>
> Thanks & regards.
> -Prabath
>
> Dennis Sosnoski wrote:
>> Following up on some earlier discussions of Axis2/Rampart WS-Security
>> performance, devWorks has now published my latest article in the Java
>> Web Services series, comparing Axis2/Rampart with Metro WS-Security
>> performance: http://www.ibm.com/developerworks/java/library/j-jws11/
>> The results are very bad for Axis2/Rampart, with Metro more than
>> twice as fast overall in the WS-Security tests.
>>
>> As mentioned in the article, some timing tests with
>> org.apache.rampart.TIME logging seemed to indicate that a lot of the
>> overhead is actually occurring outside the Rampart handler. I suspect
>> that Axis2 has fallen into the same performance pit as Axis in doing
>> conversions to and from different forms of the message.
>>
>> If anyone is interested in investigating further, the full source
>> code for the performance comparison is available as a download from
>> the article.
>>
>> - Dennis
>>
>
Re: Axis2/Rampart WS-Security performance
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Prabath,
I just tried a couple of simple tests, using the signing+encryption
policy on the server and trying different variations of policy
(including no policy) on the client with both Metro and Axis2. All the
client variations were rejected by the server in both cases, so at least
at this basic level both Metro and Axis2/Rampart are enforcing the
server policy.
What sort of shortfalls did you see in Metro's policy-based validations?
- Dennis
Prabath Siriwardena wrote:
> Hi Dennis;
>
> Nice analysis...
>
> Does Metro do policy based validations?
>
> Rampart does validations at two levels - first validation at the
> message level with info gathered from the message it self - and then
> validate the entire message with the defined policy.
>
> If somebody skips the second step - it could open up holes for attacks
> like XML wrapping attacks.
>
> I found few occasions that Metro doesn't do policy based validations.
> Would be glad if you could please confirm it.
>
> Thanks & regards.
> -Prabath
>
> Dennis Sosnoski wrote:
>> Following up on some earlier discussions of Axis2/Rampart WS-Security
>> performance, devWorks has now published my latest article in the Java
>> Web Services series, comparing Axis2/Rampart with Metro WS-Security
>> performance: http://www.ibm.com/developerworks/java/library/j-jws11/
>> The results are very bad for Axis2/Rampart, with Metro more than
>> twice as fast overall in the WS-Security tests.
>>
>> As mentioned in the article, some timing tests with
>> org.apache.rampart.TIME logging seemed to indicate that a lot of the
>> overhead is actually occurring outside the Rampart handler. I suspect
>> that Axis2 has fallen into the same performance pit as Axis in doing
>> conversions to and from different forms of the message.
>>
>> If anyone is interested in investigating further, the full source
>> code for the performance comparison is available as a download from
>> the article.
>>
>> - Dennis
>>
>
Re: Axis2/Rampart WS-Security performance
Posted by Prabath Siriwardena <pr...@wso2.com>.
Hi Dennis;
Nice analysis...
Does Metro do policy based validations?
Rampart does validations at two levels - first validation at the message
level with info gathered from the message it self - and then validate
the entire message with the defined policy.
If somebody skips the second step - it could open up holes for attacks
like XML wrapping attacks.
I found few occasions that Metro doesn't do policy based validations.
Would be glad if you could please confirm it.
Thanks & regards.
-Prabath
Dennis Sosnoski wrote:
> Following up on some earlier discussions of Axis2/Rampart WS-Security
> performance, devWorks has now published my latest article in the Java
> Web Services series, comparing Axis2/Rampart with Metro WS-Security
> performance: http://www.ibm.com/developerworks/java/library/j-jws11/
> The results are very bad for Axis2/Rampart, with Metro more than twice
> as fast overall in the WS-Security tests.
>
> As mentioned in the article, some timing tests with
> org.apache.rampart.TIME logging seemed to indicate that a lot of the
> overhead is actually occurring outside the Rampart handler. I suspect
> that Axis2 has fallen into the same performance pit as Axis in doing
> conversions to and from different forms of the message.
>
> If anyone is interested in investigating further, the full source code
> for the performance comparison is available as a download from the
> article.
>
> - Dennis
>
Re: Axis2/Rampart WS-Security performance
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Amila
>
> > In the very first scenario upto 640 concurrency level both have
> same through put while for 1280 threads UE has a sudden increment
> and for 2560 other ESB has a relatively high change. What could be
> the reason for that?
> Which set are you referring to - the WS-Security case? Sorry I do
> not see what you mean..
>
> 1. Direct Proxy Scenario 500b case.
> And also
> 1. Direct Proxy Scenario 1K case
> for 640 concurrency other ESB has performed well but 1280 and 2560
> done well.
>
> I am just wondering reason for these anomalities.
I think the anomaly is most possibly due to a full GC of the JVM - but
that its limited to the 500 byte / 1280 users case only - for the other
ESB. The usual trend would be for the TPS to increase gradually, and
then drop again after the sweet point of the ESB for the load considered.
If the same test is repeated multiple times, and the averages taken, the
results could eliminate these spikes - but the process could take some
number of hours more. These results were obtained after a warm up run of
1000 iterations at 20 users for each of the 4 scenarios - as we did in
Rounds 1, 2, and 3 before. This was to trigger the JVM to compile the
code with optimization - usually reached after around 10,000 iterations
of a method.
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Axis2/Rampart WS-Security performance
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Feb 11, 2010 at 10:23 PM, Asankha C. Perera <as...@apache.org>wrote:
> Hi Amila
> > how many messages you sent for one scenario test?
> > i.e for eg 500b message with 640 threads
> This depends on the concurrency, and can be found exactly by looking at
> the script used to run the load test. For example, when 20 users were
> being used, the iterations were 1000, while for 2560 users, the
> iterations were 10 - this was to keep the overall test execution time
> limited.
> > In the very first scenario upto 640 concurrency level both have same
> > through put while for 1280
> > threads UE has a sudden increment and for 2560 other ESB has a
> > relatively high change. What could be
> > the reason for that?
> Which set are you referring to - the WS-Security case? Sorry I do not
> see what you mean..
>
1. Direct Proxy Scenario 500b case.
And also
1. Direct Proxy Scenario 1K case
for 640 concurrency other ESB has performed well but 1280 and 2560 done
well.
I am just wondering reason for these anomalities.
thanks,
Amila.
> > Are all these results repeatable?
> Yes, you could re-run the test very easily on an EC2 node as per the
> details given at the bottom of the article - it will ofcourse take a
> couple of hours to complete all scenarios - so ensure that your SSH
> client timeout is disabled :D
>
> cheers
> asankha
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Axis2/Rampart WS-Security performance
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Feb 11, 2010 at 10:23 PM, Asankha C. Perera <as...@apache.org>wrote:
> Hi Amila
> > how many messages you sent for one scenario test?
> > i.e for eg 500b message with 640 threads
> This depends on the concurrency, and can be found exactly by looking at
> the script used to run the load test. For example, when 20 users were
> being used, the iterations were 1000, while for 2560 users, the
> iterations were 10 - this was to keep the overall test execution time
> limited.
> > In the very first scenario upto 640 concurrency level both have same
> > through put while for 1280
> > threads UE has a sudden increment and for 2560 other ESB has a
> > relatively high change. What could be
> > the reason for that?
> Which set are you referring to - the WS-Security case? Sorry I do not
> see what you mean..
>
1. Direct Proxy Scenario 500b case.
And also
1. Direct Proxy Scenario 1K case
for 640 concurrency other ESB has performed well but 1280 and 2560 done
well.
I am just wondering reason for these anomalities.
thanks,
Amila.
> > Are all these results repeatable?
> Yes, you could re-run the test very easily on an EC2 node as per the
> details given at the bottom of the article - it will ofcourse take a
> couple of hours to complete all scenarios - so ensure that your SSH
> client timeout is disabled :D
>
> cheers
> asankha
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Axis2/Rampart WS-Security performance
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Amila
> how many messages you sent for one scenario test?
> i.e for eg 500b message with 640 threads
This depends on the concurrency, and can be found exactly by looking at
the script used to run the load test. For example, when 20 users were
being used, the iterations were 1000, while for 2560 users, the
iterations were 10 - this was to keep the overall test execution time
limited.
> In the very first scenario upto 640 concurrency level both have same
> through put while for 1280
> threads UE has a sudden increment and for 2560 other ESB has a
> relatively high change. What could be
> the reason for that?
Which set are you referring to - the WS-Security case? Sorry I do not
see what you mean..
> Are all these results repeatable?
Yes, you could re-run the test very easily on an EC2 node as per the
details given at the bottom of the article - it will ofcourse take a
couple of hours to complete all scenarios - so ensure that your SSH
client timeout is disabled :D
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Axis2/Rampart WS-Security performance
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Amila
> how many messages you sent for one scenario test?
> i.e for eg 500b message with 640 threads
This depends on the concurrency, and can be found exactly by looking at
the script used to run the load test. For example, when 20 users were
being used, the iterations were 1000, while for 2560 users, the
iterations were 10 - this was to keep the overall test execution time
limited.
> In the very first scenario upto 640 concurrency level both have same
> through put while for 1280
> threads UE has a sudden increment and for 2560 other ESB has a
> relatively high change. What could be
> the reason for that?
Which set are you referring to - the WS-Security case? Sorry I do not
see what you mean..
> Are all these results repeatable?
Yes, you could re-run the test very easily on an EC2 node as per the
details given at the bottom of the article - it will ofcourse take a
couple of hours to complete all scenarios - so ensure that your SSH
client timeout is disabled :D
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Axis2/Rampart WS-Security performance
Posted by Amila Suriarachchi <am...@gmail.com>.
hi Asankha,
how many messages you sent for one scenario test?
i.e for eg 500b message with 640 threads
In the very first scenario upto 640 concurrency level both have same through
put while for 1280
threads UE has a sudden increment and for 2560 other ESB has a relatively
high change. What could be
the reason for that? Are all these results repeatable?
thanks,
Amila.
On Thu, Feb 11, 2010 at 12:52 PM, Asankha C. Perera <as...@apache.org>wrote:
> Hi Dennis
>
> I looked at WSS4j as a foundation for providing WS-Security support for the
> UltraESB, <http://adroitlogic.org> and realized the fact that its not
> really optimized for use on an ESB; in addition to a few more issues I came
> across. Thus we developed a new library - which is functionally similar to
> WSS4J, which performs over 3 X times or better than WSS4J. However,
> currently it does not yet ship as a separate library - although we may
> decide to do that if there is user interest and demand.
>
> Here is a comparison of it in use against WS-Security based on
> WSS4J/Rampart
>
>
> http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html
>
> cheers
> asankha
>
>
> Following up on some earlier discussions of Axis2/Rampart WS-Security
> performance, devWorks has now published my latest article in the Java Web
> Services series, comparing Axis2/Rampart with Metro WS-Security performance:
> http://www.ibm.com/developerworks/java/library/j-jws11/ The results are
> very bad for Axis2/Rampart, with Metro more than twice as fast overall in
> the WS-Security tests.
>
> As mentioned in the article, some timing tests with org.apache.rampart.TIME
> logging seemed to indicate that a lot of the overhead is actually occurring
> outside the Rampart handler. I suspect that Axis2 has fallen into the same
> performance pit as Axis in doing conversions to and from different forms of
> the message.
>
> If anyone is interested in investigating further, the full source code for
> the performance comparison is available as a download from the article.
>
> - Dennis
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
> http://esbmagic.blogspot.com
>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Axis2/Rampart WS-Security performance
Posted by Amila Suriarachchi <am...@gmail.com>.
hi Asankha,
how many messages you sent for one scenario test?
i.e for eg 500b message with 640 threads
In the very first scenario upto 640 concurrency level both have same through
put while for 1280
threads UE has a sudden increment and for 2560 other ESB has a relatively
high change. What could be
the reason for that? Are all these results repeatable?
thanks,
Amila.
On Thu, Feb 11, 2010 at 12:52 PM, Asankha C. Perera <as...@apache.org>wrote:
> Hi Dennis
>
> I looked at WSS4j as a foundation for providing WS-Security support for the
> UltraESB, <http://adroitlogic.org> and realized the fact that its not
> really optimized for use on an ESB; in addition to a few more issues I came
> across. Thus we developed a new library - which is functionally similar to
> WSS4J, which performs over 3 X times or better than WSS4J. However,
> currently it does not yet ship as a separate library - although we may
> decide to do that if there is user interest and demand.
>
> Here is a comparison of it in use against WS-Security based on
> WSS4J/Rampart
>
>
> http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html
>
> cheers
> asankha
>
>
> Following up on some earlier discussions of Axis2/Rampart WS-Security
> performance, devWorks has now published my latest article in the Java Web
> Services series, comparing Axis2/Rampart with Metro WS-Security performance:
> http://www.ibm.com/developerworks/java/library/j-jws11/ The results are
> very bad for Axis2/Rampart, with Metro more than twice as fast overall in
> the WS-Security tests.
>
> As mentioned in the article, some timing tests with org.apache.rampart.TIME
> logging seemed to indicate that a lot of the overhead is actually occurring
> outside the Rampart handler. I suspect that Axis2 has fallen into the same
> performance pit as Axis in doing conversions to and from different forms of
> the message.
>
> If anyone is interested in investigating further, the full source code for
> the performance comparison is available as a download from the article.
>
> - Dennis
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
> http://esbmagic.blogspot.com
>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
RE: Axis2/Rampart WS-Security performance
Posted by Martin Gainty <mg...@hotmail.com>.
i found building an AXIOM DOM object graph the easiest way to transmit both the inmessage and outmessage
For each complexType Axis WSDL2jAVA/wsdl2cODE their own parse method which in turn references an extensionMapper tied to that parse ..so 250 complexTypes have 250 different parse lookup methods (and 250 different extensionMappers)
the AXIOM object graph contains all the neceesary information and could be used to lookup namespace,localName and value
it seems that Axis iterative use of parse/extensionMapper introduces considerable memory/cpu overhead (as well as tying the service to a static configuration)
thoughts?
Martin Gainty
______________________________________________
please do not alter/modify or disrupt this transmission. Thank You
> Date: Thu, 11 Feb 2010 22:19:08 +1300
> From: dms@sosnoski.com
> To: axis-dev@ws.apache.org
> Subject: Re: Axis2/Rampart WS-Security performance
>
> Hi Asankha,
>
> From what I've seen, most of the performance problems with
> Axis2/Rampart lay outside of WSS4J. Rampart could certainly do a better
> job of optimizing its use of WSS4J - for example by not going through
> the overhead of constructing an AXIOM DOM representation of the message
> and passing that to WSS4J when the security configuration does not
> require any processing on a particular message (such as for the response
> message when only using UsernameToken) - but for cases where security
> processing is actually needed, Rampart also does not appear to be the
> cause of most of the added overhead.
>
> I suspect the problems lie in the Axis2/AXIOM interaction, with
> conversions between different forms of the message soaking up a lot of
> time (and memory). One of these conversions, the building of an AXIOM
> DOM representation, does show up as part of the Rampart timings, but I
> suspect there are more conversions going on outside of Rampart once the
> message body has to be parsed into a document model. The original Axis
> has problems of this type, with repeated conversions between string and
> DOM representations of a message which add a lot of overhead.
>
> I'm only working with open source code in my articles, so your products
> are not something I'd cover. If you want a better comparison for
> WS-Security performance I suggest you try Metro to see how that compares
> to your code.
>
> - Dennis
>
>
> Asankha C. Perera wrote:
> > Hi Dennis
> >
> > I looked at WSS4j as a foundation for providing WS-Security support
> > for the UltraESB, <http://adroitlogic.org> and realized the fact that
> > its not really optimized for use on an ESB; in addition to a few more
> > issues I came across. Thus we developed a new library - which is
> > functionally similar to WSS4J, which performs over 3 X times or better
> > than WSS4J. However, currently it does not yet ship as a separate
> > library - although we may decide to do that if there is user interest
> > and demand.
> >
> > Here is a comparison of it in use against WS-Security based on
> > WSS4J/Rampart
> >
> > http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html
> >
> > cheers
> > asankha
> >
> >> Following up on some earlier discussions of Axis2/Rampart WS-Security
> >> performance, devWorks has now published my latest article in the Java
> >> Web Services series, comparing Axis2/Rampart with Metro WS-Security
> >> performance: http://www.ibm.com/developerworks/java/library/j-jws11/
> >> The results are very bad for Axis2/Rampart, with Metro more than
> >> twice as fast overall in the WS-Security tests.
> >>
> >> As mentioned in the article, some timing tests with
> >> org.apache.rampart.TIME logging seemed to indicate that a lot of the
> >> overhead is actually occurring outside the Rampart handler. I suspect
> >> that Axis2 has fallen into the same performance pit as Axis in doing
> >> conversions to and from different forms of the message.
> >>
> >> If anyone is interested in investigating further, the full source
> >> code for the performance comparison is available as a download from
> >> the article.
> >>
> >> - Dennis
> >>
> > --
> > Asankha C. Perera
> > AdroitLogic, http://adroitlogic.org
> >
> > http://esbmagic.blogspot.com
> >
> >
> >
> >
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/
Re: Axis2/Rampart WS-Security performance
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Asankha,
From what I've seen, most of the performance problems with
Axis2/Rampart lay outside of WSS4J. Rampart could certainly do a better
job of optimizing its use of WSS4J - for example by not going through
the overhead of constructing an AXIOM DOM representation of the message
and passing that to WSS4J when the security configuration does not
require any processing on a particular message (such as for the response
message when only using UsernameToken) - but for cases where security
processing is actually needed, Rampart also does not appear to be the
cause of most of the added overhead.
I suspect the problems lie in the Axis2/AXIOM interaction, with
conversions between different forms of the message soaking up a lot of
time (and memory). One of these conversions, the building of an AXIOM
DOM representation, does show up as part of the Rampart timings, but I
suspect there are more conversions going on outside of Rampart once the
message body has to be parsed into a document model. The original Axis
has problems of this type, with repeated conversions between string and
DOM representations of a message which add a lot of overhead.
I'm only working with open source code in my articles, so your products
are not something I'd cover. If you want a better comparison for
WS-Security performance I suggest you try Metro to see how that compares
to your code.
- Dennis
Asankha C. Perera wrote:
> Hi Dennis
>
> I looked at WSS4j as a foundation for providing WS-Security support
> for the UltraESB, <http://adroitlogic.org> and realized the fact that
> its not really optimized for use on an ESB; in addition to a few more
> issues I came across. Thus we developed a new library - which is
> functionally similar to WSS4J, which performs over 3 X times or better
> than WSS4J. However, currently it does not yet ship as a separate
> library - although we may decide to do that if there is user interest
> and demand.
>
> Here is a comparison of it in use against WS-Security based on
> WSS4J/Rampart
>
> http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html
>
> cheers
> asankha
>
>> Following up on some earlier discussions of Axis2/Rampart WS-Security
>> performance, devWorks has now published my latest article in the Java
>> Web Services series, comparing Axis2/Rampart with Metro WS-Security
>> performance: http://www.ibm.com/developerworks/java/library/j-jws11/
>> The results are very bad for Axis2/Rampart, with Metro more than
>> twice as fast overall in the WS-Security tests.
>>
>> As mentioned in the article, some timing tests with
>> org.apache.rampart.TIME logging seemed to indicate that a lot of the
>> overhead is actually occurring outside the Rampart handler. I suspect
>> that Axis2 has fallen into the same performance pit as Axis in doing
>> conversions to and from different forms of the message.
>>
>> If anyone is interested in investigating further, the full source
>> code for the performance comparison is available as a download from
>> the article.
>>
>> - Dennis
>>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
Re: Axis2/Rampart WS-Security performance
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Dennis
I looked at WSS4j as a foundation for providing WS-Security support for
the UltraESB, <http://adroitlogic.org> and realized the fact that its
not really optimized for use on an ESB; in addition to a few more issues
I came across. Thus we developed a new library - which is functionally
similar to WSS4J, which performs over 3 X times or better than WSS4J.
However, currently it does not yet ship as a separate library - although
we may decide to do that if there is user interest and demand.
Here is a comparison of it in use against WS-Security based on WSS4J/Rampart
http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html
cheers
asankha
> Following up on some earlier discussions of Axis2/Rampart WS-Security
> performance, devWorks has now published my latest article in the Java
> Web Services series, comparing Axis2/Rampart with Metro WS-Security
> performance: http://www.ibm.com/developerworks/java/library/j-jws11/
> The results are very bad for Axis2/Rampart, with Metro more than twice
> as fast overall in the WS-Security tests.
>
> As mentioned in the article, some timing tests with
> org.apache.rampart.TIME logging seemed to indicate that a lot of the
> overhead is actually occurring outside the Rampart handler. I suspect
> that Axis2 has fallen into the same performance pit as Axis in doing
> conversions to and from different forms of the message.
>
> If anyone is interested in investigating further, the full source code
> for the performance comparison is available as a download from the
> article.
>
> - Dennis
>
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Axis2/Rampart WS-Security performance
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Dennis
I looked at WSS4j as a foundation for providing WS-Security support for
the UltraESB, <http://adroitlogic.org> and realized the fact that its
not really optimized for use on an ESB; in addition to a few more issues
I came across. Thus we developed a new library - which is functionally
similar to WSS4J, which performs over 3 X times or better than WSS4J.
However, currently it does not yet ship as a separate library - although
we may decide to do that if there is user interest and demand.
Here is a comparison of it in use against WS-Security based on WSS4J/Rampart
http://adroitlogic.org/samples-articles-and-tutorials/15-tutorials/48-esb-performance.html
cheers
asankha
> Following up on some earlier discussions of Axis2/Rampart WS-Security
> performance, devWorks has now published my latest article in the Java
> Web Services series, comparing Axis2/Rampart with Metro WS-Security
> performance: http://www.ibm.com/developerworks/java/library/j-jws11/
> The results are very bad for Axis2/Rampart, with Metro more than twice
> as fast overall in the WS-Security tests.
>
> As mentioned in the article, some timing tests with
> org.apache.rampart.TIME logging seemed to indicate that a lot of the
> overhead is actually occurring outside the Rampart handler. I suspect
> that Axis2 has fallen into the same performance pit as Axis in doing
> conversions to and from different forms of the message.
>
> If anyone is interested in investigating further, the full source code
> for the performance comparison is available as a download from the
> article.
>
> - Dennis
>
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Axis2/Rampart WS-Security performance
Posted by Prabath Siriwardena <pr...@wso2.com>.
Hi Dennis;
Nice analysis...
Does Metro do policy based validations?
Rampart does validations at two levels - first validation at the message
level with info gathered from the message it self - and then validate
the entire message with the defined policy.
If somebody skips the second step - it could open up holes for attacks
like XML wrapping attacks.
I found few occasions that Metro doesn't do policy based validations.
Would be glad if you could please confirm it.
Thanks & regards.
-Prabath
Dennis Sosnoski wrote:
> Following up on some earlier discussions of Axis2/Rampart WS-Security
> performance, devWorks has now published my latest article in the Java
> Web Services series, comparing Axis2/Rampart with Metro WS-Security
> performance: http://www.ibm.com/developerworks/java/library/j-jws11/
> The results are very bad for Axis2/Rampart, with Metro more than twice
> as fast overall in the WS-Security tests.
>
> As mentioned in the article, some timing tests with
> org.apache.rampart.TIME logging seemed to indicate that a lot of the
> overhead is actually occurring outside the Rampart handler. I suspect
> that Axis2 has fallen into the same performance pit as Axis in doing
> conversions to and from different forms of the message.
>
> If anyone is interested in investigating further, the full source code
> for the performance comparison is available as a download from the
> article.
>
> - Dennis
>