11–20 of 46 posts
Earlier quoted context omitted.
True, but it's in-memory only (there was no persistence with ZeroMQ in the given setup).
Then why even test ZeroMQ then? If you plan to setup a benchmark test, and then decide to throw out the results (winner/ZeroMQ) because it doesn't produce the desired outcome you wanted ... then this benchmark is a joke to begin with.
Earlier quoted context omitted.
True, but it's in-memory only (there was no persistence with ZeroMQ in the given setup).
Then why even test ZeroMQ then? If you plan to setup a benchmark test, and then decide to throw out the results (winner/ZeroMQ) because it doesn't produce the desired outcome you wanted ... then this benchmark is a joke to begin with.
- All these products have a lot of knobs to set. Performance depends on these knobs. It depends on whether you do batch sends(which some can do), whether you do transactions, whether you chose at-least-once, at-most-once etc. delivery, queue prefetch sizes, I/O worker size, and numerous other settings.
It'd also be interresting to see qpid-cpp in there as well, not just the Java version.
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 brok…
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.
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 brok…
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.
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.
Interesting results! In my testing, I came to a different conclusion. Background: PHP and STOMP, with loads of several million messages per hour, ranging in size from 2-20Kb. Multiple processes enqueuing, and many more dequeuing. Tests performed about this time last year. Out of ActiveMQ, RabbitMQ and Apollo: ActiveMQ crashed constantly under load. RabbitMQ could not enqueue/dequeue fast enough. Apollo blew them all…
That has been my experience as well, to this day I have an ActiveMQ broker for which the JVM just stops responding, its not the broker that goes unresponsive, its the entire JVM, with no error, no log, no nothing, it just stops replying to the service wrapper and sits at 100% cpu usage. The wrapper kills that JVM and restarts it once every couple days because this happens.
Oh and this was fun: yesterday I went to check on the broker as it was running a bit slow, the DLQ had ~50,000 messages in it that were not there last week, all were timestamped to the same second in ~July 2012...9 months ago...
I'll likely never use ActiveMQ again.
Please keep in mind: - All these products have a lot of knobs to set. Performance depends on these knobs. It depends on whether you do batch sends(which some can do), whether you do transactions, whether you chose at-least-once, at-most-once etc. delivery, queue prefetch sizes, I/O worker size, and numerous other settings. It'd also be interresting to see qpid-cpp in there as well, not just the Java version.
Apart from declaring the testing queues in some brokers’ configuration and the persistence settings, all brokers were running with their default configuration out of the box (no tuning made).
He also casually mentions that ZeroMQ is using an in-memory configuration.
A home-made ZeroMQ 2.2.0 broker, working in memory only (no persistence).
The default configuration of AMQ persists messages to journal on disk. So apples to oranges?
Why do people keep writing "benchmark" blog posts like this?
Interesting results! In my testing, I came to a different conclusion. Background: PHP and STOMP, with loads of several million messages per hour, ranging in size from 2-20Kb. Multiple processes enqueuing, and many more dequeuing. Tests performed about this time last year. Out of ActiveMQ, RabbitMQ and Apollo: ActiveMQ crashed constantly under load. RabbitMQ could not enqueue/dequeue fast enough. Apollo blew them all…
> ActiveMQ crashed constantly under load. That has been my experience as well, to this day I have an ActiveMQ broker for which the JVM just stops responding, its not the broker that goes unresponsive, its the entire JVM, with no error, no log, no nothing, it just stops replying to the service wrapper and sits at 100% cpu usage. The wrapper kills that JVM and restarts it once every couple days because this happens. Oh…
If everything is tuned and lined up properly this won't happen. I've used AMQ in high-volume production systems for years without this problem.
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 brok…
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.