View
3.792
Download
4
Category
Preview:
DESCRIPTION
Citation preview
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
Recommended