[rabbitmq-discuss] routing threads on a rabbitmq node
matthias at lshift.net
Wed Feb 3 02:00:37 GMT 2010
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.
More information about the rabbitmq-discuss