[rabbitmq-discuss] Question on RabbitMQ and file I/O characteristics

[Matt Pietrek]

Sorry for coming back to this thread so much after your reply - Was off on
vacation for a week.

> But your ping-pong test is doing the same thing! If it can't send another
message until the previous one has been received, we can't coalesce
together two writes.

Understood - Back to the original question, in this scenario would you
expect each written message to cause approximately four disk writes?
Naively, I'd expect it to be closer to two or three writes.

It's fine if so - I just want to ensure that our experimental data matches
up with your expert opinion on what should be happening.

Thanks much,

Matt





On Wed, Aug 7, 2013 at 3:22 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 06/08/13 18:42, Matt Pietrek wrote:
>
>> The net effect is that messages 'ping-pong' between the two ioloop
>> threads as fast as possible. In the 'main' ioloop init, it sends an
>> initial message to kick things off.
>>
>
> <snip>
>
>
>  I also have a global switch (USE_TRANSACTIONS) that lets me switch
>> between using transactions and not. When set, it adds tx_select() when
>> opening the channels and tx_commit after publishing messages. For the
>> tests I was running, I wasn't using transactions. If I do run with
>> transactions the numbers are very similar (surprising I know, but I
>> stepped through the code to verify that the tx_xxx calls are only made
>> when I intend them to be.)
>>
>
> Ah, I see. The thing is that transactions are quite lightweight in and of
> themselves, the reason they tend to slow things down is they form a barrier
> across which we can't coalesce writes / have to wait for a synchronous
> network round trip.
>
> But your ping-pong test is doing the same thing! If it can't send another
> message until the previous one has been received, we can't coalesce
> together two writes. And it also ensures there's only one message on the
> wire at once.
>
> Cheers, Simon
>
>
> --
> Simon MacMullen
> RabbitMQ, Pivotal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130815/2cd00ad6/attachment.htm>