JBoss Benchmark Claims HornetQ is the Performance Leader of Enterprise Messaging Systems
- Share
-
- |
Read later
My Reading List
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!
Who measures the resilience figures
by
Eirik Maus
- 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.
Re: Who measures the resilience figures
by
Martijn Verburg
RabbitMQ?
by
Ilya Sterin
So guys, what happened to RabbitMQ comparison?
Re: RabbitMQ?
by
Simon Knott
Re: RabbitMQ?
by
Tim Fox
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.
Stability
by
Robert Roland
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.
Re: Stability
by
Tim Fox
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.
Re: RabbitMQ?
by
Andrey Paramonov
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.
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think