[rabbitmq-discuss] Need help to interpret performance results

[tang qingxiong]

Hi,

        I redone the test with the agent enabled on all the nodes.

       This is the results,
overview

http://img805.imageshack.us/img805/2306/overviewrabbitmq1.jpg

queue

http://img522.imageshack.us/img522/4746/queuesrabbitmq1.jpg

I noticed that the messages in 1 queue is increasing despite the fact that
the incoming is still <= get/deliver. The pileup is actually quite
significant as I only managed to last an hour before the broker crashed due
to insufficient memory. one message could be up to 300kb as thats what I
set the frame size to be (I assume that is the message size).

Was wondering if it is a problem with the way I implement the clustering or
code.

my cluster config is as follows
server 1
[
{rabbit,[{vm_memory_high_watermark, 1.0},{frame_max,
0},{cluster_nodes,['rabbit at SERVER1','rabbit at SERVER2']}]}
].
server 2
[
{rabbit,[{vm_memory_high_watermark, 1.0},{frame_max,
0},{cluster_nodes,['rabbit at SERVER2','rabbit at SERVER1']}]}
].
.
.
.
.

server 5
[
{rabbit,[{vm_memory_high_watermark, 1.0},{frame_max,
0},{cluster_nodes,['rabbit at SERVER5','rabbit at SERVER1']}]}
].

Thanks,
Qingxiong
On Tue, Dec 6, 2011 at 11:38 PM, Simon MacMullen <simon at rabbitmq.com> wrote:

> 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/<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<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
> ______________________________**_________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<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/20111207/41154d14/attachment.htm>