Simon,<div>Thanks for the information. I expected that a lot of this would depend on my particular implementation and that some of these things would become apparent as we apply load to the system. The facts you have provided me are excellent and will help shape the system moving forward. Thanks! Off to do more testing...<br>
<br><div class="gmail_quote">On Fri, Mar 9, 2012 at 4:57 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com">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">
<div class="im">On 08/03/12 23:51, Glen Wagley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
the 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<br>
flowing through while some have little to none depending on the day. Is<br>
there a recommended approach to number of connections vs channels? We<br>
are starting to load test the system and I am trying to understand what<br>
could be tweaked to improve performance/throughput. Thanks.<br>
</blockquote>
<br></div>
To some extent the answer is "do your own tests", but to get you thinking in the right direction, here are some pertinent facts:<br>
<br>
* Starting a new channel on an existing connection involves one network round trip - starting a new connection takes several.<br>
<br>
* Each connection uses a file descriptor on the server. Channels don't.<br>
<br>
* Publishing a large message on one channel will block a connection while it goes out. Other than that, the multiplexing is fairly transparent.<br>
<br>
* Connections which are publishing can get blocked if the server is overloaded - it's a good idea to separate publishing and consuming connections.<br>
<br>
* There is only one AMQP parser process per connection. Therefore if you have less connections than CPU cores, and are CPU bound in AMQP parsing, you might not make full use of your server. This is generally pretty rare but sounds like it may apply to you.<br>
<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></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>
</div>