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.l...@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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
