Hacker News Reader

Comment by mootothemax | Hacker News Reader

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 out of the water and, long-term, has proven extremely stable.

I must admit that haven't spent hours performance tuning. The results shown here, however, make me think I should go back and re-evaluate.

View on HN

> 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 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.

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 systems for years without this problem.

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.

"RabbitMQ could not enqueue/dequeue fast enough"? I think the STOMP plugin was still pre-production a year ago. You may want to try using RabbitMQ 3.x..

I think the STOMP plugin was still pre-production a year ago. You may want to try using RabbitMQ 3.x.

Cool, thanks, I'll take a look and see how we go :)

Reply on news.ycombinator.com