[rabbitmq-discuss] Per-Connection Flow Control -- The Case Against

[Simon MacMullen]

On 30/05/12 06:52, Chip Salzenberg wrote:
> On Fri, May 25, 2012 at 5:12 AM, Simon MacMullen <simon at rabbitmq.com
> <mailto:simon at rabbitmq.com>> wrote:
>
>     In the mean time, I wonder whether 500 consumers and prefetch-count
>     of 2 is what you really want. Normally I would expect a
>     configuration like that when you expect to take some time to process
>     each message, but it sounds like you're going fast enough that
>     either 500 consumers are not needed, or prefetch-count > 2 might
>     lead to better performance.
>
>
> I didn't know that a larger prefetch count could reduce broker workload.
>   Per-message processing in this system is sometimes high (up to 20s),
> but it averages very low.  It's likely that 500 is overkill, but
> probably only by 2x or so.
>
> Assuming a constant throughput of about 6K/sec and at least 250 workers,
> what prefetch seems more helpful, IYO?  10?  20?

Well, there are two different things here that I somewhat conflated:

* Number of consumers using prefetch count
   - The higher this number, the more bookkeeping work the queue has
     to do.

* Size of prefetch count
   - The lower this number, the more likely that any given consumer will
     stall, and thus the slower consuming goes.

The "ideal" prefetch count is (network latency / average time to process 
each message). Lower than that and consumers will process all their 
messages, ack them, and then have to wait for more messages to arrive 
over the network.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware