[rabbitmq-discuss] Need help to interpret performance results

[Simon MacMullen]

Hi Tang.

On 06/12/11 15:22, tang qingxiong wrote:
> Some background. My project is trying to implement rabbitMQ as a
> communications protocol as a direct replacement for OpenAMQ as it is
> outdated. We are running C++ on windows server 2003 and used the C
> client library to implement our solution.
>
> We setup 4 clustered brokers for clients to connect to. We have 20
> clients each publishing data using direct mode to the same exchange with
> all the queues listening to the same key.
>
> The idea of the setup is that if 1 client sends out data each of the
> other 19 will receive the data.
>
> We ran our application and noticed that the queues actually pile up.
> I have taken screenshoots of the management console.

You *must* enable rabbitmq_management_agent on every node in the cluster 
to be able to trust the figures you see in management - at the moment 
you're only seeing partial message rates; they are not guaranteed to add 
up *at all*.

> http://imageshack.us/f/213/overviewrabbitmq.jpg/
>
> This shows that the ready queue which is increasing overtime and also
> publish and deliver.
>
> http://img690.imageshack.us/img690/903/queuesrabbitmq.jpg
>
> This image shows the incoming rate of each client is 12/s and deliver is
> 30/s.

It's probably not.

> I am wondering if anyone here knows the reason on the pileup as the
> incoming rate is less than the deliver rate.

Even when you get rabbitmq_management_agent installed, there can still 
be small pileups when mgmt shows incoming and deliver being the same, 
since the rates are averages and are not sampled at the exact same 
instant as queue lengths anyway.

But small pileups are not a problem - it is a message *queue* after all :-)

> (Assuming the incoming rate
> is the rate of receiving and deliver rate is the rate of sending.).

Incoming = rate at which messages enter the queue. Deliver = rate at 
which they are consumed.

> Also is there anyway to further optimize the rate of speeding and
> receiving either programmatically or configuration. Our send and receive
> code is very similar to the example provided by the Client here

Well 30 msg/s should be nothing. You shouldn't need to optimise anything 
much.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware