Run Mule… run faster


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).

The test cases and setup were similar as the ones used some time ago to benchmark Mule 2.0.2. For more details on these benchmarks please refer to Whitepaper Perf Test Results.


  • 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.

Perf Test Setup

Test Cases

  • 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.

Figure 1. Test Results - Direct Proxy

Figure 1. Test Results - Direct Proxy

Figure 2. Test Results - Content Based Routing Proxy

Figure 2. Test Results - Content Based Routing Proxy

Figure 3. Test Results - XSLT Proxy

Figure 3. Test Results - XSLT Proxy

You can download the Mule 3.1.1 compliant application used for these tests here.

We'd love to hear your opinion on this post

3 Responses to “Run Mule… run faster”

  1. I was trying to replicate this, but I guess the configurations have changed from 2.0.2 to 3.1?

    Would be very helpful if you could update the older resources at with the new ones used.

    Also, how do you ensure that each test runs for at least 15 seconds?

    • Linda you are right, I will be updating the post soon adding the configuration for Mule ESB 3.1. In order to ensure that tests run for at least 15 seconds, I just performed previous tests in order to adjust the values for the amount of threads and loops of the load application client.

  2. Hi,
    I want to do the same process for testing scenarios for the newer version of Mule but I don’t know how to implement the test cases with same data, Could you help me with this?
    This is my email :
    It would be nice to contact me for further help on this case.