Java Web Service: CXF Performance Comparison

Introduction: Apache CXF shares some of the underlying components with Apache Axis2 and Metro, but combines them in a completely different architecture. Dennis Sosnoski will continue his Java Web services column to compare the performance of the CXF, Metro, and Axis2 stacks in the absence of ws-security.

The Apache CXF Web Services Stack is based on the same technologies as the Apache Axis2 and Metro Stacks discussed in earlier articles in this series. Similar to AXIS2, it is implemented using Apache wss4j ws-security. Like Metro, it uses the JAX-WS 2.x Web service configuration and JAXB 2.x data binding (even with the same JAXB implementations as Metro, but the two stacks are different versions). However, in addition to these common components, the differences between the stacks also include their processing engine and ws-securitypolicy configuration processing.

Earlier articles in this series compared the performance of Axis2 with Metro, including simple message exchange under different ws-security configurations. In this article, you will learn about performance comparisons between CXF and Axis2 and Metro's latest releases.

Performance overview

Similar to the previous articles on WEB services performance-"ws-security" and "compare Metro to Axis2 performance"-This article will measure the time it takes to execute a specific request sequence when the client and server are running on a single system. This approach compares the WEB service processing overhead multiple times because it eliminates the overhead of network latency and timing. Assuming that the client code is not significantly slower than the server, the data can represent the performance of the actual server under high load.

This article will also use the same test application as the earlier article, a seismic data retrieval service. The database used by the service contains data from over 93,000 earthquakes that have occurred over the years in the global context. The service request will specify a time range and a coordinate range, and the service will return all earthquakes within the range. See the "ws-security overhead" for complete information on test applications and sample request/Response message pairs.

As in previous articles, we will use two sets of request sequences for performance testing. The first group uses 1,000 requests and adjusts the query parameters to match a small portion of the data in the entire seismic database (only 816 matching seismic entries are returned in 1,000 requests). The second group uses 100 requests and adjusts it to match larger portions of the database (176,745 matching seismic entries are returned in 100 requests). These two request sequences emphasize the different performance characteristics of the WEB service stack. The first sequence shows the speed at which the stack uses a small amount of data to process requests, while the second sequence emphasizes the speed at which data is processed. Each request sequence is run several times with a different security configuration, and the results only record the best performance data for each configuration.

The hardware and software conditions for running tests are: Mandriva 2009.1 64-bit Linux systems, Athlon X2 5400+ processors and 4GB of memory, using the Sun (Oracle) Java 1.6.0_18 32-bit JVM (for specific heap size In small terms, it has a slightly better performance than 64 bits. Server code runs on Tomcat 6.0.20, configured to use a 1024MB-size heap, while client code uses a 512MB-sized heap. The WEB service stack version is as follows:

CXF 2.1.7

Metro 2.0

Axis2 1.5.1, and Rampart 1.5 release

If you want to try to test on your own machine and JVM, download the code (http://www.ibm.com/developerworks/cn/java/j-jws14/index.html#download).