Performance gain for web service requests in Apache CXF

In this post I want to talk about a recent performance gain for JAX-WS web service requests I made in Apache CXF. It was prompted by a mail to the CXF users list. The scenario was for a JAX-WS web service where certain requests are secured using WS-SecurityPolicy, and other requests are not. The problem was that the user observed that the security interceptors were always invoked in CXF, even for the requests that had no security applied to the message, and that this resulted in a noticeable performance penalty for large requests.

The reason for the performance penalty is that CXF needs to convert the request into a Document Object Model to apply WS-Security (note there is also a streaming WS-Security implementation available, but the performance is roughly similar). CXF needs to perform this conversion as it requires access to the full Document to perform XML Signature verification, etc. on the request. So even for the insecure request, it would apply CXF's SAAJInInterceptor. Then it would iterate through the security headers of the request, find that there was none present, and skip security processing.

However when thinking about this problem, I realised that before invoking the SAAJInInterceptor, we could check to see whether a security header is actually present in the request (and whether it matches the configured "actor" if one is configured). CXF makes the message headers available in DOM form, but not the SOAP Body (unless SAAJInInterceptor is called). If no matching security header is available, then we can skip security processing, and instead just perform WS-SecurityPolicy assertion using a set of empty results.

This idea is implemented in CXF for the 3.3.2 release via the task CXF-8010. To test what happens, I added a test-case to github here. This creates a war file with a service with two operations, one that is not secured, and one that has a WS-SecurityPolicy asymmetric binding applied to the operations. Both operations contain two parameters, an integer and a String description.

To test it, I added a JMeter test-case here. It uses 10 threads to call the insecure operation 30,000 times. The description String in each request contains the URL encoded version of the WS-Security specification to test what happens with a somewhat large request.

Here are the results using CXF 3.3.1:

and here are the results using the CXF 3.3.2-SNAPSHOT code with the fix for CXF-8010 applied:

Using CXF 3.3.1 the throughput is 1604.25 requests per second, whereas with CXF 3.3.2 the throughput is 1795.26 requests per second, a gain of roughly 9%. For a more complex SOAP Body I would expect the gain to be a lot greater.