I really dislike graphs that leave labels off. When presenting results its nice to have a clear understanding of whats being displayed, the missing Y axis on these graphs is not helping.
A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
21–30 of 46 posts
Re: A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
#22Anyone here use NSQ in production (https://github.com/bitly/nsq). If so what are your thoughts in comparison to the article?
Re: A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
#23I would rather see number of processes varied.
Re: A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
#24Earlier quoted context omitted.
> 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…
AMQ is sensitive to proper memory configuration. Typically what will happen is the memory configuration in the activemq.xml doesn't line up with the JVM heap and this causes garbage collection thrashing. It reaches a point where the CPU spikes and the monitor process zaps the JVM process, which causes a restart. If everything is tuned and lined up properly this won't happen. I've used AMQ in high-volume production sy…
I've played with this and am not getting anywhere near the -Xmx set for the JVM and producer flow control isn't kicking it. Load on this broker isn't very high either, 5k to 10k messages/day, all messages << 1KB.
Re: A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
#25I would like to see Kestrel (and Darner) in this benchmark. My personal experience with Darner is that it handles extreme loads. Granted, the MQ is not distributed and it is difficult to do "topics" in the JMS sense.
Re: A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
#26I really dislike graphs that leave labels off. When presenting results its nice to have a clear understanding of whats being displayed, the missing Y axis on these graphs is not helping.
"And now, the results (processing time measured in seconds: the lower the better)."
Re: A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
#27Earlier quoted context omitted.
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.
[deleted]
Re: A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
#28Earlier quoted context omitted.
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?
Re: A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
#29When is a message queue required? And when is a pub/sub setup with Redis good enough? I'm sure it's apples to oranges, but there must be a few places with ActiveMQ installed where it wasn't really needed.
Re: A quick message queue benchmark: ActiveMQ, RabbitMQ, HornetQ, QPID, Apollo
#30I suspect this benchmark is actually just testing the difference between STOMP and AMQP. RabbitMQ with STOMP is in the same regime as ActiveMQ / Apollo while RabbitMQ with AMQP is always 3x-5x faster than itself and others with STOMP.
QPID is the only other AMQP competitor and it seems to have performance issues with persistence but the transient performance is always in the same regime as AMQP RabbitMQ.
STOMP is a UTF-8 text protocol while AMQP is a binary protocol. This means that every message you send using STOMP requires encoding it in a safe-for-text format (e.g. base64 encoding or similar. I'm not intimately familiar with STOMP).
Going on the hypothesis that a STOMP message parser is much slower than an AMQP parser, this would explain why RabbitMQ AMQP does not perform well in the 200 message case while it trounces in the 20k and 200k message case. In the 20k/200k message case the benchmark is mostly looking at time to decode 200k text messages versus 200k binary messages.
It's so exceedingly hard to do a benchmark and measure the thing you think you are measuring.
Also, I agree with others that the minimal difference between persistent and transient setups is very non-intuitive. The author left out an important detail of whether he was using an SSD or not. Otherwise, I suspect an error in the measurement setup.