Max number of binding keys per queue

[Eric Fulton]

I'm building a web chat and I'm trying to decide between two setups.  In either case there are clients -> server -> rabbitmq:

Setup 1:

Each client gets their own queue with the binding key for their "chat rooms"

Setup 2:

The server has a single queue with all binding keys for all clients which it routes with custom logic to the subscribers (which are tracked by the server)

My questions are as follows: 

How many binding keys can a queue have?

Which configuration would be more scalable?  

[Michael Klishin]

> On 6 feb 2016, at 5:27, Eric Fulton <dr.ef...@gmail.com> wrote:
>
> How many binding keys can a queue have?

RabbitMQ does not enforce a limit.

> Which configuration would be more scalable?

Using 1 queue is definitely not, plus message
distribution happens at the time of routing (there are no
queue selectors), so a single queue won't work
for typical chat apps.

[Eric Fulton]

Is there a reason why having only one queue per application server wouldn't work?  Why can't I setup an exchange:

chatroom.{chatroomname}

where chatroom name exists for every chatroom subscribed to by every user of a given application server and is bound to that application server's queue?

The application server itself acts as a broker in that it tracks subscriptions, and messages, proxies those through the single queue, and then returns them to the correct subscribing clients.

[Michael Klishin]

Because once a message is consumed and acknowledged by the first user who happens to refresh

her UI, it is deleted.

So you either can use a queue per consumer or use RabbitMQ for message distribution and store messages

in a data store you can repeatedly query. This is a very good idea in general because most chat apps

provide history and search.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Fulton]

Oh I see what you were getting at.  So I didn't give the full details.  The messages are consumed by application servers and a backend which will persist the messages.  History is retrieved from the backend server, and fresh messages are retrieved directly from the queue when a user is logged in.

[Michael Klishin]

Eric,

I'd  still recommend using N queues. You will run into various limitations of a single queue. For example,
a single queue can only use 1 CPU core. There are other limitations, too.

Do you have any particular reasons to not use multiple queues?
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Eric Fulton]

So I'm hoping this application will become popular and I want to build it with scaling in mind.  Let's say tomorrow I have 10 million users.  Then there is the potential for 10 million queues if they all logged on at once.  I figured I could mitigate the number of connections by funneling the messages though a single queue per application server. 

Should I not worry about that?  Would I be able to handle that by simply adding more application servers and more rabbit mq nodes? 

[Michael Klishin]

On 6 February 2016 at 22:14:58, Eric Fulton (dr.ef...@gmail.com) wrote:
> Should I not worry about that? Would I be able to handle that by
> simply adding more application servers and more rabbit mq nodes?

Of course, queues do consume resources, so your concern is valid.

It depends on your mirroring settings. For example, when mirroring to all nodes,
then adding nodes doesn't help distribute the load. But if you mirror to a quorum
or several nodes, and distribute queue masters [1] and client connections between
them, you will be able to scale.

The main resource queues consume is RAM (even when they are empty, because
they have state), using lazy queues [2] help greatly reduce it while only having a minor
reduction effect on throughput.

HTH. 

1. https://www.rabbitmq.com/ha.html, "Queue Master Location"
2, http://rabbitmq.com/lazy-queues.html

[Eric Fulton]

I was going to have the clients all have exclusive queues, so mirroring shouldn't be an issue.  Each backend serer will be subscribing to a subset of all messages flowing through rabbitmq in order to persist the messages.  These queues will be durable so maybe they would be good candidates for lazy queues and a sensible mirroring setup.

With these considerations in mind, it sounds like you would still opt for having a queue per client rather than a queue per application server because of CPU limitations and because I can always scale out the RabbitMQ cluster.

Thank you very much for all of your help!  I'll go with your suggestions!  

[Michael Klishin]

On 6 February 2016 at 22:36:48, Eric Fulton (dr.ef...@gmail.com) wrote:
> With these considerations in mind, it sounds like you would
> still opt for having a queue per client rather than a queue per
> application server because of CPU limitations and because I
> can always scale out the RabbitMQ cluster.

There's a way to work around the single core limitation:
https://github.com/rabbitmq/rabbitmq-sharding

The plugin allows you to use a single "logical" queue backed by multiple physical queues.
This assumes multiple consumers on the logical queue, and means you largely trade off
queue ordering.

The above makes sense for something like Logstash where every event is timestamped
and stored in ElasticSearch, thus order can be reconstructed. I wouldn't recommend that
plugin for every or even most use cases, so this is an FYI .

[Eric Fulton]

This will be brilliant for the backend servers!  I was going to prefix the exchange names and have a different backend server consume based on prefix, but this is much cleaner.  Thank you!

I think I'll try things with a queue per client, do some load testing, and see how things look.  Thanks again for all the help.

[vitaly numenta]

Hi Michael, the sharding plugin sounds great! I read the documentation at https://github.com/rabbitmq/rabbitmq-sharding , but couldn't figure out how many consumers must be created for the sharded queue to avoid starving any of the shards. Since the sharding happens automatically and even dynamically, what's the recipe for making sure that none of the shards will starve?