You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Toralf Lund <to...@pgs.com> on 2013/11/27 15:25:44 UTC
QPid 0.14 messaging times
Hi.
I'm testing pretty standard (I think) request-response type setup for
communication between two processes, using QPid 0.14 (AMQP 0.10).
Messaging is implemented via a the C++ Messaging API, and the broker is
qpidd from qpid-cpp-server. All running under CentOS 6.4. Messages are
typically quite small - contents are often just 2-3 bytes, but there are
couple of headers as well.
Question: What sort of transfer times should I expect for my setup? When
testing with all processes on the same machine, and a broker used
exclusively for this purpose, I get a round-trip time of up to 80 ms, or
slightly more, which is a bit longer than I expected. Furthermore,
closer inspection seems to reveal that I get either of the following 4
scenarios:
1. (Worst case) The request message takes around 40 ms to reach the
"server", and the response 40 ms to get back to the client - for a
total time of around 80 ms.
2. The request message takes around 40 ms, but the response is very
fast, perhaps the transfer time is 1 ms or so. So the total time is
40 ms or so.
3. As above, only the other way around (fast request, slower response.)
4. The request and response are both very fast, giving nearly
instantaneous feedback.
2 and 3 are the most common of these.
So, is this as expected, or should I expect faster transfers? Where
might the 40 ms come from?
I suppose I should provide some code here, but it will take a while to
prepare, so I thought I might ask some general questions first...
As for QPid version, I'm using 0.14 simply because it seems to be the
most recent available on standard software depositories for the system,
but upgrading to a more recent release may of course be an option.
Thanks,
- Toralf
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
Re: QPid 0.14 messaging times
Posted by Toralf Lund <to...@pgs.com>.
On 27/11/13 15:37, Steve Huston wrote:
> This is a bit of a SWAG but you may be seeing effects of Nagle's algorithm.
I think you may be right.
> I believe the default for --tcp-nodelay changed to "on" sometime after your version. You may want to try that on both the client and broker side.
I've added setOption("tcp_nodelay", true) to my connections, and it
quite definitely helps. It seems like I consistently get response times
of 1-2 ms in my test setup, now. Whether I pass "--tcp-nodelay" to qpidd
or not may not make a lot of difference, though.
I now vaguely remember reading about this option in the past, but I'd
quite forgotten about it until you mentioned it...
Thanks,
- Toralf
>
> -Steve
>
>> -----Original Message-----
>> From: Toralf Lund [mailto:toralf.lund@pgs.com]
>> Sent: Wednesday, November 27, 2013 9:26 AM
>> To: users@qpid.apache.org
>> Subject: QPid 0.14 messaging times
>>
>> Hi.
>>
>> I'm testing pretty standard (I think) request-response type setup for
>> communication between two processes, using QPid 0.14 (AMQP 0.10).
>> Messaging is implemented via a the C++ Messaging API, and the broker is
>> qpidd from qpid-cpp-server. All running under CentOS 6.4. Messages are
>> typically quite small - contents are often just 2-3 bytes, but there are couple
>> of headers as well.
>>
>> Question: What sort of transfer times should I expect for my setup? When
>> testing with all processes on the same machine, and a broker used
>> exclusively for this purpose, I get a round-trip time of up to 80 ms, or slightly
>> more, which is a bit longer than I expected. Furthermore, closer inspection
>> seems to reveal that I get either of the following 4
>> scenarios:
>>
>> 1. (Worst case) The request message takes around 40 ms to reach the
>> "server", and the response 40 ms to get back to the client - for a
>> total time of around 80 ms.
>> 2. The request message takes around 40 ms, but the response is very
>> fast, perhaps the transfer time is 1 ms or so. So the total time is
>> 40 ms or so.
>> 3. As above, only the other way around (fast request, slower response.) 4.
>> The request and response are both very fast, giving nearly
>> instantaneous feedback.
>>
>> 2 and 3 are the most common of these.
>>
>> So, is this as expected, or should I expect faster transfers? Where might the
>> 40 ms come from?
>>
>> I suppose I should provide some code here, but it will take a while to
>> prepare, so I thought I might ask some general questions first...
>>
>> As for QPid version, I'm using 0.14 simply because it seems to be the most
>> recent available on standard software depositories for the system, but
>> upgrading to a more recent release may of course be an option.
>>
>> Thanks,
>>
>>
>> - Toralf
>>
>>
>> This e-mail, including any attachments and response string, may contain
>> proprietary information which is confidential and may be legally privileged. It
>> is for the intended recipient only. If you are not the intended recipient or
>> transmission error has misdirected this e-mail, please notify the author by
>> return e-mail and delete this message and any attachment immediately. If
>> you are not the intended recipient you must not use, disclose, distribute,
>> forward, copy, print or rely on this e-mail in any way except as permitted by
>> the author.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: QPid 0.14 messaging times
Posted by Steve Huston <sh...@riverace.com>.
This is a bit of a SWAG but you may be seeing effects of Nagle's algorithm. I believe the default for --tcp-nodelay changed to "on" sometime after your version. You may want to try that on both the client and broker side.
-Steve
> -----Original Message-----
> From: Toralf Lund [mailto:toralf.lund@pgs.com]
> Sent: Wednesday, November 27, 2013 9:26 AM
> To: users@qpid.apache.org
> Subject: QPid 0.14 messaging times
>
> Hi.
>
> I'm testing pretty standard (I think) request-response type setup for
> communication between two processes, using QPid 0.14 (AMQP 0.10).
> Messaging is implemented via a the C++ Messaging API, and the broker is
> qpidd from qpid-cpp-server. All running under CentOS 6.4. Messages are
> typically quite small - contents are often just 2-3 bytes, but there are couple
> of headers as well.
>
> Question: What sort of transfer times should I expect for my setup? When
> testing with all processes on the same machine, and a broker used
> exclusively for this purpose, I get a round-trip time of up to 80 ms, or slightly
> more, which is a bit longer than I expected. Furthermore, closer inspection
> seems to reveal that I get either of the following 4
> scenarios:
>
> 1. (Worst case) The request message takes around 40 ms to reach the
> "server", and the response 40 ms to get back to the client - for a
> total time of around 80 ms.
> 2. The request message takes around 40 ms, but the response is very
> fast, perhaps the transfer time is 1 ms or so. So the total time is
> 40 ms or so.
> 3. As above, only the other way around (fast request, slower response.) 4.
> The request and response are both very fast, giving nearly
> instantaneous feedback.
>
> 2 and 3 are the most common of these.
>
> So, is this as expected, or should I expect faster transfers? Where might the
> 40 ms come from?
>
> I suppose I should provide some code here, but it will take a while to
> prepare, so I thought I might ask some general questions first...
>
> As for QPid version, I'm using 0.14 simply because it seems to be the most
> recent available on standard software depositories for the system, but
> upgrading to a more recent release may of course be an option.
>
> Thanks,
>
>
> - Toralf
>
>
> This e-mail, including any attachments and response string, may contain
> proprietary information which is confidential and may be legally privileged. It
> is for the intended recipient only. If you are not the intended recipient or
> transmission error has misdirected this e-mail, please notify the author by
> return e-mail and delete this message and any attachment immediately. If
> you are not the intended recipient you must not use, disclose, distribute,
> forward, copy, print or rely on this e-mail in any way except as permitted by
> the author.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org