Sharon,<br><br>Further to Simon's comments, each connection will consume ~66K memory and each connection also creates 8 Erlang processes (or thereabouts), so you'd need to factor in this memory usage and ensure that Erlang is able to spin up the required number of processes. You'd obviously also need to tweak a few system parameters to allow that many connections/sockets - all quite doable of course, but I'd concur with Simon that unless you have a pretty grunty server you could face some challenges. That being said, Erlang (and by inference RabbitMQ) can certainly handle this sort of thing... you might like to have a look at <a href="http://www.youtube.com/watch?v=wDk6l3tPBuw">http://www.youtube.com/watch?v=wDk6l3tPBuw</a>.<br>
<br>Brett<br><br><br><div class="gmail_quote">On Wed, Aug 22, 2012 at 4:16 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Sharon.<br>
<br>
There isn't a hard coded limit of course, but ~10M queues sounds optimistic, especially if combined with ~10M TCP connections.<br>
<br>
I don't think 1) and 2) are all that different. Unless you need the wildcard matching of a topic exchange you might as well pick a direct exchange.<br>
<br>
But in both cases you have millions of connections / consumers / queues. That *is* quite a lot to support on one machine. Are all these consumers going to connect simultaneously? You may have trouble raising the fd limit that high.<br>
<br>
Also each connection / consumer / queue will take a few kb of memory even when idle - so that could eat up quite a few GB before you do anything.<br>
<br>
My gut feeling is that supporting that many simultaneous connections will be a problem before the raw number of queues is.<br>
<br>
Cheers, Simon<div class="HOEnZb"><div class="h5"><br>
<br>
On 21/08/12 15:27, sharonbn wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I am investigating using RabbitMQ and AMQP to push notifications from our<br>
web app to client apps on Android devices.<br>
<br>
In our case, we have few publishers and many consumers (millions, perhaps<br>
~10M), all connected to the broker and ready to consume messages.<br>
every now and then, the publisher needs to send one message to one and only<br>
one consumer.<br>
each consumer will receive few dozens of messages daily. Message<br>
acknowledgements is not mandatory.<br>
btw, the broker (or cluster?) will be hosted on AWS EC2 instances.<br>
<br>
I was wondering if there are any limitations on number of connected<br>
consumers and what's the best strategy to implement such a scenario. �From<br>
the documentation, it seems to me there are two ways to do this:<br>
<br>
first of all, each client app already reports a unique identifier to the web<br>
app (this is done prior to any message sending). �this unique id, known on<br>
both sides, can be used to ensure routing of the message to the specific<br>
client.<br>
<br>
1) The most obvious way is to have one direct-exchange and create an<br>
exclusive queue per consumer with the unique id as the queue name. �this<br>
means there will be millions of queues that are most of the time empty or<br>
nearly empty.<br>
<br>
2) Have one topic-exchange with (how many?) queues. �the unique id will be<br>
used as topic name. �Here we have millions of topic names.<br>
<br>
which is the best solutions (or perhaps a third option)? �any other<br>
considerations in this use case? �any special configuration/settings? any<br>
help is appreciated :)<br>
<br>
thanks,<br>
<br>
Sharon.<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://rabbitmq.1065348.n5.nabble.com/How-many-queues-can-one-broker-support-tp21539.html" target="_blank">http://rabbitmq.1065348.n5.<u></u>nabble.com/How-many-queues-<u></u>can-one-broker-support-<u></u>tp21539.html</a><br>
Sent from the RabbitMQ mailing list archive at Nabble.com.<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</blockquote>
<br>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</div></div></blockquote></div><br>