<div dir="ltr">That makes sense. I hadn't considered the overhead of the protocol handling vs. the cost of internode message transfer. Thank you (again) for your assistance.<div><br></div><div>Regards,</div><div><br></div>
<div>Richard</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 19, 2013 at 3:35 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Richard,<br>
<br>
On 18/03/13 18:06, Richard Raseley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you for that information - I hadn't realized that was the case<br>
with HA queues. So, in our situation we may be better off configuring<br>
the load balanced pool to be Active / Passive so that messages will<br>
always be flowing directly to the node that is running the master queue<br>
process (thereby eliminating the intra-node network overhead)?<br>
</blockquote>
<br>
Probably, but not necessarily. Queues aren't the only entities performing work. In particular the entire protocol handling, both inbound and outbound, also takes a fair chunk of effort. And system resources (memory, sockets). So while getting publishers and consumers to connect to the 'home' node of a queue (*) saves an internode message transfer, it does put more load on that node.<br>
<br>
(*) if that is possible; in general a published message may get routed to several queues, which may not all have the same home node.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Matthias.<br>
</font></span></blockquote></div><br></div>