Hacker News Reader

Comment by DomBlack | Hacker News Reader

I'm interested to see ZMQ being compared to the traditional brokers as I've been considering swapping from ActiveMQ. Although not surprised at it's results. It very much re-enforces the ideal of keeping software simple and barebones, rather than bloating it with stuff most people never use.

Mainly because I'm finding the latency from ActiveMQ is starting to affect my overall system latency. RabbitMQ was the next broker on my list to test, but ZMQ makes more sense (if you don't mind writing the broker part).

Background; I'm currently running a system which at peak runs with about 15 million messages per hour using ActiveMQ, with several producers and consumers on the same topic. Apart from speed, not had any issues with it.

View on HN

Background; I'm currently running a system which at peak runs with about 15 million messages per hour using ActiveMQ, with several producers and consumers on the same topic.

Another vote for RabbitMQ. We're currently using a small RabbitMQ cluster that is averaging 5000+ msgs/sec and its not straining the sytem. At times, we've experienced bursts approaching 10,000 msgs/sec without any issues.

We have around 30 producers and 45 consumers spread out over a wide range of queues & exchanges.

Whilst ZMQ is generally faster, it does require more effort to be useful. Whereas RabbitMQ, I believe, provides the best of both worlds. Blazing fast messaging combined with ease of use and setup.

ActiveMQ or ActiveMQ Apollo? Definitely give Apollo and try if you haven't, it's incredibly easy to drop it and requires very little configuration.

I'm processing similar peak levels with Apollo, and so far have been amazed at how well it handles things.

ActiveMQ or ActiveMQ Apollo?

ActiveMQ, haven't looked too much into Apollo since almost it's original announcement. How is it from a stability standpoint?

How is it from a stability standpoint?

The only issues I encountered were been due to not assigning enough memory to the JVM. Other than that it's done the job admirably.

I would not use ZeroMQ for anything but the most non-critical queues. ZeroMQ is not persistent: if your server crashes you lose all your queue contents.

My current favorite is RabbitMQ. It has improved steadily over the years, performs pretty well and very easy to setup.

ZeroMQ is a messaging library only.

There is nothing stopping you from using ZeroMQ to build a daemon that implements a persistent queue— in fact, I have, several times. It's very simple.

And then you've made your own broker. At that point why not use an existing, more mature broker?

The zero in ZeroMQ is because brokerlessness is a strength in some aspects.

A broker can be an SPOF, for instance. 0MQ makes it easy to do shared-nothing.

I know what ZeroMQ does. But you argue that a one can easily write a broker on top of ZeroMQ that provides persistency, but that invalidates your biggest reason of using ZeroMQ, namely brokerlessness.

Besides SPOF is not an argument. All serious brokers have supported clustering and failover for quite a while, and they support persistency. I don't see a good reason why you may want to write a ZeroMQ-based broker instead of just using RabbitMQ.

ZeroMQ is not persistent: if your server crashes you lose all your queue contents.

With my requirements if I haven't processed the message quick enough then I don't care if it gets lost, as it would already be outdated data.

+1 for the carrot muncher here is well

Reply on news.ycombinator.com