AW: Some infos about performance of WSS4J/XML-SEC together with Axis

["Dittmann, Werner" <we...@siemens.com>]

All,

using the same hardware as described below, using the same
test scenario I did some tests using a special BouncyCastle
library that uses the openSSL crypto library to do
encryption /decryption, hashing, and signature.

To enable special BC provider no modifications in WSS4J
nor in XML-SEC were necessary (except setting the provider
id which is a standard method in both cases).

The new combination results in some very good performance
enhancements (old values in paranthesis):

Request send (client side):
Total time from enter WSDoAllSender up to exit: typically 
about 16-18ms (34-37ms)
- time spend to sign:  about 8-9ms (27-28)ms 
				5-6ms (24-24ms) XML-SEC
				processing in Signature class

- time spend to encrypt (symm/asymm): about 5-6ms (5-6ms)
  no real improvement here because only a few bytes of
  data to encrypt


Request receive (server side):
Total time from enter WSDoAllReceiver up to exit: typically 
about 24-26ms (42-47ms)

- time spend to verify:	  about 2-4ms (5-6ms)

- time spend to decrypt:  about 12-14ms (24-26ms)
				  (about 40% of time spent in
				  decrypting the symmetric key
				  using the private key (3-5ms), 
				  rest in 3DES decryption of
				  content)

WSS4J processing is about twice as fast when using the openSSL 
crypto lib compared to the SUN or BC provider. Caveat: this is
no "Java only" application anymore but needs the openSSL crypto
library - and this is a C implementation.

The most prominent enhancement was in the public key processing:
when doing encryption with the private key I got a 3-4 times
better performance, this also results in very good XML-SEC
processing times.

Because the WSS4J processing is only part of the overall
processing of a request/response pair (Axis internal, operating
system overhead, internal JVM processing, GC, etc need some CPU
cycles as well) the overall improvement is somewhere between 30%
and 40%, depending on the other processing.

Regards,
Werner


> -----Ursprüngliche Nachricht-----
> Von: Werner Dittmann [mailto:Werner.Dittmann@t-online.de] 
> Gesendet: Dienstag, 13. September 2005 23:58
> An: wss4j-dev@ws.apache.org
> Betreff: Some infos about performance of WSS4J together with Axis
> 
> 
> All,
> 
> because quite some mail was triggered because of ideas to use better
> parsers, faster memory algorithms, etc. I did some 
> performance tests. To
> do this I used the "scenario3" of the interop tests. You may find the
> deployment files in the interop directory and subdirectories thereof.
> 
> Test case: Scenario 3
> Request flow: Sign body, encrypt body after signing, add a timestap
> - Signature certificate in the request (DirectReference), Signature
>   algorithm is RSA
> 
> - Certificate used for encryption identified using SKI, symmetric
>   encryption algorithm is tripple DES, encyrption key 
> generated using a
>   random generator and is encrypted using private key linked to the
>   certificate, algorithm used here is RSA
> 
> Response flow: same actions and attributes as for request
> 
> System:
> Hardware: AMD Athlon64 3000, 1GB Main mem
> Software: Linux (SuSe 9.2), Java J2SE JDK 1.4.2_07
> 
> Test setup:
> Standalone Axis client using WSDoAllSender / WSDoAllReceiver
> SimpleAxisServer as server using WSDoAllSender / WSDoAllReceiver
> 
> During the test the system was not empty, but no heavy active task
> were running. However, some time-spikes arise from other system
> activities.
> 
> Test run:
> One "Warmup run" request/response, then 20 timed 
> request/response pairs,
> several test runs using this test setup.
> 
> Several timeing points are used to get information about each step of
> the request and response processing.
> 
> No real time clock available, thus using the  standard system clock.
> This may result in time deviations.
> 
> Findings:
> The total time to execute the 20 request/response pairs was about
> 4100-4200ms, resulting in about 205-210ms per request/response.
> 
> Request send (client side):
> Total time from enter WSDoAllSender up to exit: typically 
> about 34-37ms
>  - time spend to sign:		       about 27-28ms 
> (24-24 ms XML-SEC
> 						     processing in
> 						     Signature class)
>  - time spend to encrypt (smy/asym):   about 5-6ms
> 
>  - the rest of 1-3ms was spend in Axis processing (get message, get
>    SOAP Enevelope as document, c14n the resulting SOAP request, etc.)
> 
> Request receive (server side):
> Total time from enter WSDoAllReceiver up to exit: typically about
> 42-47ms
> 
>  - time spend to verify:	      about 5-6ms
> 
>  - time spend to decrypt:	      about 24-26ms (about 60-65% of
> 						    time spent in
> 						    decrypting the
> 						    symmetric key using
> 						    the private key,
> 						    rest in 3DES)
> 
>  - time spend to check cert trust, check timestamp, header processing:
>    about 4-5ms
> 
>  - the rest of 6-10ms was spend in Axis processing (get message, get
>    SOAP Enevelope as document, c14n the resulting SOAP request, etc.).
>    Most of that spent for Axis serialization (about 4-6ms), 
> because the
>    received data is much larger (includes all the security 
> headers etc.)
>    thus deserialization takes more time.
> 
> The timing for the response flow is very similar to the request flow
> with one notable difference, but this could not be verified 
> in all cases
> (maybe this is due to the "not empty" system).
> 
> Conclusion:
> - The security processing for one direction takes ~75-85ms, for a
>   request / response pair about 150-170ms
> 
> - Most of that time is spent in Signature/Encryption/Decryption
>   processing (120-140ms), thus accounting for about 80-90% of the
>   time for security processing
> 
> - the rest is consumed by Axis, DOM, c14n, certificate 
> lookup, and other
>   security handler activities, operating system to send/receive the
>   data, etc.
> 
> Question: would such a result justify the efforts to speed up DOM,
> parser, etc. processing? Just to speed up the remaining 10-20%?
> 
> The real time consuming things in security are always the encryption,
> digest computations, public/private key computations etc.
> 
> I did a similar test with scenarion #1 (UsernameToken). With this
> scenarion a request/resonse pair takes about 22-25ms on my 
> system (same
> test setup as described above). Thus Axis and its engine is also not
> the bottleneck compared to the "real" security. If someone makes
> Axis or parsing faster - very good for normal usage, but it 
> doesn't help
> much for security unless someone finds the superfast implementation
> of the digest, encyrption, decryption algorithms.
> 
> Regards,
> Werner
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> 
>