Arch2Arch Tab BEA.com
Syndicate this blog (XML)

AquaLogic Service Bus 3.0: Setting the New Benchmark for Enteprise-class ESB Performance

Bookmark Blog Post

del.icio.us del.icio.us
Digg Digg
DZone DZone
Furl Furl
Reddit Reddit

Dain Hansen's Blog | March 17, 2008   3:15 PM | Comments (0)


AquaLogic Service Bus once again proves that it is the enterprise-class leader in ESB technology with its refined foundational capabilities in 3.0. These include:

 

  • Performance improvements
  • Optimized parallelism
  • Partial parsing of headers
  • Large message streaming

 

Together these new techniques provide AquaLogic Service Bus customers ways of lowering their ESB hardware requirements, at the same time future-proofing their implementations for the large enterprise-wide deployments.

 

Performance Improvements

 

In our standard routing of HTTP/SOAP messages benchmark, AquaLogic Service Bus easily beats the 500 million messages a day benchmark. The benchmark is run for 2-CPU dual core (2 GHz) Intel Xeon server running Red Hat Linux; average message sizes are 5K. For even smaller messages, we see over 700 million messages a day or roughly 9,000 messages a second.

 

This is approximately 12% faster than AquaLogic Service Bus 2.6 with some additional noteworthy improvements below which give an additional bump for cases that involve parallelism, partial parsing, or large message processing.

 

Incidentally this is also beats the numbers from this performance study on WS02 and Service Mix with a significant advantage.

 

Parallelism

 

  • Benchmark involves AquaLogic Service Bus invoking 3 Business Services in parallel (each with 20ms latency).
  • The baseline is calling the 3 Services sequentially in AquaLogic Service Bus

 

Using the new Parallel action, we see a 62% reduction in response time. This is ideal for cases where processing of messages requires steps with latency and optimizations of parallelism can be implemented.

 

Partial Parsing Optimizations for Content Based Routing

 

Improved content based routing is enabled through partial parsing of the SOAP header. This is enabled by using StAX extract the SOAP header. This is an advanced technique of parsing large XML documents which doesn’t require a large memory footprint. Using this technique shaves over 3 times the performance for processing larger XML messages. SOAP header based routing is just one place where we gain from using partial parsing.

 

We also gain from partial parsing in the following scenarios:

 

  • SOAP Header based routing (irrespective of whether we enable streaming) or any SOAP header processing (e.g. adding a new header)
  • Routing based on any part of the payload (not just SOAP header) when streaming is enabled. This is a big plus for content based routing of larger payloads. This is assuming the payload is not transformed as that requires the entire payload to be parsed. 

 

 Streaming Mode

 

This new feature in AquaLogic Service Bus allows messages to be kept in a serialized format instead of a parsed XmlBean format for optimized large file handling. With this new feature, paging support is included which allows for the serialized message buffer to be persisted either in-memory or to the disk. The message is buffered in order to allow retries. Streaming allows for significantly larger messages (>500MB) to be transformed easily and ultimately, this helps the ESB scale by reducing the memory pressure. Reducing the memory pressure means less Garbage Collection and that may lead to performance improvements.

 

Feel free to take your own test drive of the ESB, check out: AquaLogic Service Bus 3.0.

 

 

References

 

Also look at other tests of other open source ESBs here:

 

 

 

 

 

 

 

 


Comments

Comments are listed in date ascending order (oldest first) | Post Comment



Only logged in users may post comments. Login Here.

Powered by
Movable Type 3.31