[rabbitmq-discuss] Queues versus Bindings
simon at rabbitmq.com
Thu Apr 18 17:01:05 BST 2013
On 18/04/13 16:53, danb wrote:
> For my scenario, what's better: a queue with 6000 bindings, or 6000 queues
> each with one binding?
> My Scenario:
> In my application I'd expect perhaps 1 to 20 messages per "binding" over
> about 3 minutes. So if I take the many queues approach the queues will be
> mostly idle, and I would destroy the queue after around 3 minutes so they
> would be relatively short lived. I only have one process listening to the
> messages using one connection with multiple channels.
In that scenario I would go for just one queue; it just feels less
> Note: 6000, over 3 minutes means I'll be creating and deleting 33 queues per
> second. Or alternatively adding or removing 33 bindings per second.
While that rate of binding churn is tolerable I might try to figure out
if it's possible to live without it - creating / deleting a binding is
rather more work than publishing / consuming a message. If you must have
that much churn you might want to ensure at least one of your queue and
exchange are non-durable, otherwise you will force an fsync after each
bind / unbind.
> In the thread
> Emile mentions that Rabbit can declare an "enormous number of idle queues
> without difficulty". But I remember reading that Rabbit uses one Thread per
> Queue, so I'm wondering what an enormous number is?
It uses one *Erlang process* per queue - but Erlang processes are
designed to be much more lightweight than native threads. Typically we
limit the Erlang VM to 1M processes by default, but that limit can be
exceeded with a reconfigure.
More information about the rabbitmq-discuss