AquaLogic Service Bus: Leading the Race in Performance
Dain Hansen's Blog |
November 7, 2006 6:51 AM
|
Comments (4)
BEA is no amateur in the race to make its systems best-in-class for performance and scalability. Recently BEA announced the Winning SpecjAppServer Benchmark where BEA WebLogic Server proves that it requires fewer CPUs than any other application server. AquaLogic Service Bus 2.5 also leverages this strong BEA performance heritage for its Enterprise Service Bus (ESB) capabilities. The AquaLogic Service Bus was purpose-built for enabling high volume, high performance service mediation: including service brokering, routing, transformation, security, and monitoring; without adding considerable latency to the entire end-to-end solution.
One of the challenges in implementing SOA has been proving that you actually can de-couple your systems without paying such a heavy price in performance. We have seen this question asked by several folks, including John Reynolds on his blog on Is an ESB Appropriate for Volume-performance Applications. I would answer: Yes, absolutely! By minimizing the latency of an ESB system, we can see the benefits that service mediation and de-coupling provides.We need to architect this from the get-go into the ESB, and that is something that AquaLogic Service Bus provides.
Now let’s run the numbers. In BEA labs, AquaLogic Service Bus can easily process over 200 million messages a day on a typical 4 CPU platform using a rigorous end-to-end benchmark. These numbers reflect typical routing rules for processing 5K messages on either JMS or HTTP transports. We have measured even higher numbers for smaller messages: around 300 million messages a day on a single core 2 CPU box. This is just the beginning for our performance capability, we support the capability for linear scalability in our AquaLogic Service Bus: adding a second server to a single server, doubles the capacity of the system.
Unfortunately there isn’t a good standard in the industry for ESB performance. Undoubtedly we need something like a standardized SpecESB benchmark from SPEC for a true apples-to-apples comparison. However, I have seen AquaLogic Service Bus significantly stronger than other numbers in our customer engagements, especially the open source ESBs. Unfortunately nothing is formalized as a public benchmark so it is difficult to qualify this with numbers. For instance, regarding Service Mix – 15 million messages per day – (In a response posted to my blog on Is JBI Dead?).
AquaLogic Service Bus provides the performance as well as the reliability. It also provides capability for failover as well as guaranteed transactions for once-and-only once reliable messaging. The AquaLogic Service Bus provides these capabilities as well as security: transport security, message level security, and identity propagation. The performance is a key aspect in each part of the architecture, including also the built-in monitoring and management. The AquaLogic Service Bus has the capability to monitor the service without jeapordizing the performance of the service itself.
In my experience, the AquaLogic Service Bus is leading the race in performance for ESBs, we have a strong foundation at BEA, and we certainly will keep building upon these strengths. This in turn enables our customers to leverage fundamental aspects of SOA, like de-coupling the service consumers from the service providers using service mediation, without worrying about the overhead.
Other interesting related articles:
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Ross,
That is fair. I removed the Mule performance figures, feel free to update me with a link when you have the more official numbers. We'll be waiting. Perhaps we should work together on a Spec4ESB project?
Cheers, Dain
Posted by: dainsworld on November 14, 2006 at 5:53 AM
-
Dain, its very misleading to quote your benchmark figures in a comparison with figures for Mule that were quoted originally by a user without any context and certainly are not benchmark figures. We are working on publishing some figures by the end of the year, but in the meantime maybe you should edit your posting.
Cheers,
Ross
Posted by: rossmason on November 10, 2006 at 7:37 AM
-
Ross,
I didn't run the benchmark. This was posted by Rob Thorton on October 3rd, 2006 on infoq, which I linked from the blog, please take a look at: http://www.infoq.com/news/mule-13. Feel free to write to them about the numbers and I can can always correct it. Is there another public posting I can use for the numbers for Mule?
Cheers, Dain
Posted by: dainsworld on November 7, 2006 at 10:49 PM
-
Dain,
Mule is typically used in high volume environments, 3 of our Fortune 50 and many other customers fall into this high volume category and are happily running in production with cycles to spare.
I have no idea how you arrived at the measly 1 million messages mark but I can assure you that you did something wrong. Why don't you share benchmark code so that people who know what they're doing with the technology can provide real figures?
Cheers,
Ross Mason
Posted by: rossmason on November 7, 2006 at 10:18 AM
|
