Opposite to men that with the years we get slower (at least that’s my case), the new version of Mule 3 showed an improvement in performance compared to previous Mule ESB versions. In general plenty of effort was put to profile and optimize Mule for high concurrency scenarios, which led to improve the way messages were handled in transports and transformers.
Mule 3.1 performance is in average 10% better than its predecessor version 2.2.7, performing better when the number of concurrent consumers gets bigger and much better when dealing with XSLT transformations (around 15% better).
- Two dual-processor 2.66GHz Intel i7 computers running Java 1.6 on Mac OS X 10.6.5. The request generator JavaBench was installed on the first computer. Mule 2.2.7 and Mule 3.1 were installed along with the Echo service on the second computer.
- A warmup period was considered before each test, so that all the components involved in the test were fully initialized (thread pools, caches, etc.)
- All tests were at least 15 seconds long to give an accurate view into system performance.
- Direct Proxy: This case creates a proxy service that passes messages directly to the Echo service. This case tests the ability for an ESB to efficiently proxy HTTP requests.
- Content Based Routing: This case evaluates XPath expressions in the message payload before routing them to the service component.
- XSLT: This case tests an ESB’s ability to transform request and response messages using XSLT-based transformations. With a proper configuration, Mule is able to stream XML transformations directly from a request to the response, yielding very high performance.
The previous test cases were ran with 20, 40, 80 & 160 concurrent client threads and for each case different size input messages were used (500 bytes, 1 kb, 5 kb and 10kb). As can be shown in the figures below, Mule 3 was in average 7% faster for Direct Proxy, 4% for Content Based Routing Proxy and 15% for XSLT Proxy.
You can download the Mule 3.1.1 compliant application used for these tests here.