[rabbitmq-discuss] Performance degrades with increasing queue depth

[Ben Hood]

Aisha,

On Tue, Sep 8, 2009 at 10:46 PM, Aisha Fenton<aisha.fenton at gmail.com> wrote:
> Sorry meant to say EventMachine, not libevent.
>
>> I am interested as to what the specific issue is with sending acks
>> with libevent - are you saying that the app can issue an ack and this
>> can potentially go AWOL between the the libevent API returning and the
>> point it time when the AMQP frame is actually written to the socket?
>
>
> This article sums it up well. I haven't investigated this myself though, so
> only going on a other peoples comments.
> http://pivotallabs.com/users/jpalermo/blog/articles/952-rabbitmq-amqp-gem-and-eventmachine
>
> The article also suggests a workaround. Use MQ.prefetch(1)

If you need more explicit flow control, then using the AMQP basic.qos
command is the way to go. I presume that MQ.prefetch in tmm1-amqp
wraps this. This command allows a consumer to choose a prefetch window
that specifies the amount of unacknowledged messages it is prepared to
receive. By setting the prefetch count to a non-zero value, the broker
will not deliver any messages to the consumer that would breach that
limit. To move the window forwards, the consumer has to acknowledge
the receipt of a message (or a group of messages). By acknowledging a
message, the consumer gains credit in the broker which makes it
eligible to receive more messages.

Ben