[
https://issues.apache.org/jira/browse/RAMPART-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amila Jayasekara updated RAMPART-298:
-------------------------------------
Attachment: performance-comparison.pdf
RAMPART-298.diff
Providing a patch for this issue. Patch is created on svn revision 1053937
relative to trunk.
(http://svn.apache.org/repos/asf/axis/axis2/java/rampart/trunk)
Cause for the issue :-
This experiment uses sign and encrypt (symmetric) binding. In symmetric binding
the initiator is suppose to create a token and the same token is used by the
receiver. When ever initiator expects a result back, initiator has to cache the
token it used to send the message. Tokens are stored in a TokneStorage class
within Rampart. The default implementation within rampart is
SimpleTokenStorage. Once initiator decrypt the reply, we can remove the token
from token storage. But according to current implementation rampart does not
remove tokens from the cache, which are already validated. Therefore number of
tokens increase per each request → Rampart does a linear search per each
request → Time per request increases with the number of requests.
Solution :-
Remove tokens from the Token storage when the reply is validated (at initiator
end).
Results after applying this patch :-
Now we are not experiencing a growth in the request time when number of
requests are increased. Following is a result comparison,
Before,
Number of requests Time (ms) Timer per request (ms)
100 3322 33.22
200 6351 31.755
300 9115 30.3833333333
400 13460 33.65
500 19061 38.122
600 26924 44.8733333333
After,
Number of requests Time (ms) Timer per request (ms)
100 3352 33.52
200 5688 28.44
300 7889 26.2966666667
400 9903 24.7575
500 11799 23.598
600 13934 23.2233333333
700 16465 23.5214285714
A more detailed summary of results is attached to this issue
(performance-comparison.pdf). As you can see in above results, timer per
request is stabilizing when the number of requests, increase. More or less it
is coming to a number around 23 ms.
(Note : These tests are carried out in a 4 CPU machine, speed - 2.53 GHz,
memory - 4GB. Thus crypto caching was also enabled)
Thanks
AmilaJ
> Client using SymmetricBinding runs slower and slower as more requests are made
> ------------------------------------------------------------------------------
>
> Key: RAMPART-298
> URL: https://issues.apache.org/jira/browse/RAMPART-298
> Project: Rampart
> Issue Type: Bug
> Components: rampart-core
> Affects Versions: 1.5
> Reporter: Dennis Sosnoski
> Attachments: axis2-symm-bug.zip, performance-comparison.pdf,
> RAMPART-298.diff, rampart-receiver.pdf
>
>
> Tests run with Axis2/Rampart client talking to an Axis2/Rampart server using
> SymmetricBinding get slower and slower as the number of requests goes up.
> Here are some typical figures:
> 100 requests - 8.0 seconds
> 200 requests - 19.1 seconds
> 300 requests - 40.9 seconds
> 400 requests - 77.0 seconds
> 500 requests - 134.4 seconds
> Since this appears to be strictly a function of the number of requests run
> using a single client, I suspect the Rampart client code is doing something
> like caching all the generated secret keys and then doing a linear search to
> find the one referenced in a response.
> To demonstrate the problem using the attached code, first edit the build
> properties to set the path to the Axis2 installation, then build using "ant"
> command, upload .aars to server, and run test using "ant run-encr". The
> number of requests can be changed in the build.properties file before each
> test run.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
