[rabbitmq-discuss] Performance Issue

[Pavel Kogan]

Matthias, Alvaro

Thanks for quick reply.

1) Rabbit version: 2.8.4
    Erlang version: R14B04

2) The other queues are some idle some working (not very hard - up to 30-40
message per second).

3) Meaning:
    a) Declaring durable named queue: channel.queueDeclare(queue_name,
true, .... ).
    b) Binding queue: channel.queueBind(queue_name, exchange_name,
routing_key).

4) I will take a closer look at basic.qos

5) We are declaring queue only once on initialization (we are using JAVA
client).

Thanks,
   Pavel



On Mon, Jan 14, 2013 at 5:44 PM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

> Pavel,
>
>
> On 14/01/13 21:21, Pavel Kogan wrote:
>
>> I have a rabbit server on single dedicated CentOS machine (Quad Core
>> with 16Gb RAM) connected to 1Gbit LAN.
>>
>
> What version of Erlang and Rabbit are you running? If it's not the latest
> of both then please upgrade.
>
>
>  I have many queues running, but total number of messages is not very
>> high for such a machine.
>>
>
> What are all those queues doing? Are the completely idle or is there a
> trickle of messages flowing in/out/through them?
>
>
>  The problem is following:
>> 1) I connect client A to some queue (with many many messages ready) with
>> some routing key - it processes 150 messages per sec (its limit).
>>
>
> What do you mean by "connect... to some queue... with some routing key"?
> Consuming from a queue does not involve a routing key.
>
>
>  2) I connect another client A in parallel on identical server to same
>> queue with same routing key. Now I have 2 identical consumers on same
>> queue and messages are distributed on round robin
>>      manner, but somehow second unit receives only 50 messages per sec.
>> 3) If I disconnect A1, A2 starts working normally. If I connect A1 back
>> it becomes a slow node.
>>
>
> As Alvaro said, check your basic.qos settings; if they are too low then
> throughput becomes bounded by network latency.
>
> Also, check that there aren't any extraneous AMQP commands being issued by
> your client. e.g. it would be bad if, say, it (re)declared the queue every
> time it receives a message. You may want to connect through the tracer (
> http://www.rabbitmq.com/api-**guide.html#tracer<http://www.rabbitmq.com/api-guide.html#tracer>)
> and examine the command stream.
>
>
> Regards,
>
> Matthias.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130114/956cfeaa/attachment.htm>