[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rampart-dev
Subject:    Axis2/Rampart performance problems
From:       Dennis Sosnoski <dms () sosnoski ! com>
Date:       2009-12-07 7:35:45
Message-ID: 4B1CB051.3060707 () sosnoski ! com
[Download RAW message or body]

Axis2 performance when using Rampart is very poor. I published some 
figures on this a few months ago in 
http://www.ibm.com/developerworks/java/library/j-jws6/index.html and 
have now performed some tests comparing Axis2/Rampart performance with 
Metro. I was surprised to see that Metro's performance is much better 
than Axis2/Rampart for WS-Security, so I tried digging into this a bit.

Using log4j.logger.org.apache.rampart.TIME=DEBUG gives an assortment of 
times which seem to span all the Rampart handling. The interesting thing 
is that when I add up all the time results from the output, the total is 
less than half of the time actually taken for the test. Here's a summary 
for a test using signatures in both directions (with client and server 
running on the same system and single-threaded processing), by way of 
example:

-------------------------

/Total time for 100 message exchanges: 47516

Client
Inbound processHeader by WSSecurityEngine 4895, DOOM conversion 7439, 
PolicyBasedResultsValidattor 1446; total inbound 13780
Outbound Signature took 1645

Server
Inbound processHeader by WSSecurityEngine 817, DOOM conversion 83, 
PolicyBasedResultsValidattor 708; total inbound 1608
Outbound Signature took 5221

Total of all reported times: 22254
/
-------------------------

These are reasonable figures for the WS-Security processing (and 
comparable to the Metro total times), though the DOOM conversion step is 
a lot of overhead for the "convenience" of working with AXIOM. AFAIKS 
the TIME=DEBUG timing reports should  include all the actual security 
processing - so where's the rest of overhead coming from?

I'm suspecting there's more going on with AXIOM conversions and such as 
part of the inbound and outbound processing, though it's hard to imagine 
that these conversions could be taking up as much time as the actual 
signature processing. Does anyone have any ideas on this?

  - Dennis
[prev in list] [next in list] [prev in thread] [next in thread]