ActiveMQ Apollo Looking Impressive

ActiveMQ Apollo is a new generation of messaging broker built from the foundations of the ActiveMQ messaging broker, but using a radically different threading and message dispatching architecture.  In it’s current incarnation, Apollo only supports the STOMP protocol but just like the original ActiveMQ, it’s been designed to be a multi protocol broker and in future iterations it should get OpenWire support so it can be compatible with ActiveMQ 5.x JMS clients.

The BIGGEST change in the broker architecture was a switch to a non-blocking threading model for message processing using the HawtDispatch library.  This meant changing many of the APIs to using a continuation passing style so that caller never blocks on a request.  The upside of the new architecture is that the most complex and brittle areas of multi-threaded code in ActiveMQ 5.x  have now been tremendously simplified.  Those areas are using actor style coarse grained synchronization thanks to HawtDispatch.

It is impressive how well Apollo performs. Using a little benchmarking tool, I compared the performance of Apollo and three other STOMP server implementations.  The benchmark tests different combinations of consumers, destinations, producers, persistence options, message sizes for a total of 74 common usage scenarios.  I ran the benchmarks on two different boxes.  If you want to peek at the complete benchmark reports, see Ubuntu 4 Core report and OS X 8 Core report.

Apollo ends up doing really well in comparison to other servers in most cases but in some cases it’s just mind blowing.  For example:

The  scenario above is the case where you have 10 producer and 10 consumers on a single topic moving non persistent STOMP messages with a 20 byte payload.   The graph shows that Apollo can easily sustain a total consumer processing rate of 1.2 Million messages per second while the closest contender could only reach about 105,000 thousand messages per second.

5 thoughts on “ActiveMQ Apollo Looking Impressive

  1. Dear god – 1.2m mps? Smashing! Nice work Hiram, this is blowing all previous stats out of the water. Now – ahem – if it’s not *too* much a down to earth question – what’re the stats like for persisted messaging? Keep up the good work…

  2. Hiram,

    The Hornet team haven’t put a lot of effort _as yet_ into optimising the STOMP protocol in HornetQ, also the codec has actually been more or less completely rewritten since the version you tested (it used to be _really_ slow), however they could definitely spend some more time getting it up to the levels of performance of our core protocol.

    As you know, if we compare the performance of JMS (using our core protocol) rather than STOMP, then ActiveMQ comes off a lot worse than HornetQ. http://community.jboss.org/wiki/HornetQ-thePerformanceLeaderinEnterpriseMessaging (we did have a comparison of all major messaging implementations in there but unfortunately had to remove some of the proprietary ones due to legal reasons) – in fact HornetQ came across #1 across all JMS implementations.

    Also, when benchmarking _real_ workloads including combinations of persistent, non persistent etc, e.g. using the independent SPECjms benchmark then, again, HornetQ wins out again http://www.spec.org/jms2007/results/jms2007.html

    Having said that, your results are *very* impressive and set the standard for competing STOMP implementations. I think STOMP (especially 1.1) is going to be an important technology going ahead so this is definitely an area the HQ team should look at improving.

    Congratulations on the great results :)

    [Disclosure – I used to be the HornetQ project lead]

  3. This truly is a quantum leap in performance, but what you forgot to say in the post is the *relatively modest* hardware on which you achieved it. That makes the headline figure of 1.2M consumer msg/s even more awesome.

    Just wondering, will there be a like-for-like specJMS2007 run for ActiveMQ Apollo? I presume you will wait for the non-snapshot Apollo release…

  4. This does look impressive. Cant wait till they have all teh other features such as message reply and scheduled messages .. then I will move over from activeMQ to Apollo 😉

Comments are closed.