[rabbitmq-discuss] Performance bottleneck on inter-node connection

Thu Apr 10 17:01:48 BST 2014

(re-adding the list)

On 10/04/14 16:42, joseph rouphael wrote:
> On Thu, Apr 10, 2014 at 11:57 AM, Matthias Radestock
> <matthias at rabbitmq.com <mailto:matthias at rabbitmq.com>> wrote:
>     Have you tried this w/o hipe?
> In fact, HIPE is not enabled in Erlang, so this config has no effect.
> (You can consider Hipe off)

ok, I'd still prefer if you took out that setting.

>         {delegate_count, 32},
>     Why did you set this?
> I have used this in a try to increase the number of delegate processes
> used for intra-cluster configuration. Hoping that will increase
> inter-node communication performance (But this had no effect)

Ditto.

> In fact, I am not using any synchronous mechanism. I am publishing
> messages with no confirm.select.
> I am using a c client (based on rabbitmq-c) to publish messages with the
> following config:
> - Non persistent
> - No confirm.select
> - Default Direct exchange
> - Routing key equal to queue_name
> - Message size 1KB
> I am running 10 client processes which are publishing in parallel to 10
> different queues.
> Rate is regulated on the client, I can force the publsih rate in the C
> client.
>
> I am running as well 10 other client processes to consume full-speed (no
> rate regulation) from the 10 queues.

Do the consumers use acknowledgements?

> I am using the same setup to publish/consume messages on one node (node
> 1 where queues are created), with no issue. I can hit up to 100K TPS (5K
> TPS on each client process).
> The problem appears only when I try to publish on node1 and consume from
> node2 (or publish on node2 and consume from node1). The problem appears
> only when there is an inter-node activity.

So the 100kHz is the aggregate publishing and consuming rate, i.e. 10 x 
5kHz publishing and 10 x 5kHz consuming?

What results do you get in the single-node and multi-node scenarios when 
running the tests with just a single queue and single producer and 
single consumer?

Regards,

Matthias.