<div dir="ltr">Hi Matthias,<div><div><br></div><div>Thanks for your reply. Sorry didn't answered before, I was on vacation.</div><div>Maybe it is client issue (.Net) but moving publishing to separate thread with blocking queue interface helped a lot.</div>
<div><br></div><div>Regards,�</div><div>� �Pavel</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 31, 2013 at 9:21 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">Pavel,<div class="im"><br>
<br>
On 31/07/13 23:16, Pavel Kogan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However publishing response in line with processing slows the things as<br>
network latency is considerable (even though it is internal 1Gbit<br>
network).<br>
</blockquote>
<br></div>
Publishing is an asynchronous operation and therefore should not be affected by latency.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
The question is about receiving overhead. Is there any pre-caching of<br></div>
messages [...]?<br>
</blockquote>
<br>
By default there is an infinite prefetch, i.e. the broker will send messages to the client as fast as network speed & server processing permits. The number of messages "in flight" that way, more precisely, the number of messages that have been sent to the client but not yet acknowledged, can be bounded with the basic.qos prefetch setting. See the section of "Fair dispatch" in Tutorial #2 (<a href="http://www.rabbitmq.com/tutorials/tutorial-two-python.html" target="_blank">http://www.rabbitmq.com/<u></u>tutorials/tutorial-two-python.<u></u>html</a>).<span class="HOEnZb"><font color="#888888"><br>
<br>
Matthias.<br>
</font></span></blockquote></div><br></div>