The latest performance reports point to canonicalization as the major CPU
eater...
that part needs to be virtually completely redone...
----- Original Message -----
From: "Werner Dittmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Friday, October 10, 2008 11:58 PM
Subject: Re: WSS4J 1.5.4 Encryption Performance Question
Shawn,
the most expensive part during encryption (and in some cases also
Signature) is the asymmetric encryption part. Several years ago (in
the beginning of WSS4J :-) ) I did some performance tests to detect
where time is lost.
I assume you use the standard way to encrypt/decrypt data, thus the
following process is used:
- get information about the public key of the receiver (usually using
the receiver's x.500 certificate)
- generate a random key that WSS4J uses to symmetrically encrypt the
content, for example the SOAP body on in your case the user name token
- encrypt this random key a using public key algorithm, for example RSA
(which public key algo will be used depends on the contents of the
certificate)
- build up the Security header.
The step to encrypt the random key is the most expensive. Your
configuration shows that you are using UsernameTokenSignature thus you
do not do a "real" Signature using a x.500 certificate bu a specific
variant where data of the user name token is used to compute a signature.
This explains why the signature processing is fast in your test frame.
During the tests I could speed up the public key processing by using
another security provider - Apache JuiCE which is a Java JCE wrapper
that uses openSSL as crpyto engine that gave me between 30-50% better
performance compared with bouncy castle.
Thus to speed up this you may consider using keys that do not depend on
certificates - AFAIK there is also a way to send keys using user name
token, but this needs to be confirmed.
Regards,
Werner
Shawn McKinney schrieb:
Hello,
We have been using Axis1 and WSS4J in production for 3 years now. Our
token configuration varies by client but typically is Usernametoken
encrypt, timestamp with nonce.
Recently we have begun the preparations to convert our clients and
services to support Axis2 and Rampart. Out of this effort I have been
running micro benchmarks for the following 4 scenarios:
UNT1: Usernametoken, unencrypt, unsigned, timestamp, nonce
UNT2: Usernametoken, unencrypt, signed, timestamp, nonce
UNT3: Usernametoken, encrypt, signed, timestamp, nonce
UNT4: Usernametoken, encrypt, signed, timestamp, nonce
Each of the 4 scenarios effect crypto operations on username token only
(if at all). No encryption or signing of elements within XML payload
have been tested with this benchmark.
The test results show:
* signing username token is relatively unexpensive - good news here!
* encrypting username token is relatively expensive - not so good news
for us.
Related to 2nd bullet above. Is there something we are doing wrong? Our
results show a 35% dropoff in overall throughput when enabling
encryption of the username token itself. Are these results consistent
with what others have found on same, or are we likely doing something
wrong here?
More details on the tests can be found below:
Client Machine 1:
* AMD 64 Dual Core
* 2 GHz, 2 GB RAM
* WinXP
* Axis2 client driven by Jmeter Server Machine 2:
* Intel Dual core
* 2 GHz, 3 GB RAM
* Linux - Centos 5
* Running in Tomcat 5.5.x
* Both machines using Java 1.5
* Both machines using bouncycastle's bcprov-jdk15-135.jar
Test Objective:
* Compare the 4 UNT types, measure relative performance costs for
performing cryptographic functions.
4 Test Cases:
* 10 threads X 5000 service transactions = 50K transactions per test.
* Measurements cover entire roundtrip of transaction including time
to perform crypto operations on both client and server machines.
Benchmark Summary
1. UNT1
i. Avg response time: 116 ms
ii. Avg throughput: 85.2/s
iii.Avg CPU utilization (client): 37%
2. UNT2
i. Avg response time: 127 ms
ii. Avg throughput: 78.3/s
iii.Avg CPU utilization (client): 42%
3. UNT3
i. Avg response time: 177 ms
ii. Avg throughput: 56.2/s
iii.Avg CPU utilization (client): 34%
4. UNT4
i. Avg response time: 181 ms
ii. Avg throughput: 54.8/s
iii.Avg CPU utilization (client): 36%
Axis2/Rampart Client-side config:
<parameter name="OutflowSecurity">
<action>
...
<!-- UNT1: -->
<items>UsernameToken Timestamp</items>
<!-- UNT2: --> <!-- UserNameTokenSignature Timestamp works -->
<!-- UNT3: --> <!--items>UsernameTokenSignature Timestamp</items-->
<!-- UNT4: --> <!--items>UsernameTokenSignature Encrypt
Timestamp</items-->
... <passwordType>PasswordText</passwordType> <addUTElements>Nonce
Created</addUTElements>
<encryptionParts>{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken</encryptionParts>
<signatureParts>{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken</signatureParts>
</action>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
