4 ms·
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
by DomBlack 14y ago
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.
- mootothemax 14y agoBackground; 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. 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.
- DomBlack 14y agoActiveMQ or ActiveMQ Apollo? ActiveMQ, haven't looked too much into Apollo since almost it's original announcement. How is it from a stability standpoint?
- mootothemax 14y agoHow 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.
- FooBarWidget 14y agoI 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.
- sneak 14y agoZeroMQ 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.
- deleted 14y ago[deleted]
- FooBarWidget 14y agoAnd then you've made your own broker. At that point why not use an existing, more mature broker?
- sneak 14y agoThe 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.
- FooBarWidget 14y agoI 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.
- rdtsc 14y ago+1 for the carrot muncher here is well
- plant42 14y agoBackground; 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.