[rabbitmq-discuss] routing threads on a rabbitmq node

[Matthias Radestock]

Brian,

Brian Sullivan wrote:
> 1) How many msgs/second are being published for this issue to occur?
>  From a single producer, about 900 messages/sec during these burst 
> catchup periods.  Normal volumes then drop down to 300-500 mps 
> throughout the day, which we can keep up with for the most part.  Note 
> that there are 8-9 such producers, distributed across 2 nodes.

So that's a 900Hz * 9 = 8.1kHz peak inbound rate?

> 4) How many queues do messages end up in, on average?
> About the same number of bindings - 75.  We don't do many multiple 
> bindings per queue (if any).

8.1kHz inbound with a 75x fan-out ratio would require an outbound rate 
of >600kHz, which is way more than a two-node rabbit cluster can handle. 
So some backlog will certainly build up.

It will take a while for messages to make it into queues. This isn't 
helped by lack of optimisation in two areas of the server code:

- topic exchanges. As you know, they are currently totally unoptimised 
and the cost of determining the queues a message should be routed to is 
linear in the total number of bindings on the exchage. How many bindings 
are there in total in your case? If you can, please use a direct exchange.

- cross-node routing in a cluster. A while ago we had to remove 
optimised cross-node routing since it turned out to break certain effect 
visibility guarantees required by AMQP. As a result, routing a message 
to N queues residing on a different node will result in N network 
transmissions of the message to that node, and N copies of the message 
at the node. If you can, don't use clustering or at least avoid 
configurations where producers and consumers connect to different nodes.


Regards,

Matthias.