BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News JBoss Benchmark Claims HornetQ is the Performance Leader of Enterprise Messaging Systems

JBoss Benchmark Claims HornetQ is the Performance Leader of Enterprise Messaging Systems

Leia em Português

This item in japanese

Bookmarks

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!

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Who measures the resilience figures

    by Eirik Maus,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    .... 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.

  • Re: Who measures the resilience figures

    by Martijn Verburg,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • RabbitMQ?

    by Ilya Sterin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

  • Re: RabbitMQ?

    by Simon Knott,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Maybe they didn't include RabbitMQ because the benchmark was comparing products which implement the JMS specification.

  • Re: RabbitMQ?

    by Tim Fox,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Stability

    by Tim Fox,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Comparing to other messaging systems

    by Adam Warski,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A comparison of replicated, persistent message queues, including HornetQ, as well as SQS, Kafka, RabbitMQ and Mongo can be found here: www.warski.org/blog/2014/07/evaluating-persiste...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT