Dushan Abeyruwan Senior Software Engineer Integration Technology Team Member - Integration MC WSO2 Inc. March 2013

How the WSO2 ESB outperforms other Major Open Source ESB vendors

Kasun Indrasiri Associate Tech Lead Integration Technology Team Member - Integration MC WSO2 Inc. March 2013

About WSO2

• Providing the only complete open source componentized cloud platform

– Dedicated to removing all the stumbling blocks to enterprise agility

– Enabling you to focus on business logic and business value

• Recognized by leading analyst firms as visionaries and leaders

– Gartner cites WSO2 as visionaries in all 3 categories of application

infrastructure

– Forrester places WSO2 in top 2 for API Management • Global corporation with offices in USA, UK & Sri Lanka

– 200+ employees and growing

• Business model of selling comprehensive support & maintenance for our products

Outline for the today's webinar

• Background - SOA & ESB

• What is Pass Through Transport (PPT) and the main differences

between PTT and NHTTP.

• How PTT was enhanced to work as the default Transport layer.

• High performance Stream Xpath.

• FAST XSLT – High Performance Message Transformations .

• ESB Performance round 6.5 – observations and test results .

• Conclusion.

Background

• Service Oriented Architecture (SOA) – A style of software architecture that is modular, distributed and

loosely coupled. – Componentization – The main driver of SOA – Business Functionalities are implemented in different Business

Components – Business Components provide their functionality to its consumers

as a ‘Service’ with the well-defined service interfaces.

Background

• Enterprise Service Bus (ESB) – An ESB is a middleware solution that enables interoperability

among heterogeneous environments using a service-oriented model.

– Stateless and Seamless Integration – Standard Protocols – SOAP, REST, JSON etc. – Transports – HTTP/S, JMS, TCP, VFS etc.

Source : http://graegert.com/programming/no-soa-criticism-somewhere

WSO2 ESB is…

• A lightweight, high performance ESB • Feature rich and standards compliant

– SOAP and WS-* standards – REST support – Domain specific protocol support (eg: FIX, HL7)

• User friendly and highly extensible • 100% free and open source with commercial

support

Under the Hood: Apache Synapse

• A lightweight, open source ESB implementation from the

ASF : http://synapse.apache.org

• Makes up the mediation engine of WSO2 ESB

• Multithreaded and asynchronous message processing core

• Based on a number of well known open source projects (eg:

Axis2, Http Core)

Under the Hood: WSO2 Carbon

• An OSGi based components framework for SOA

• Extensive modularity and reusability

• Easily add, remove and customize features

– Similar to Eclipse plug-ins

• Easily deploy third party libraries and custom code

into the server runtime

• Web based management console

WSO2 Carbon

WSO2 Carbon

Why ESB Performance Matters?

• Most organizations are adopting SOA as the enterprise architecture and ESB is essential in order to realization of SOA.

• Similar or disparate systems are connected via an ESB • All communication and message passing occurs via ESB. • Diverse message transformations, message filtering and protocol

switching occurs inside the ESB

High Level Architecture (NHTTP )

Axis2 In Runtime

Transport

Transport Sender

• Sends the message to given endpoint address/output stream

Transport Receiver

• Receives the transport specific message. • Builds the message context. • Invokes the AxisEngine.

Limitations with Default NHTTP

• The default transport was very generic and it was designed to offer reasonable performance in all the integration scenarios the ESB could potentially participate in.

• However HTTP load balancing, HTTP URL routing (URL rewriting) and HTTP header-based routing are some of the most widely used integration patterns in the industry and to support these use cases well, we needed a specialized transport.

NHTTP Inside Story

Axis2 NHTTP Receiver

InputStream

I/O Buffer1

OS Buffer

Message builder

NHTTP Sender

OutputStream

I/O Buffer2

OS Buffer

Message Formatter

NHTTP Inside Story Cont.

• The old NHTTP transport was based on a dual buffer model.

• Incoming message content was placed in a SharedInputBuffer.

• Outgoing message content was placed in a SharedOutputBuffer.

• Apache Axiom, Apache Axis2 and the Synapse mediation engine sit Between the two buffers, reading from the input buffer and writing to the output buffer. • This architecture is illustrated in the following diagram.

NHTTP Inside Story Cont.

NHTTP – The Limitation…

• The main downside is every message happens to go through the Axiom layer, which is not really necessary in cases like HTTP load balancing and HTTP header-based routing.

• Also the overhead of moving data from one buffer to another was not always justifiable in this model.

Why do we need a Specialized transport ?

To achieve followings • Ultra-fast, low latency mediation of HTTP requests. • Supporting a very large number of inbound (client-ESB) and outbound

(ESB-server) connections concurrently (we were looking at several thousand concurrent connections).

• Automatic throttling and graceful performance degradation in the

presence of slow or faulty clients and servers.

History behind Passthrough transport (PT Transport)

• The HTTP pass-through transport was first released in June 2011 along with WSO2 ESB 4.0.

• Back then it was disabled by default and the user had to enable it by un-commenting a few entries in the axis2.xml file.

• The performance numbers we were seeing with the new transport were simply remarkable.

• WSO2 also published some of these benchmarking results in a March 2012 article. [1]

[1] http://wso2.org/library/articles/2012/03/wso2-esb-message-transfer-mechanisms-

comparative-benchmarks

Why Passthrough so special?

Why passthrough transport so special Cont.

• PTT can utilize a single shared buffer. • In similar circumstances, the NHTTP transport utilizes two buffers.

This improvement is particularly useful for the performance of pass-through mediation.

Limitations with PT prior to ESB 4.6.0 releases

• Configuration overhead (Users had to explicitly enable the transport depending on their target use cases)

• Cannot support any integration scenario that requires HTTP content manipulation (because Axiom was bypassed, any mediator attempting to access the message payload would not get anything useful to work with)

• Instance maintaining two separate HTTP transports was twice as work for the developers and testers.

Improvements in Passthrough Transport

• Content-unaware mediators – Mediators that never access the message content in anyway (eg: drop mediator)

• Content-aware mediators – Mediators that always access the message content (eg: xslt mediator)

Improvements in Passthrough Transport

<proxy xmlns="http://ws.apache.org/ns/synapse" name="CBRProxy" transports="https http" startOnLoad="true" trace="disable"> <description/> <target> <inSequence> <filter xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ source="//order[1]/symbol“ regex="IBM"> <then> </inSequence> <outSequence> <target> <filter xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ source=“$trp:symbolHeader“ regex="IBM"> </target> <outSequence> </proxy>

In Sequence contnetaware =true , since it refers the content of the message in XPath

outSequence contnetaware =false, since the inbound response the synapse language written only to evaluate based on transport headers.

Outbound

Inbound

Streaming XPath

XPath is a special component in ESB Since most of the messages going through the SOA environment are

SOAP messages.

To manipulate these SOAP messages, we use XPath expressions.

Uses XPath engines like Jaxen or AXIOM Xpath.

PROBLEMS • Navigation through each and every node consumes time and memory

• So the larger the XML file, the more parsing performance is reduced

Streaming XPath

The XPath parsing happens on top of the AXIOM data model created

by an input stream to the XML document.

Returns the first match of the XPath expression.

Complex XPath expressions that have predicates, logical combinations of results, etc. are not eligible for Streaming XPath

Streaming Xpath – How it works

AXIOM data model for the XML document will be passed to the first

component -> choose the first element that has the local name “data” Send the selected element to the next component. (And process

continues. When a XPath is given it creates a component chain. Input XML stream is pass through the component chain and result is

obtain at the last component.

Streaming Xpath – How it works

Streaming XPath parser supports simple absolute and relative XPath

expressions that don't have logical combinations, functions, predicates etc.

When an XPath is given, the Streaming XPath parser will analyze that expression to mandate whether it belongs to the supported set of expressions. -> If so, it creates the component chain for the given Xpath

Why Antlr? For matching the given XPath and component chain creating

process we used ‘Antlr’ language-analyzing tool. Using Antlr we can check whether a given string matches a

particular syntax, or set of rules, which is provided in a grammar file. (XPath1.g)

Grammar file is used to identify the XPath expressions that can be processed with Streaming XPath.

Unsupported XPath expressions will be processed with traditional XPath processing

FAST XSLT

An improved XSLT mediator which provides much faster streaming

transformation when used with the PTT. Almost doubled the XSLT performance.

ESB Performance Round 6.5

• Conducted performance study to compare the performance of WSO2 ESB 4.6.0, WSO2 ESB 4.5.1, Mule 3.3.0, Talend-SE-5.1.1, and UltraESB 1.7.1 - Enhanced.

• We have chosen to called this test “Round 6.5” because we are comparing against the same versions and results of the ESBs used in the Round 6 performance benchmark published on the UltraESB-managed performance site esbperformance.org.

ESB Performance Round 6.5

• All the load tests were carried out using Amazon AWS EC2 with the instance type "High-CPU Extra Large (c1.xlarge, 7GB).” The configuration used is described below. The back-end echo service used for testing was hosted in fully optimized Apache Tomcat 7.0.29.

• Testing Scenarios • DirectProxy • CBRProxy • CBRSOAPHeaderProxy • XSLTProxy • XSLT Enhanced Proxy (Using FAST XSLT mediator written to

handle with passthrough transport) SecureProxy

Observations

• Number of messages per client n=1000 up to 320 concurrency and n=10 for higher concurrency (1280/2560)

Observations

• Number of messages per client n=1000 up to 320 concurrency and n=10 for higher concurrency (1280/2560)

Observations

• Number of messages per client n=1000 up to 320 concurrency and n=200 for higher concurrency (1280/2560)

Observations

• Number of messages per client n=1000 up to 320 concurrency and n=200 for higher concurrency (1280/2560)

ESB is not just about performances

• Enterprise Ready – WSO2 Customer Case Studies • Part of a complete middleware platform – WSO2 Middleware Platform • PaaS - ESB in the Cloud • 100% Open Source

Conclusion

• Why ESB Performance • NHTTP and PTT • Performance Test Round 6.5 • Observations

Time for questions

150+ globally positioned support customers

Engage with WSO2

• Helping you get the most out of your deployments

• From project evaluation and inception to development

and going into production, WSO2 is your partner in

ensuring 100% project success