[rabbitmq-discuss] Performance Observations and Interesting Behavior

Ron Cordell ron.cordell at gmail.com
Wed Feb 12 17:20:51 GMT 2014

We are testing the application against the RabbitMQ cluster, so there are
many queues involved, all of which are HA. Most of the queues present the
work or results of an activity, where each activity is part of a larger
finite state machine. The application processes incoming messages via these
state machines, and we drive the application and RabbitMQ testing by
pushing through levels of messages. In this case there are about 100
queues, but only 15 of those are actively used; the remainder represent
error states or other "non-happy path" activities. All of this is
accomplished using the MassTransit libraries, which manages sagas and
message retry/reprocessing as well as other things on top of an AMQP
messaging system.

So... all that being said - we pump through about 100K messages/hour, each
message is ~5K in size, and messages are real in the sense that the
application under test will process them successfully into the system using
RabbitMQ. We're not just testing raw performance of RabbitMQ but the
performance of RabbitMQ in the context of the application. This increases
the number of variables when testing but we can observe the Rabbit cluster
under test and still draw conclusions.

Hope this helps and if you have any other feedback it would be welcome!



On Wed, Feb 12, 2014 at 3:10 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 11/02/14 23:42, Ron Cordell wrote:
>> 4. (here is the interesting one) When the F5 is configured to load
>> balance across the 3 nodes as a round-robin load balancer, maximum
>> throughput is significantly less than if the F5 sends all traffic to a
>> single node.
>> I'd love any feedback, especially on #4.
> Depends exactly what your tests are doing.
> If your tests are running through a single queue then it will be faster to
> publish and consume on the node which hosts that queue since you can avoid
> sending messages across the cluster.
> [This effect is particularly pronounced if using basic.qos or
> mandatory=true, since those currently involve synchronous request-response
> across the cluster. This will get fixed in 3.3.0.]
> Cheers, Simon
> --
> Simon MacMullen
> RabbitMQ, Pivotal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140212/7e56d076/attachment.html>

More information about the rabbitmq-discuss mailing list