[rabbitmq-discuss] Rabbitmq vs. Activemq
Matthias Reik
maze at reik.se
Mon Jul 8 22:13:02 BST 2013
In addition to what was already said ...
... what was important for us is the rather freely reconfigurability of
Exchanges to Queues. Even though we don't have to do that too often,
it's still a very powerful feature of AMQP.
Ok, I haven't looked into ActiveMQ for several years. So I might be
outdated :-(
Cheers
Maze
On 2013-06-18 14:20 , Chris wrote:
> 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
> <mailto: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/
>
> 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
> <mailto:rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> <mailto:rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> 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/20130708/b9dfbf47/attachment.htm>
More information about the rabbitmq-discuss
mailing list