[rabbitmq-discuss] Queues versus Bindings

[Simon MacMullen]

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 
complicated.

> 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
> http://rabbitmq.1065348.n5.nabble.com/RabbitMQ-with-many-queues-td26033.html
> 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.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware