[rabbitmq-discuss] performance

Mon Sep 1 21:09:47 BST 2008

Just few hints:

1. Measuring maximal throughput is tricky for various reasons, queueing 
being only one of them. There are statistical and methodological 
problems like hidden average, non-stability of the metric etc. However, 
simple way to get *some* results is to run the tests with publisher 
publishing messages at various rates. Maximal rate where latency doesn't 
increase ad infinitum can be considered "maximal throughput".

2. 380,000 256-byte messages a second is a nice result, however, it 
doesn't tell much about the messaging system. It simply means that the 
system is able to exhaust 1GbE with messages 256 bytes long. To get more 
interesting results, test should be run with smaller messages 
(preferably 0 or 1 bytes long) where processing power will be the 
bottleneck rather than the networking infrastructure.

HTH.
Martin

Matthias Radestock wrote:
> Michael,
> 
> Mayne, Michael wrote:
> 
>> Red has produced a paper recently (June 2008) explaining its performance
>> testing lab that it did recently to show how optimised Red Hat on Intel
>> Xeon hardware can process very high message rates:
>> http://www.redhat.com/f/pdf/mrg/Reference_Architecture_MRG_Messaging_Thr
>> oughput.pdf 
>>
>> This paper was presented at an Intel FasterCITY - fasterMESSAGING event
>> in London on 23 June.
>> http://www.intelfasterfs.com/fastermessaging/ 
>> It contains a description of the test bench it used to generate its
>> figures - which were a repeatable ingress rate of 380,000 (256 byte)
>> messages per second. There is obviously a lot more to it - see the paper
>> for details.
>>
>> That could be a starter for ten.
> 
> I am familiar with that report. The tests conducted are pretty similar 
> to the ones we did with Intel last year and earlier this year (see 
> http://www.rabbitmq.com/resources/AMQP_Solution_Brief_final.pdf).
> 
> Unfortunately the test setup - "producers reliably en-queues messages 
> onto the broker as fast as they can, consumers reliably de-queue 
> messages from the broker as fast as they can" - isn't addressing the key 
> problem I described, namely controlling and adapting the ingress rate in 
> order to maximise throughput.
> 
> 
> Matthias.
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss