Performance without WS-Security Figure 1 shows the measured test times for both Axis2 and Metro without any WS-Security usage. The chart shows that there's only a small difference between the two stacks. In the test with 1,000 requests and small responses, Metro ran half a second faster than Axis2. In the test with only 100 requests but larger responses, the two stacks ran equally fast (to within .1 seconds). Figure 1. Test times without security

These timing results show that (for the data used by the test application) Metro is probably slightly faster than Axis2 in per-request processing, but in actual data conversions the two run neck-and-neck (when using the default ADB data binding with Axis2 other data bindings may give different results, and XMLBeans binding, in particular, is known to be considerably slower).

Performance with WS-Security The next two figures show the relative test times for the following security configurations: plain No security (the same values as in Figure 1, but normalized to the Axis2 time) username WS-Security plain-text UsernameToken on requests sign WS-Security signing of body and headers, with timestamp signencr WS-Security signing of body and headers, with timestamp, and encryption of body

Both Figure 2 and Figure 3 show the measured times as multiples of the Axis2 plain time, to make it easy to compare the results. Figure 2 shows the times for 1,000 requests with small responses:

Figure 3 shows the times for 100 requests with large responses: Figure 3. Large response tes

Metro is consistently much faster than Axis2 for the WS-Security configurations more than twice as fast overall, and more than three times as fast in the case of the username and sign configurations for large messages. This is a surprising result for two Web services stacks at about the same level of maturity. Metro is consistently much faster than Axis2 for the WS-Security configurations more than twice as fast overall, and more than three times as fast in the case of the username and sign configurations for large messages. This is a surprising result for two Web services stacks at about the same level of maturity. Rampart has rudimentary time logging built-in using the org.apache.rampart.TIME logger. By enabling this logger at DEBUG level, you can find out the amount of clock time required for various parts of the Rampart processing. Strangely, when I did this for the signatures example, I found that the Rampart processing times made up less than half of the total time taken for the test. This implies that the main performance problems with Axis2/Rampart WS-Security handling lie outside Rampart and the underlying WSS4J security implementation. Rampart certainly has a lot of room for improvement. As mentioned in "The high cost of (WS-)Security," Rampart does build a complete in-memory model of the message any time WSSecurity processing is involved. The overhead from building the in-memory model is the apparent cause of Axis2/Rampart's poor performance in the UsernameToken case. It's possible that the poor performance by Axis2/Rampart in other WS-Security scenarios also relates to this same type of conversion issue.

Wrapping up Metro Metro can be awkward to configure for standalone use, especially given the limited documentation available (see Resources). Metro also only works with JAXB 2.x data binding and JAX-WS 2.x Web services configuration, as opposed to the wider range of data bindings and alternative configuration supported by Axis2. But Metro offers performance equal to Axis2 for plain-text message exchanges and much better performance than Axis2 when WS-Security is involved. If you're using WS-Security and concerned about performance, you should definitely look into using Metro for your application. The next article moves on to looking at the CXF Web services stack, another Apache Foundation

project. CXF uses some of the same underlying components as Axis2 but a very different style for configuring and deploying Web services. You'll see the basics of CXF usage and how it differs from Axis2 and Metro then.