[rabbitmq-discuss] Rabbitmq vs. Activemq

Tue Jun 18 13:20:36 BST 2013

A couple of other things to consider:

1) Message durability: In my own informal tests (about 8 months ago), I
found that ActiveMQ took a very significant hit once you turned on message
persistence.  RabbitMQ also took a hit, but it was much less significant.

2) Clustering / High Availability: If you need to cluster the brokers for
HA or failover, there are significant differences here.  Last I checked,
ActiveMQ only supported active/passive configurations and they were fairly
difficult to configure, or required separate shared storage nodes.
 RabbitMQ supports active/active configurations, is easy to configure, and
requires no other external dependencies.  That said, I did find that
ActiveMQ clients have better support for automatic failover than most
RabbitMQ clients (so you have to implement it yourself in RabbitMQ clients
or find an add-on library for it).

Disclaimer: I did my research on ActiveMQ 5.7, so you may want to check if
ActiveMQ 5.8 addresses some of these problems...

-Chris

-Chris

On Tue, Jun 18, 2013 at 5:45 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> If your primary concern is latency, testing with a maxed-out message rate
> (which it seems is what you are doing) will give very dubious results.
> Maxing out the message rate means that all internal buffers are full, and
> thus messages take a while to get through the broker.
>
> The same is presumably true for ActiveMQ, but presumably it has smaller
> buffers.
>
> This is even more true if your tests are able to publish messages faster
> than they consume (which I guess is what's happening in your last row) - if
> your test ends up enqueueing messages and then taking a while to dequeue
> them then I am not surprised you see high latency.
>
> Dropping your message rate to even 90% of the maximum will give huge
> latency gains - see the final chart here:
>
> http://www.rabbitmq.com/blog/**2012/04/17/rabbitmq-**
> performance-measurements-part-**1/<http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-part-1/>
>
> Finally, I would be wary of constructing a synthetic benchmark and then
> using it to pick which product you go with, unless you determine that one
> product has acceptable performance and others do not. Factors such as
> reliability, ease of use, feature set and so on tend to be more important
> than a 10% difference in performance.
>
> Hopefully I would still be saying that even if RabbitMQ were "winning"
> your tests :-)
>
> Cheers, Simon
>
>
> On 18/06/13 04:00, JC wrote:
>
>> Hi,
>>
>> We are in the process of evaluating middleware and choosing which
>> middleware we pick for a potentially large scale distributed
>> application.    We did an evaluation between activemq and rabbitmq with
>> different test cases. So far activemq has outperformed rabbitmq using
>> the default out-of-box configuration especially on the latency side.
>> We use activemq openWire protocol vs. rabbit AMQP,  Here is one example
>> result of the test we did on 1 publisher/1 consumer and we measure the
>> latency from send to receive time.    Similar results we get from
>> multiple consumers as well.  Any one has done the similar benchmark?
>> Could you please share your experience?  And if anyone knows the tips to
>> boost rabbitmq performance, please let us know.   The rabbit test client
>> is using fanout exchange and MINIMAL_BASIC to publish messages.
>>
>> BrokerType      Publishers      Consumers       SlowConsumers
>> TgtMsgRate(mps)
>> TgtMsgLimit     AvgMsgSentRate(mps)     AvgSentTime(ns)
>> AvgMsgRcvRate(mps)
>> MinLat(ns)      MaxLat(ns)      AvgLat(ns)      MedLat(ns)      90%Lat(ns)
>> Activemq at middlewarebench        1       1       0       25000   1000000
>>         20776   5644    20776
>> 99484   7959080         259337  255760  316848
>> Rabbit at middlewarebench  1       1       0       25000   1000000
>> 20749   5440    20749
>> 171994  46140955        870211  913283  988979
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Activemq at middlewarebench        1       1       0       100000  1000000
>>         62695   5347    62695
>> 100634  19872040        491588  359763  510862
>> Rabbit at middlewarebench  1       1       0       100000  1000000
>> 56850   6790    54512
>> 315808  822398215       487403726       487170082       696265654
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
>> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>>
>>
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal
> ______________________________**_________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130618/6a5f19fd/attachment.htm>