[rabbitmq-discuss] Is RabbitMQ indeed "hype ware"?
Gavin M. Roy
gmr at myyearbook.com
Sat Aug 29 16:26:21 BST 2009
While I've not completed my migration from ActiveMQ to RabbitMQ, every
indication is that it is faster in my work load. I do not have
thousands of consumers, but I do have thousands of clients connecting,
enqueueing and disconnecting.
In this scenario, connection times in ActiveMQ increase over the
course of days, starting at 4ms and if left unattended to, increase
to100's of ms. The only way to resolve this is to restart the
ActiveMQ broker which is disruptive and an operational issue for us.
In addition, load tests show that ActiveMQ slows considerably with
steady enqueue with no dequeue, over the course of 1000's of messages.
I ran this same test with RabbitMQ runs steady until it runs out of
memory which for my tests was around 2M messages.
On Sat, Aug 29, 2009 at 10:20 AM, Dikkie Hagel<dikkiehagel at hotmail.com> wrote:
> I am in the process of setting up messaging middleware for a webbased
> platform which should be able to handle millions producers/consumers.
> We've started our development with ActiveMQ. Everything seemed to work fine
> until we started connecting with 1000 consumers to a single topic. ActiveMQ
> could not handle this at all, complaining about "too many open filehandles".
> Others seem to have encountered this same issue as well (see second life's
> review), but we've not been able to google a solution. That was a major
> showstopper, and made us conclude that something was terribly wrong with the
> architecture of this software, which made it unsuitable for our intended
> We then turned to RabbitMQ, and after fixing the Perl and ActionScript AMQP
> interfaces (http://github.com/joodie) we now almost have a working prototype
> for our environment, ready for some first performance tests.
> Now I just received a mail from the ActiveMQ/Fuse support team, which in
> reply to my report to them about the 1000 consumers issue, quotes their
> "Manager Engineering", stating the following:
> ============== START OF QUOTE =================
> This is due to the configuration out of the box for ActiveMQ - its very
> straightforward for ActiveMQ to handle the same load as RabbitMQ.
> There are some significant benefits in using ActiveMQ over RabbitMQ.
> ActiveMQ has no limit on the depth (number of messages) in a Queue -
> other than disk space. RabbitMQ runs out of memory.
> Also - there's performance benefits too - although sending messages can
> be a lot faster to RabbitMQ (this is due to RabbitMQ caching messages in
> memory) - consuming messages is considerably slower.
> In reality, RabbitMQ is just hype ware - not really suitable for
> production scenarios. Although its getting a lot of traction, it only
> suitable for cases where consumers will always keep up with producers.
> =============== END OF QUOTE ======================
> Now that's a pretty scary assesment there. "Hype ware"... Perhaps RabbitMQ's
> engineers can reply to this, and reassure us that our shift in favour of
> RabbitMQ is a sound decision? (we plan to deploy it on systems with plenty
> gigs of RAM).
> Kind regards, Roberto
> What can you do with the new Windows Live? Find out
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss