Rabbitmq vs. Activemq
Locked
 
|
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.
_______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
Hi,
I have a question about connection blocking. When memory alarm is true, RabbitMQ is blocking incoming connections. But I want it to reject connections, is it possible? Thanks, Umutcan. _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
2013/6/18 Umutcan <[hidden email]> When memory alarm is true, RabbitMQ is blocking incoming connections. But I want it to reject connections, is it possible? Not at the moment. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
Re: Rejecting Connection
|
|
On 18/06/13 09:16, Michael Klishin wrote:
> 2013/6/18 Umutcan <[hidden email] <mailto:[hidden email]>> > > When memory alarm is true, RabbitMQ is blocking incoming > connections. But I want it to reject connections, is it possible? > > > Not at the moment. Bear in mind that RabbitMQ doesn't actually block incoming connections when the memory alarm is raised. Instead it only blocks connections which are publishing; it's perfectly ok for a client to connect and consume. Also bear in mind that memory alarms are generally very transient, i.e. they shouldn't last more than a few seconds. Rejecting connections during that time seems a tad severe. I'm curious what the use case is here. Matthias. _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
In reply to this post by michaelklishin
On 06/18/2013 11:16 AM, Michael Klishin
wrote:
OK. Then, is it possible to check if connection is blocked or not in order to close connection? I know I can use timeout but I do not prefer to use a timeout. _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
2013/6/18 Umutcan <[hidden email]> Then, is it possible to check if connection is blocked or not in order to close connection? There is no easy way at the moment. In one of the future versions, there will be a way to react to connection blocking. Note that it will require client
libraries to be updated. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
In reply to this post by Matthias Radestock-3
On 06/18/2013 11:27 AM, Matthias Radestock wrote:
> On 18/06/13 09:16, Michael Klishin wrote: >> 2013/6/18 Umutcan <[hidden email] <mailto:[hidden email]>> >> >> When memory alarm is true, RabbitMQ is blocking incoming >> connections. But I want it to reject connections, is it possible? >> >> >> Not at the moment. > > Bear in mind that RabbitMQ doesn't actually block incoming connections > when the memory alarm is raised. Instead it only blocks connections > which are publishing; it's perfectly ok for a client to connect and > consume. > > Also bear in mind that memory alarms are generally very transient, > i.e. they shouldn't last more than a few seconds. Rejecting > connections during that time seems a tad severe. > > I'm curious what the use case is here. I am sending data to a mysql database with my consumers. When everything is normal with database, memory use of the broker is low. But, sometimes mysql server fails (or some operations may be running) and the messages is begining to wait in the queue. If solving problem with the database takes too long time, memory use reaches the limit. So, I want my publishers to stop publishing new messages when this happened. _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
In reply to this post by JC
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@middlewarebench 1 1 0 25000 1000000 20776 5644 20776 > 99484 7959080 259337 255760 316848 > Rabbit@middlewarebench 1 1 0 25000 1000000 20749 5440 20749 > 171994 46140955 870211 913283 988979 > > > > > > > > > > > > > > > Activemq@middlewarebench 1 1 0 100000 1000000 62695 5347 62695 > 100634 19872040 491588 359763 510862 > Rabbit@middlewarebench 1 1 0 100000 1000000 56850 6790 54512 > 315808 822398215 487403726 487170082 696265654 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > rabbitmq-discuss mailing list > [hidden email] > https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss > -- Simon MacMullen RabbitMQ, Pivotal _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
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 <[hidden email]> 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. _______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
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:
_______________________________________________ rabbitmq-discuss mailing list [hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
This post has NOT been accepted by the mailing list yet.
In reply to this post by JC
You can find more detailed comparison at http://blog.digiqt.com/index.php/2017/04/23/how-you-scale-infrastructure-with-distributed-messaging/
|
«
Return to RabbitMQ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |