WSO2 Enterprise Service Bus (ESB) Performance Testing - Round 3

this article is the third in a set of articles that measure and compare the performance of the wso2 enterprise service bus (esb) against other leading implementations - both open source and proprietary.

two previous articles are available as wso2 esb performance testing round 1 and wso2 esb performance testing round 2

table of content

1. introduction
2. sample request messages
3. completeness of the scenario implementations and issues encountered
4. benchmark configurations and adjustments made
5. results
6. conclusions
7. resources

introduction

in this round of testing, we have compared the wso2 enterprise service bus (esb) [6] v1.7 against the leading proprietary esb (prop-s/prop-n), the proprietary version of an open source esb (prop-os), the open source alternatives - apache service mix 3.2.1 and mule community edition 2.0.1 (mule ce). the wso2 enterprise service bus (esb) is an open source project (under the apache license v2.0) developed by wso2 based on the popular apache synapse enterprise service bus (esb) [7]. since the wso2 esb v1.7 embeds the apache synapse esb v1.2 release, the performance figures between these will be identical. however, the wso2 esb ships with better management and development support with a graphical web interface, enhanced jmx support and a built-in wso2 registry instance.

although, initially we planned to include the openesb and the jboss esb in the testing rounds, due to the complexity involved in understanding these products to build the simple scenarios we needed, we decided to go without them and to include a follow up article instead. you will recall from the first and second rounds of testing, that we had three specific scenarios benchmarked designed to test the processing performance of an enterprise service bus (esb) intermediary. although these scenarios obviously aren't exhaustive, and we understand that there could be other scenarios where alternative benchmarks may show different results, these are some of the most common use-cases based on customer situations that we have encountered. the three scenarios are:

1. virtualization, where the esb hides the actual service and performs message routing

in this scenario we create a proxy service (defined by the proxywsdl) for the actual echo service (defined by the echowsdl), which simply passes on the messages to the real service. this pattern allows users to hide real services behind proxies exposed over the esb and thereby prevent direct application-to-application, application-to-service and/or service-to-service links from being created within an enterprise to bring order to a service oriented architecture (soa) deployment. this additionally allow users to perform authentication, authorization, validation, ws-security, ws-reliable messaging and ssl decryption etc at the esb layer, so that the real services within the organization could be simplified. this also allows real services available over different transports or schemas to be exposed over other transports and/or interfaces, and also allow ws-policy attachments for consistent enforcement of enterprise wide policies.

2. content-based routing (cbr), where the esb routes on data within the message

the content based routing (cbr) proxy service performs an evaluation of an xpath expression over the payload of the messages, before they are routed to the real service. for this example, we use an xml payload with a list of 'order' elements , and check if the first order element is for the symbol "ibm". if this condition is satisfied, we forward it to the actual service implementation, else return an error. typically payloads are routed on transport/soap headers and/or user defined header elements, or payload body elements.

3. transformation, where the esb transforms the request and response messages using xslt-based transformations

in this scenario, we expose a different interface at the proxy service that expects all elements in reverse order. thus a client querying the wsdl of the proxy service is presented a completely different wsdl with a different schema. the messages received from the client is in reverse order, and are then transformed as expected by the real service. the response from the real service is then transformed again (i.e. reversed) and sent back to the client. this is a typical use case when newer versions of a service are exposed, and a subset of its users now require backwards compatibility with the previous schemas etc.

sample request messages

• a sample request message used for the direct proxy and cbr proxy scenarios is given below. refer[4] for actual requests used.

<soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://services.samples/xsd">
    <soapenv:body>
        <xsd:buystocks>
            <order><symbol>ibm</symbol><buyerid>asankha</buyerid><price>140.34</price><volume>2000</volume></order>
            <order><symbol>msft</symbol><buyerid>ruwan</buyerid><price>23.56</price><volume>8030</volume></order>
            <order><symbol>sun</symbol><buyerid>indika</buyerid><price>14.56</price><volume>5000000</volume></order>
        </xsd:buystocks>
    </soapenv:body>
</soapenv:envelope>

• a sample request message used for the xslt proxy scenario is given below. refer[4] for actual requests used.

<soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://services.samples/xsd">
    <soapenv:body>
        <xsd:skcotsyub>
            <redro><lobmys>ibm</lobmys><direyub>asankha</direyub><ecirp>140.34</ecirp><emulov>2000</emulov></redro>
            <redro><lobmys>msft</lobmys><direyub>ruwan</direyub><ecirp>23.56</ecirp><emulov>8030</emulov></redro>
            <redro><lobmys>sun</lobmys><direyub>indika</direyub><ecirp>14.56</ecirp><emulov>500</emulov></redro>
        </xsd:skcotsyub>
    </soapenv:body>
</soapenv:envelope>

completeness of the scenario implementations and issues encountered

we did not encounter any issues in implementing the scenarios within the wso2 enterprise service bus (esb) or the proprietary esb. however, mule ce was not able to create any real proxy services (i.e. a service that can 'expose' a different interface from that of a real service they hide behind, and have the ability to forward those requests to the real service), without having to write a full service implementation class in java. the proprietary version of the open source esb was unable to expose the wsdl for the xslt transformation scenario due to an error. apache servicemix couldn't proxy the incoming soapaction to the real service implementation, and we found this to be a known issue with servicemix 3.2.1

figure 1 - ability to create real proxy services for the scenarios

table 1 - issues encountered with each esb

benchmark configurations and adjustments made

table 2 - tuning of each of the systems

backend service implementation

we developed a mock echoservice as a servlet which simulated a 10ms processing time, and deployed this on an apache tomcat 5.5.26 instance.we soon noticed tomcat running out of resources to support the load test, with a message "severe: all threads (150) are currently busy, waiting. increase maxthreads (150) or check the servlet status". we then increased the maxthreads and acceptcount to 600, and allocated 512m of heap memory. the mockservice war and its source code can be found at[2]

client implementation

we used the excellent apache httpcomponents projects' benchmark code , which is a good replacement for the apachebench load generator, with support for http 1.1 and ssl. this code has now been exposed as a simple to use binary javabench, and its source code/binary is available at[1]

benchmarking methodology followed

we used the shell scripts available at[3] to drive each scenario. a warm up run of each of the three scenarios were executed by the script before the actual tests for each esb began. we also re-started the apache tomcat backend before each test run. the output of the shell scripts were re-directed to a text file, and was fed through a utility to convert into a csv file, which was then used to generate the tables and graphs.

results

important: in the following tables and charts, the proprietary esb used, and the proprietary version of the open source esb are indicated with the following keys:

• "prop-s" - the proprietary esb with its additional performance improvements turned on, and started in 'production' mode
• "prop-n" - the proprietary esb without the additional performance improvements, and started in 'production' mode
• "prop-os" - the proprietary version of an open source esb

1. direct proxy service - virtualization

observations:

1. mule ce 2.0.1 and the proprietary version of the open source esb crashed with a concurrency level over 80 (also see [5])
2. mule ce 2.0.1 consistently failed on ~1% of the requests for each and every scenario tested, even for the low concurrency tests.
3. apache servicemix 3.2.1 failed to forward the incoming soapaction to the real service
4. the proprietary esb demonstrated a clear leadership over all scenarios, with or without additional performance improvements turned on
5. the proprietary esb performed 1.6~1.9 times tps on average (with and without additional performance improvements) than the wso2 esb
6. wso2 enterprise service bus (esb) v1.7 with its default configuration beat all other open source alternatives consistently
7. the wso2 esb average tps was over 4 times than that of mule ce and the proprietary version of the open source esb, and over twice that of apache servicemix

2. content based routing

observations:

1. mule ce 2.0.1 and the proprietary version of the open source esb crashed with a concurrency level over 80 (also see [5])
2. mule ce 2.0.1 consistently failed on ~1% of requests for each and every scenario tested, even for the low concurrency tests.
3. apache servicemix 3.2.1 failed to forward the incoming soapaction to the real service
4. the wso2 esb performed better than the proprietary esb (even with its additional performance improvements turned on) for 1/2k and 1k messages.
5. for 5k messages, the proprietary esb did slightly better than the wso2 esb.
6. wso2 enterprise service bus (esb) v1.7 with its default configuration beat all other open source alternatives consistently
7. the wso2 esb average tps was roughly over 3 times than that of mule ce, the proprietary version of the open source esb, and apache servicemix

3. xslt transformations

notes:

• we turned on the default apache xalan translet transformation flag with the wso2 esb and this result is shown as "wso2-*"
• the proprietary esb did not have any additional performance optimizations for this scenario, where the message was being transformed during proxying

observations:

1. mule ce 2.0.1 and the proprietary version of the open source esb crashed with a concurrency level over 80 (also see [5])
2. mule ce 2.0.1 consistently failed on ~1% of requests for each and every scenario tested, even for the low concurrency tests.
3. apache servicemix 3.2.1 failed to forward the incoming soapaction to the real service
4. the wso2 esb performed better than the proprietary esb for 1/2k messages with xalan translet compilation enabled, but was beaten by it for the 1k and 5k messages.
5. wso2 enterprise service bus (esb) v1.7 with xalan translet compilation enabled, beat mule ce and the proprietary version of the open source esb for all scenarios.
6. apache servicemix beats wso2 esb for xslt transformation of 5k messages
7. considering the average tps, the wso2 esb with the xalan translet compilation enabled, performed better than all esb's with a close tie from the proprietary esb, but with a clear lead against the open source options.

conclusions

• wso2 enterprise service bus (esb) displays excellent stability and performance on all scenarios
• wso2 esb v1.7 leads in performance over all other open source alternatives, as well as the proprietary version of the open source esb benchmarked
• the performance of the proprietary esb has improved drastically over the past year, as compared to numbers it gained during the rounds 1[8] and 2[9]

notes

• all performance numbers were captured while running a single instance of each esb, on a single jvm.
• all software (javabench, tomcat, wso2 esb, mule ce, the proprietary version of the open source esb and servicemix) were run on the sun jdk 1.5.0_15 on red hat enterprise linux server release 5 (tikanga)
• the proprietary esb was run on its own jvm on the same red hat enterprise linux server release 5 (tikanga) server
• hardware configuration
• client / load generator - intel(r) xeon(tm) 3.20ghz 2mb cache dual core - 2 cpu system / 2gb ram / 1g nw
• enterprise service bus - intel(r) xeon(tm) 3.20ghz 2mb cache dual core - 2 cpu system / 2gb ram / 1g nw
• backend service simulator - intel(r) xeon(r) 2.00ghz dual core - 2 cpu system / 2 gb ram / 1g nw
• all three systems were tuned at the operating system level as follows:

/etc/sysctl.conf 
net.ipv4.ip_local_port_range = 1024 65535 
net.ipv4.tcp_fin_timeout = 30 
fs.file-max = 2097152 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_tw_reuse = 1 

/etc/security/limits.conf 
* soft nofile 4096 
* hard nofile 65535

resources

[1] javabench - a java clone of the popular apache bench load generator, implemented by apache httpcomponents project

source available at https://wso2.org/repos/wso2/trunk/commons/performance/esb/tools/client , with build instructions and a maven project file

a complimentary binary build is available here: java-bench-0.1.zip

[2] mockservices - a high performance echo servlet that acts as a service simulator.

source available at https://wso2.org/repos/wso2/trunk/commons/performance/esb/tools/mockservice/mock-services with build instructions and a maven project file

a complimentary binary build is available here: mockservices.war

[3] resources used for the load testing, including xslt transformations, wsdl's, and shell scripts etc. available at https://wso2.org/repos/wso2/trunk/commons/performance/esb/round_3/resources

[4] sample client requests of 0.5k, 1k and 5k can be found at https://wso2.org/repos/wso2/trunk/commons/performance/esb/tools/client/requests

[5] mule ce 2.0.1 encountered the following exception when the number of concurrent users exceeded the maximum thread count configured

error 2008-06-20 16:42:05,283 [httpconnector.receiver.1] org.mule.providers.http.httpconnector: work caused exception on 'workcompleted'. 
   work being executed was: httpmessagereceiver{this=160c4b0, receiverkey=http://testb.wso2.com:8090/services/cbrproxy, endpoint=http://testb.wso2.com:8090/services/cbrproxy}


error 2008-06-20 16:42:05,285 [httpconnector.receiver.1] org.mule.impl.defaultexceptionstrategy: caught exception in exception strategy: null
edu.emory.mathcs.backport.java.util.concurrent.rejectedexecutionexception
        at org.mule.util.concurrent.waitpolicy.rejectedexecution(waitpolicy.java:56)
        at edu.emory.mathcs.backport.java.util.concurrent.threadpoolexecutor.reject(threadpoolexecutor.java:765)
        at edu.emory.mathcs.backport.java.util.concurrent.threadpoolexecutor.execute(threadpoolexecutor.java:1288)
        at org.mule.impl.work.scheduleworkexecutor.doexecute(scheduleworkexecutor.java:39)
        at org.mule.impl.work.muleworkmanager.executework(muleworkmanager.java:276)
        at org.mule.impl.work.muleworkmanager.schedulework(muleworkmanager.java:243)
        at org.mule.providers.tcp.tcpmessagereceiver.run(tcpmessagereceiver.java:177)
        at org.mule.impl.work.workercontext.run(workercontext.java:310)
        at edu.emory.mathcs.backport.java.util.concurrent.threadpoolexecutor.runworker(threadpoolexecutor.java:1061)
        at edu.emory.mathcs.backport.java.util.concurrent.threadpoolexecutor$worker.run(threadpoolexecutor.java:575)
        at java.lang.thread.run(thread.java:595)

[6] wso2 enterprise service bus (esb) - http://wso2.org/esb

[7] apache synapse enterprise service bus (esb) - http://synapse.apache.org

[8] performance testing round 1 = http://wso2.org/library/1721

[9] performance testing round 2 = http://wso2.org/library/2259

author

asankha perera, wso2 inc.

project management commitee member and comitter of apache synapse enterprise service bus (esb), apache web services and apache httpcomponents projects

architect and product manager of the wso2 enterprise service bus (esb)

asankha at wso2 dot com

http://esbmagic.blogspot.com