Thanks for the input. This is exactly the type of info I'm looking for!<br><br><div class="gmail_quote">On Fri, Mar 9, 2012 at 4:48 AM, Marek Majkowski <span dir="ltr"><<a href="mailto:majek04@gmail.com">majek04@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Mar 8, 2012 at 23:51, Glen Wagley <<a href="mailto:glen.wagley@gmail.com">glen.wagley@gmail.com</a>> wrote:<br>
> I'm experimenting with rabbitmq to replace our current message queuing<br>
> implementation. Currently our test system is comprised of a REST web<br>
> service, a 3-node rabbitmq cluster, and a windows service. The REST service<br>
> acts as a front-end for our clients to send data to which then gets<br>
> published from the REST service to our rabbitmq cluster. The windows service<br>
> has multiple subscriber threads that consume the messages from the cluster<br>
> and do things like insert data from the message into a relational database,<br>
> send an email containing the message contents, etc.<br>
><br>
> Right now I am trying to figure out if I am limiting throughput to the<br>
> cluster because each instance of the REST service and each instance of the<br>
> windows service only has one connection to the cluster BUT multiple<br>
> channels. We support about two dozen message types right now and I've<br>
> created a channel for each one. Some channels have a lot of messages flowing<br>
> through while some have little to none depending on the day. Is there a<br>
> recommended approach to number of connections vs channels? We are starting<br>
> to load test the system and I am trying to understand what could be tweaked<br>
> to improve performance/throughput. Thanks.<br>
<br>
</div></div>Glen,<br>
<br>
There aren't any specific guidelines about connections vs channels.<br>
Depending on the application, it may be more convenient to use<br>
multiple connections or channels. Use what is more convenient.<br>
<br>
Of course, if possible you should reduce number of<br>
connections - connections consume constrained resources<br>
(file descriptors).<br>
<br>
<br>
Having said that there is one particular case when you could<br>
benefit from having multiple connections.<br>
<br>
In a situation when RabbitMQ runs of memory (high memory<br>
watermark), it will stop accepting new messages. But due to the<br>
limitations of AMQP protocol, it can't �be done on per-channel<br>
basis - a full connection will be stopped in such case.<br>
<br>
To rephrase - when rabbit runs out of memory the connections<br>
on which messages are being published will be temporarily<br>
throttled. You won't be able to do anything on that connection<br>
until rabbit recovers - that includes consuming messages.<br>
<br>
So, if you wish to be shielded against this situation, you<br>
may want to keep publishers on a separate connection<br>
than consumers. That will ensure that even in the<br>
out-of-memory case the consumers will be able to do their<br>
job (and thus help rabbitmq free memory faster)<br>
<br>
Hope that helps,<br>
�Marek<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Glen Wagley <<a href="mailto:glen.wagley@gmail.com">glen.wagley@gmail.com</a>><br>