CXF Performance on Sun Solaris Platform: some numbers

Introduction

I would like to show some performance benchmarks for Apache CXF on SPARC/Solaris 11 Platform. CXF was deployed in OSGi Karaf container and uses Jetty as Web Server.
JMS communication was done using Apache ActiveMQ broker, database access was based on EclipseLink JPA with Apache Aries managed transactions and Oracle DB server.

Acknowledgments

A lot of thanks for colleges Marian Kueffner for composing and integration of benchmark results and Christian Schneider for supporting me with the tests.

Benchmark Goals

• Measure maximum CXF service invocation throughput on a particular hardware configuration: SPARC/Solaris 11
•  Identify bottlenecks, areas of tuning and enhancements

Source Code
Source code is available on GitHub: cxf.benchmarks
 

Hardware

SPARC / Solaris 11 SUN-T4-2-FAMILY-0 30351017 SPARC T4-2 512GB – 8 GbE Ports – 4 FC Ports – 4 10GbE *604532* Ports

• 2x SPARC T4 8-Core 2,85 Ghz. processor

• 512GB RAM (32x 16GB DDR3 DIMM MODULES)

• 6x 600GB SAS2 10k HDD

• 2x Qlogic FC 8Gbps HBA PCIe

• 2x 10 GbE SFP+ HBA PCIe

• 1x 1 GbE Quad Gigabit Ethernet HBA PCIe

Software

Deployment: Karaf OSGi (Equinox based) container

Versions:

• Java: 6 (build 1.6.0_26-b3)
• CXF: 2.6.0
• Karaf: 2.2.6
• Jetty: 7.5.4
• Aries: 0.3.1
• ActiveMQ: 5.6.0
• EclipseLink: 2.3.0

Scenarios

Benchmarks were measured  for three main scenario:

• (A) JAX-WS based Web Services (SOAP over http)
• (B) Messaging over JMS/ActiveMQ (SOAP over JMS)
• (C) Database access via Service (EclipseLink, container managed transaction, Oracle)

 Every scenario was executed with messages of three sizes: small (1 KB), medium (10 KB) and large (1 MB). Service implementation simply redirects request to response and in scenario (C) additionally fulfills DB access operations. The focus of benchmarks was DOM-based message model, but for some scenarios service was tested also using stream oriented message processing. Throughput on the service side and CPU load are measured.

Benchmark results

Scenario A: small messages with DOM model; HTTP

Scenario A: small messages with stream model; HTTP

 

Scenario A: medium messages with DOM model; HTTP

 

Scenario A: large messages with DOM model; HTTP

 

Special Scenario: maximal service load

In this scenario service was loaded using 4 clients: three SoapUI and one CXF. Clients were activated sequentially with 1 minute interval. You can see how service load changing when the next client becomes active.

 

 

  Scenario B: small messages with DOM model; JMS

 

Scenario B: medium messages with DOM model; JMS

 

Scenario B: large messages with DOM model; JMS

 

Scenario C: Inserts in Oracle DB using EclipseLink JPA and Aries transactions

 

Scenario C: Selects from Oracle DB using EclipseLink JPA and Aries transactions

 

Conclusion

Generally CXF shows high performance in described scenarios on Sun Solaris Platform.

I have some remarks regarding the benchmark results:

1. Single thread shows pretty low performance, but system is highly scalable. Perhaps Solaris should be additionally tuned for single thread.
2. Service (provider) is very scalable. As you can see in the Test Case 5, adding more consumers just increases the service throughput. I reach more than 10K messages per second, but it still was not the top.
3. JMS scenario with ActiveMQ shows relative low performance with default configuration. The numbers are much higher if persistence is deactivated or at least immediate synchronization is switched off.
4. Stream oriented message processing increases throughput on 25-30% even for small messages.