[rabbitmq-discuss] Is RabbitMQ indeed "hype ware"?

[Alexis Richardson]

Hi

Thanks everyone for these emails.

To further Ben's excellent response, if anyone has any use cases or
tests where they are not seeing what they expect, please do let us
know as much as you can about what you are seeing.  If you can post
any test harnesses on the web, eg on github, then everyone can try to
replicate what you are seeing.  In the case of a messaging system like
RabbitMQ or ActiveMQ, the most interesting production behaviours may
take time to observe so *any* concrete tests to replicate unusual
behaviour are *very* helpful.

Cheers,

alexis




On Sat, Aug 29, 2009 at 8:26 AM, Gavin M. Roy<gmr at myyearbook.com> wrote:
> 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.
>
> Regards,
>
> Gavin
>
> On Sat, Aug 29, 2009 at 10:20 AM, Dikkie Hagel<dikkiehagel at hotmail.com> wrote:
>> Hello,
>>
>> 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
>> purpose.
>>
>> 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
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>