[rabbitmq-discuss] Occasional slow message on a local machine

[Brennan Sellner]

On 09/06/2012 05:28 AM, Matthias Radestock wrote:
> On 06/09/12 10:21, Tim Watson wrote:
>> On 6 Sep 2012, at 10:16, Matthias Radestock wrote:
>>> Creation/deletion of durable queues/exchanges/bindings *does* touch
>>> the disk. With an fsync to boot.

We may have a winner...  It turns out that the exchange is durable,
though the queues being created and bound are not.  Our wrapper around
librabbitmq-c is setting all exchanges to durable; I had (mistakenly)
assumed that the queue's durability must match the exchange's.  From
re-reading http://www.rabbitmq.com/tutorials/amqp-concepts.html, it
looks like a durable queue may only bind to durable exchanges, but a
non-durable queue is free to bind to durable and non-durable exchanges.

My apologies for leading anyone astray.

So, a new set of questions:

Which of the following causes Rabbit to touch disk (and possibly fsync)?
  - Redeclaring an existing durable exchange
  - Binding a non-durable queue to a durable exchange

>> amqp_consume
> 
> no.

If binding a non-durable queue to a durable exchange causes disk access,
a possible explanation for the slow amqp_consume call is that the
immediately preceding amqp_queue_bind is at fault.  Does Rabbit hit the
disk synchronously before sending the bind-ok method, or is it possible
the disk access could affect later calls?

Depending on the answers to the above, a potential explanation for the
observed behavior could be:

amqp_exchange_declare
  - Durable, but being redeclared in all of the problem cases
  - May cause delayed fsync
amqp_queue_declare # Sometimes slow
  - Non-durable
  - Sometimes slowed by the fsync from exchange_declare
amqp_queue_bind    # Sometimes slow
  - Binding non-durable queue to durable exchange
  - May cause synchronous or delayed fsync
  - If fsync occurs before bind-ok is sent, we attribute the delay
    to queue_bind
amqp_basic_consume # Sometimes slow
  - If queue_bind's fsync is delayed, we attribute it to basic_consume

We can certainly change the durability of the exchange if it's at fault,
but I'd like to understand the system's behavior first. :-)

Thanks,

-Brennan