New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
JBoss Benchmark Claims HornetQ is the Performance Leader of Enterprise Messaging Systems
Posted by Dionysios G. Synodinos on Sep 05, 2010
JBoss has published the results of messaging throughput benchmarks against the leading enterprise messaging servers on the market that implement the Java Message Service (JMS) API. In these results HornetQ demonstrates superior performance compared to the other products.
The benchmarks cover some common messaging use cases, including both lightweight publish/subscribe messaging and persistent point-to-point messaging. Default configuration for each system was used unless the vendor specifically recommended particular tunings for performance in their documentation, or the vendor's default configuration settings did not provide JMS specification compliance.
Since the license of some proprietary messaging systems prohibits from attributing benchmark results to them, the results for those systems were published anonymously. Since there are several proprietary systems in the results it is not possible to infer which results belong to which of the proprietary systems. The following versions of the non-anonymised messaging systems were used in the measurements.
- HornetQ 2.1.1 final
- ActiveMQ 5.3.2 GA
- SwiftMQ 7.6
- OpenMQ 4.4
The benchmark results [PDF] showed that HornetQ had better performance than the other solutions, in a variety of scenarios:
For lightweight publish / subscribe messaging with 12 byte messages, there was a very wide range of results with HornetQ as the clear leader. For publish/subscribe messaging with larger 1 kiB messages, several systems appeared to saturate the 1 Gib/s network becoming I/O bound and gave similar results around the 100k messages/sec mark. Other systems could not saturate the network. It would be interesting to see how much higher results would go with a faster 10 Gib/s network. For persistent messaging, there was also a wide range of results again with HornetQ as the performance leader.
It is worth noting that earlier this year, HornetQ had proven faster than ActiveMQ in peer reviewed benchmark, mainly because of its choice to implement a highly tuned journal that uses AIO when running on Linux.
You can find more information on Messaging and HornetQ, right here on InfoQ!
Dionysios G. Synodinos is a Web Engineer and a freelance consultant, focusing on Web technologies
Who measures the resilience figures
by
Eirik Maus
Posted
Re: Who measures the resilience figures
by
Martijn Verburg
Posted
RabbitMQ?
by
Ilya Sterin
Posted
Re: RabbitMQ?
by
Simon Knott
Posted
Re: RabbitMQ?
by
Tim Fox
Posted
Re: RabbitMQ?
by
Andrey Paramonov
Posted
Stability
by
Robert Roland
Posted
Re: Stability
by
Tim Fox
Posted
-
.... like
- mean time between duplicated messages when the router bugs hit you
- max time to detect and repair a missing message
- behavior with out-of-disk-space situations
- rollback speed when the messaging transaction is coordinated with the database transaction governing the business data updates. -
I totally agree, we run a heavily transaction messaging system and the performance of rollback retries and other such overheads are very important to us.
-
Seems like they forgot to mention RabbitMQ, being that it has as much attention and market penetration as it does, it makes be believe that this was done purposefully.
So guys, what happened to RabbitMQ comparison? -
Maybe they didn't include RabbitMQ because the benchmark was comparing products which implement the JMS specification.
-
Maybe they didn't include RabbitMQ because the benchmark was comparing products which implement the JMS specification.
That is correct. It's explained in the introduction in the report. It's difficult to do a fair comparison unless all the systems implement the same interface. -
We were using HornetQ via Spring and Spring Integration with little success. When it worked, it was *fast*, however, it was far from stable.
In the long run, we chose to use ActiveMQ 5.3. We were willing to take a small performance hit for a queue that's stable. -
We were using HornetQ via Spring and Spring Integration with little success. When it worked, it was *fast*, however, it was far from stable.
In the long run, we chose to use ActiveMQ 5.3. We were willing to take a small performance hit for a queue that's stable.
That's unfortunate. More often than not the stories are of migration from ActiveMQ-->HornetQ due to stability issues with ActiveMQ. Last.fm is a good example: java.dzone.com/articles/case-study-how-lastfm-uses
If issues with HornetQ are reported we are normally *very* quick in fixing them, if they're real issues and not just configuration issues (we get a lot of configuration issues especially when Spring is used). If you can point me to the JIRAs you filed to report the issues you had I'll try and find out why they didn't get fixed for you. -
According to RabbitMQ FAQ
RabbitMQ operates at sub-millisecond latency in transient mode under a load of 10k messages per second. In persistent mode, it should be possible to achieve a throughput of 3-5k messages per second stored to disk depending upon the exact configuration.
From our testing, we expect easily-achievable throughputs of 4000 persistent, non-transacted one-kilobyte messages per second (Intel Pentium D, 2.8GHz, dual core, gigabit ethernet) from a single RabbitMQ broker node writing to a single spindle.
8 comments
Watch Thread Reply