[rabbitmq-discuss] Performance degrades with increasing queue depth
aisha.fenton at gmail.com
Tue Sep 8 22:46:50 BST 2009
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.
The article also suggests a workaround. Use MQ.prefetch(1)
On 9/09/2009, at 2:01 AM, Chuck Remes wrote:
> Aisha is mistaken. The ruby amqp library does not use libevent
> anywhere. It uses EventMachine under the covers which is a home-
> grown reactor written in C that uses select, poll and kqueue
> depending on the platform.
> On Sep 8, 2009, at 8:33 AM, Ben Hood wrote:
>> Not wanting to hijack this thread another time, but....
>> On Mon, Sep 7, 2009 at 10:44 PM, Aisha
>> Fenton<aisha.fenton at gmail.com> wrote:
>>> The library I'm using (http://github.com/celldee/bunny/tree/
>>> master) is
>>> synchronous only. I'm considering switching to (http://github.com/tmm1/amqp/tree/master
>>> ) which is async and uses libevent. However, I've read that there
>>> problems with msg acknowledges in apps that use libevent, because
>>> OS can buffer the ack responses. And although I'm not using ack
>>> yet, I
>>> want to in my production system.
>> 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
>> point it time when the AMQP frame is actually written to the socket?
More information about the rabbitmq-discuss