Thanks for the reply.<div><br></div><div>By intermittent, I mean burst, pause, burst, pause, ...</div><div><br></div><div>The problem has been 'solved' for now. We were using basic_get and 96 consumers was too much even with a 1 second delay on no-data-received (we're swapping over to callbacks ASAP). I reduced the number of consumers to 32 and got much better throughput, so the queue is keeping up now.</div>
<div><br></div><div>...Ken</div><div><br><br><div class="gmail_quote">On Tue, May 8, 2012 at 5:47 AM, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Kenneth,<br>
<div class="im"><br>
On 07/05/12 20:10, Kenneth Loafman wrote:<br>
> I've got a fanout exchange running two queues. One queue is responding<br>
> very quickly like normal, the other is intermittent. What would cause<br>
> this? The fast queue has 3 consumers, the slow queue has 64 consumers.<br>
> Is there a limit to how many consumers can be attached to a queue?<br>
<br>
</div>If you say the queue is responding intermittently, what do you mean<br>
exactly? Are you measuring latency between publish and deliver, or<br>
something else?<br>
<br>
The broker does not impose a fixed limit on the number of subscribers to<br>
a queue, but the server capacity may be a limit.<br>
<br>
It is possible that the problem is caused by some behaviour of the<br>
clients, or a difference in pre-fetch count. Do you get more comparable<br>
performance if you set the pre-fetch count to 3 on the "intermittent" queue?<br>
<br>
Depending on what you are measuring you may wish to enable the firehose<br>
tracer for debugging:<br>
<br>
<a href="http://www.rabbitmq.com/firehose.html" target="_blank">http://www.rabbitmq.com/firehose.html</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-Emile<br>
<br>
<br>
</font></span></blockquote></div><br></div>