You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by WJCarpenter <bi...@carpenter.org> on 2002/07/26 00:43:05 UTC
setTcpNoDelay; why not true by default?
It's very nice indeed that SOAP 2.3 has direct API support for setting
the TcpNoDelay option. It seems curious to me, though, that it's not
defaulted to true (which, in the strange lingo of this option, means
"yes, I want no delay"). I don't imagine any SOAP calls would ever
benefit from having the Nagle algorithm delay.
Shouldn't we just default it to true instead of depending on callers to
be wise enough to do it on their own? Just like in the stock market,
where theinsiders will always have better performance than people like me, Apache
SOAP insiders will know to call SOAPHttpConnection.setTcpNoDelay(BooleanTRUE)
and have better performance than the unwashed.
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
> I wrote that paper, but suggested they put the change in Apache SOAP
(We love that paper around here. RPC latency discussions are all the
rage here, in our drab wretched lives. :-)
A couple of days (late March) before your TcpNoDelay patch was posted on this
mailing list, we had locally found a different "fix" to the 200 ms delay.
Instead of setting TcpNoDelay, we instead called shutDownOutput on the
socket. For various fairly obvious reasons, setting TcpNoDelay is a
better performance fix, so thanks for it!
When I measured the result of using either fix by itself, I got about the
same numbers. If I used them both together, I only got about 90% of
the improvement I got if I used either individually. I didn't pursue
an explanation.
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
> I wrote that paper, but suggested they put the change in Apache SOAP
(We love that paper around here. RPC latency discussions are all the
rage here, in our drab wretched lives. :-)
A couple of days (late March) before your TcpNoDelay patch was posted on this
mailing list, we had locally found a different "fix" to the 200 ms delay.
Instead of setting TcpNoDelay, we instead called shutDownOutput on the
socket. For various fairly obvious reasons, setting TcpNoDelay is a
better performance fix, so thanks for it!
When I measured the result of using either fix by itself, I got about the
same numbers. If I used them both together, I only got about 90% of
the improvement I got if I used either individually. I didn't pursue
an explanation.
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Dan Davis <da...@caip.rutgers.edu>.
Thanks, Scott. You understand what I've been trying to say.
Re: setTcpNoDelay; why not true by default?
Posted by Dan Davis <da...@caip.rutgers.edu>.
Thanks, Scott. You understand what I've been trying to say.
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
OK, I've now confirmed that on a Windows 2000 server, there is a delayed
ACK, so disabling Nagle on the client makes a difference. The error in my
testing was that I was sending large payloads. With large payloads, the
client has a full TCP segment (1460 bytes for Ethernet) to send after the
HTTP header. The Nagle delay waiting for the ACK applies only when there is
not a full segment; a full segment is sent without the ACK. The server side
disables delayed ACK when receiving a series of full segments, so the last
(partial segment) packet can be sent from the client in a timely manner
since it receives the ACK for the previous packet right away.
Anyway, for the small payload test, the server configuration was
Server 3
--------
Windows 2000 SP1
AMD K6-III 450 MHz
256 MB PC100 SDRAM
Sun JVM 1.3.1-b24
Tomcat 4.0.1
Using client 2, I captured the following with the Windows 2000 Network
Monitor utility (note: the timer resolution used by this tool is clearly > 1
us).
*** Nagle enabled on client ***
time offset at server
---------------------
6.269015 SYN received
6.269015 SYN/ACK sent
6.269015 ACK received
6.279029 HTTP header received
6.419231 ACK sent
6.419231 payload received
6.439260 HTTP header/ACK sent
6.439260 payload/ACK sent
6.449274 FIN/ACK sent
6.449274 ACK received
6.449274 ACK received
6.479317 FIN/ACK received
6.479317 ACK sent
*** Nagle disabled on client ***
time offset at server
---------------------
7.560872 SYN received
7.560872 SYN/ACK sent
7.560872 ACK received
7.570886 HTTP header received
7.570886 payload received
7.570886 ACK sent
7.600929 HTTP header sent
7.600929 payload sent
7.600929 ACK received
7.610944 FIN/ACK sent
7.610944 ACK received
7.630972 FIN/ACK received
7.630972 ACK sent
Scott Nichol
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Monday, July 29, 2002 5:15 PM
Subject: Re: setTcpNoDelay; why not true by default?
> Thanks for the link.
>
> I have dusted off my old test code and checked it into CVS under
> samples/stringarray. The code itself is nothing out of the ordinary. It
> was my intention to use this code to test the affect of tcpNoDelay,
> outputBufferSize and XML DocumentBuilder v. Transform. To my great
> surprise, I am seeing *no* difference in performance related to different
> settings for tcpNoDelay and outputBufferSize. I have following this up by
> using tcpdump to capture network traffic, and I am seeing no Nagle-related
> delays, apparently because the server is not doing a 200 ms delayed ACK.
>
> I started testing with the following configuration:
>
> * SOAP always built from current sources
> * 100 Mbps switched network
>
> Client 1
> --------
> Windows 2000 SP1
> AMD K6-III 450 MHz
> 256 MB PC100 SDRAM
> Sun JVM 1.3.1-b24
>
> Server 1
> --------
> Red Hat 7.3
> AMD Athlon 1.2 GHz
> 256 MB PC2100 DDR
> IBM JVM 1.3.1 classic
> Tomcat 4.0.3
>
> I repeated the tests with the following client #2 to server #1, then
client
> #2 to server #2
>
> Client 2
> --------
> Windows 98 SE w/DUN 1.4
> Intel Celeron 366 MHz
> 192 MB SODIMM
> Sun JVM 1.3.1-b24
>
> Server 2
> --------
> Windows NT 4 SP 6
> AMD K6-III 450 MHz
> 256 MB PC100 SDRAM
> Sun JVM 1.2.2_006 symcjit
> Tomcat 4.0.1
>
> In all cases, client performance (average RPC roundtrip time) shows no
> significant difference between when Nagle is enabled and when it is
> disabled.
>
> I have not looked at any dumps with the NT server (no easy way for me to
> capture the packets on my switched network), but here is a synopsis of an
> RPC with Nagle enabled on the client when hitting the Linux-based server.
>
> time at server
> 16:59:56.283386 SYN received
> 16:59:56.283461 ACK sent
> 16:59:56.283797 ACK received
> 16:59:56.302040 HTTP header received
> 16:59:56.302072 ACK sent
> 16:59:56.303047 payload received
> 16:59:56.303099 ACK sent
> 16:59:56.305286 HTTP header sent
> 16:59:56.305312 payload sent
> 16:59:56.305571 FIN sent
> 16:59:56.306480 ACK received
> 16:59:56.330867 FIN received
> 16:59:56.330892 ACK sent
>
> As you can see, there is no delayed ACK on the server (unless 32
> microseconds counts as a delay), so the payload is received about 1 ms
after
> the HTTP header.
>
> I will continue testing and analyzing other configurations, but I wanted
to
> let other know the behavior I am seeing. If anyone else can run similar
> tests, that would be great.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "WJCarpenter" <bi...@carpenter.org>
> To: <so...@xml.apache.org>
> Sent: Friday, July 26, 2002 3:33 PM
> Subject: Re: setTcpNoDelay; why not true by default?
>
>
> > There is a pretty good discussion of this stuff, specifically regarding
> > Apache SOAP, in the paper "Latency Performance of SOAP Implementations".
> > Here's the URL:
<www.caip.rutgers.edu/TASSL/Papers/p2p-p2pws02-soap.pdf>
> >
> > They do a much nicer job than I can of describing the interaction of
Nagle
> > and TCP delayed ACK.
> > --
> > bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> > 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
OK, I've now confirmed that on a Windows 2000 server, there is a delayed
ACK, so disabling Nagle on the client makes a difference. The error in my
testing was that I was sending large payloads. With large payloads, the
client has a full TCP segment (1460 bytes for Ethernet) to send after the
HTTP header. The Nagle delay waiting for the ACK applies only when there is
not a full segment; a full segment is sent without the ACK. The server side
disables delayed ACK when receiving a series of full segments, so the last
(partial segment) packet can be sent from the client in a timely manner
since it receives the ACK for the previous packet right away.
Anyway, for the small payload test, the server configuration was
Server 3
--------
Windows 2000 SP1
AMD K6-III 450 MHz
256 MB PC100 SDRAM
Sun JVM 1.3.1-b24
Tomcat 4.0.1
Using client 2, I captured the following with the Windows 2000 Network
Monitor utility (note: the timer resolution used by this tool is clearly > 1
us).
*** Nagle enabled on client ***
time offset at server
---------------------
6.269015 SYN received
6.269015 SYN/ACK sent
6.269015 ACK received
6.279029 HTTP header received
6.419231 ACK sent
6.419231 payload received
6.439260 HTTP header/ACK sent
6.439260 payload/ACK sent
6.449274 FIN/ACK sent
6.449274 ACK received
6.449274 ACK received
6.479317 FIN/ACK received
6.479317 ACK sent
*** Nagle disabled on client ***
time offset at server
---------------------
7.560872 SYN received
7.560872 SYN/ACK sent
7.560872 ACK received
7.570886 HTTP header received
7.570886 payload received
7.570886 ACK sent
7.600929 HTTP header sent
7.600929 payload sent
7.600929 ACK received
7.610944 FIN/ACK sent
7.610944 ACK received
7.630972 FIN/ACK received
7.630972 ACK sent
Scott Nichol
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Monday, July 29, 2002 5:15 PM
Subject: Re: setTcpNoDelay; why not true by default?
> Thanks for the link.
>
> I have dusted off my old test code and checked it into CVS under
> samples/stringarray. The code itself is nothing out of the ordinary. It
> was my intention to use this code to test the affect of tcpNoDelay,
> outputBufferSize and XML DocumentBuilder v. Transform. To my great
> surprise, I am seeing *no* difference in performance related to different
> settings for tcpNoDelay and outputBufferSize. I have following this up by
> using tcpdump to capture network traffic, and I am seeing no Nagle-related
> delays, apparently because the server is not doing a 200 ms delayed ACK.
>
> I started testing with the following configuration:
>
> * SOAP always built from current sources
> * 100 Mbps switched network
>
> Client 1
> --------
> Windows 2000 SP1
> AMD K6-III 450 MHz
> 256 MB PC100 SDRAM
> Sun JVM 1.3.1-b24
>
> Server 1
> --------
> Red Hat 7.3
> AMD Athlon 1.2 GHz
> 256 MB PC2100 DDR
> IBM JVM 1.3.1 classic
> Tomcat 4.0.3
>
> I repeated the tests with the following client #2 to server #1, then
client
> #2 to server #2
>
> Client 2
> --------
> Windows 98 SE w/DUN 1.4
> Intel Celeron 366 MHz
> 192 MB SODIMM
> Sun JVM 1.3.1-b24
>
> Server 2
> --------
> Windows NT 4 SP 6
> AMD K6-III 450 MHz
> 256 MB PC100 SDRAM
> Sun JVM 1.2.2_006 symcjit
> Tomcat 4.0.1
>
> In all cases, client performance (average RPC roundtrip time) shows no
> significant difference between when Nagle is enabled and when it is
> disabled.
>
> I have not looked at any dumps with the NT server (no easy way for me to
> capture the packets on my switched network), but here is a synopsis of an
> RPC with Nagle enabled on the client when hitting the Linux-based server.
>
> time at server
> 16:59:56.283386 SYN received
> 16:59:56.283461 ACK sent
> 16:59:56.283797 ACK received
> 16:59:56.302040 HTTP header received
> 16:59:56.302072 ACK sent
> 16:59:56.303047 payload received
> 16:59:56.303099 ACK sent
> 16:59:56.305286 HTTP header sent
> 16:59:56.305312 payload sent
> 16:59:56.305571 FIN sent
> 16:59:56.306480 ACK received
> 16:59:56.330867 FIN received
> 16:59:56.330892 ACK sent
>
> As you can see, there is no delayed ACK on the server (unless 32
> microseconds counts as a delay), so the payload is received about 1 ms
after
> the HTTP header.
>
> I will continue testing and analyzing other configurations, but I wanted
to
> let other know the behavior I am seeing. If anyone else can run similar
> tests, that would be great.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "WJCarpenter" <bi...@carpenter.org>
> To: <so...@xml.apache.org>
> Sent: Friday, July 26, 2002 3:33 PM
> Subject: Re: setTcpNoDelay; why not true by default?
>
>
> > There is a pretty good discussion of this stuff, specifically regarding
> > Apache SOAP, in the paper "Latency Performance of SOAP Implementations".
> > Here's the URL:
<www.caip.rutgers.edu/TASSL/Papers/p2p-p2pws02-soap.pdf>
> >
> > They do a much nicer job than I can of describing the interaction of
Nagle
> > and TCP delayed ACK.
> > --
> > bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> > 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
Thanks for the link.
I have dusted off my old test code and checked it into CVS under
samples/stringarray. The code itself is nothing out of the ordinary. It
was my intention to use this code to test the affect of tcpNoDelay,
outputBufferSize and XML DocumentBuilder v. Transform. To my great
surprise, I am seeing *no* difference in performance related to different
settings for tcpNoDelay and outputBufferSize. I have following this up by
using tcpdump to capture network traffic, and I am seeing no Nagle-related
delays, apparently because the server is not doing a 200 ms delayed ACK.
I started testing with the following configuration:
* SOAP always built from current sources
* 100 Mbps switched network
Client 1
--------
Windows 2000 SP1
AMD K6-III 450 MHz
256 MB PC100 SDRAM
Sun JVM 1.3.1-b24
Server 1
--------
Red Hat 7.3
AMD Athlon 1.2 GHz
256 MB PC2100 DDR
IBM JVM 1.3.1 classic
Tomcat 4.0.3
I repeated the tests with the following client #2 to server #1, then client
#2 to server #2
Client 2
--------
Windows 98 SE w/DUN 1.4
Intel Celeron 366 MHz
192 MB SODIMM
Sun JVM 1.3.1-b24
Server 2
--------
Windows NT 4 SP 6
AMD K6-III 450 MHz
256 MB PC100 SDRAM
Sun JVM 1.2.2_006 symcjit
Tomcat 4.0.1
In all cases, client performance (average RPC roundtrip time) shows no
significant difference between when Nagle is enabled and when it is
disabled.
I have not looked at any dumps with the NT server (no easy way for me to
capture the packets on my switched network), but here is a synopsis of an
RPC with Nagle enabled on the client when hitting the Linux-based server.
time at server
16:59:56.283386 SYN received
16:59:56.283461 ACK sent
16:59:56.283797 ACK received
16:59:56.302040 HTTP header received
16:59:56.302072 ACK sent
16:59:56.303047 payload received
16:59:56.303099 ACK sent
16:59:56.305286 HTTP header sent
16:59:56.305312 payload sent
16:59:56.305571 FIN sent
16:59:56.306480 ACK received
16:59:56.330867 FIN received
16:59:56.330892 ACK sent
As you can see, there is no delayed ACK on the server (unless 32
microseconds counts as a delay), so the payload is received about 1 ms after
the HTTP header.
I will continue testing and analyzing other configurations, but I wanted to
let other know the behavior I am seeing. If anyone else can run similar
tests, that would be great.
Scott Nichol
----- Original Message -----
From: "WJCarpenter" <bi...@carpenter.org>
To: <so...@xml.apache.org>
Sent: Friday, July 26, 2002 3:33 PM
Subject: Re: setTcpNoDelay; why not true by default?
> There is a pretty good discussion of this stuff, specifically regarding
> Apache SOAP, in the paper "Latency Performance of SOAP Implementations".
> Here's the URL: <www.caip.rutgers.edu/TASSL/Papers/p2p-p2pws02-soap.pdf>
>
> They do a much nicer job than I can of describing the interaction of Nagle
> and TCP delayed ACK.
> --
> bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
Thanks for the link.
I have dusted off my old test code and checked it into CVS under
samples/stringarray. The code itself is nothing out of the ordinary. It
was my intention to use this code to test the affect of tcpNoDelay,
outputBufferSize and XML DocumentBuilder v. Transform. To my great
surprise, I am seeing *no* difference in performance related to different
settings for tcpNoDelay and outputBufferSize. I have following this up by
using tcpdump to capture network traffic, and I am seeing no Nagle-related
delays, apparently because the server is not doing a 200 ms delayed ACK.
I started testing with the following configuration:
* SOAP always built from current sources
* 100 Mbps switched network
Client 1
--------
Windows 2000 SP1
AMD K6-III 450 MHz
256 MB PC100 SDRAM
Sun JVM 1.3.1-b24
Server 1
--------
Red Hat 7.3
AMD Athlon 1.2 GHz
256 MB PC2100 DDR
IBM JVM 1.3.1 classic
Tomcat 4.0.3
I repeated the tests with the following client #2 to server #1, then client
#2 to server #2
Client 2
--------
Windows 98 SE w/DUN 1.4
Intel Celeron 366 MHz
192 MB SODIMM
Sun JVM 1.3.1-b24
Server 2
--------
Windows NT 4 SP 6
AMD K6-III 450 MHz
256 MB PC100 SDRAM
Sun JVM 1.2.2_006 symcjit
Tomcat 4.0.1
In all cases, client performance (average RPC roundtrip time) shows no
significant difference between when Nagle is enabled and when it is
disabled.
I have not looked at any dumps with the NT server (no easy way for me to
capture the packets on my switched network), but here is a synopsis of an
RPC with Nagle enabled on the client when hitting the Linux-based server.
time at server
16:59:56.283386 SYN received
16:59:56.283461 ACK sent
16:59:56.283797 ACK received
16:59:56.302040 HTTP header received
16:59:56.302072 ACK sent
16:59:56.303047 payload received
16:59:56.303099 ACK sent
16:59:56.305286 HTTP header sent
16:59:56.305312 payload sent
16:59:56.305571 FIN sent
16:59:56.306480 ACK received
16:59:56.330867 FIN received
16:59:56.330892 ACK sent
As you can see, there is no delayed ACK on the server (unless 32
microseconds counts as a delay), so the payload is received about 1 ms after
the HTTP header.
I will continue testing and analyzing other configurations, but I wanted to
let other know the behavior I am seeing. If anyone else can run similar
tests, that would be great.
Scott Nichol
----- Original Message -----
From: "WJCarpenter" <bi...@carpenter.org>
To: <so...@xml.apache.org>
Sent: Friday, July 26, 2002 3:33 PM
Subject: Re: setTcpNoDelay; why not true by default?
> There is a pretty good discussion of this stuff, specifically regarding
> Apache SOAP, in the paper "Latency Performance of SOAP Implementations".
> Here's the URL: <www.caip.rutgers.edu/TASSL/Papers/p2p-p2pws02-soap.pdf>
>
> They do a much nicer job than I can of describing the interaction of Nagle
> and TCP delayed ACK.
> --
> bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Dan Davis <da...@caip.rutgers.edu>.
Thanks, WJCarpenter,
I wrote that paper, but suggested they put the change in Apache SOAP 2.3
very late in the release period. Scott was very kind to put the change
in and trust me even though I'm not an active committer.
******************************
If I don't get back to you promptly, I'm probably working on my thesis
or riding my bicycle. Thanks for your patience.
******************************
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Dan Davis <da...@caip.rutgers.edu>.
Thanks, WJCarpenter,
I wrote that paper, but suggested they put the change in Apache SOAP 2.3
very late in the release period. Scott was very kind to put the change
in and trust me even though I'm not an active committer.
******************************
If I don't get back to you promptly, I'm probably working on my thesis
or riding my bicycle. Thanks for your patience.
******************************
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
There is a pretty good discussion of this stuff, specifically regarding
Apache SOAP, in the paper "Latency Performance of SOAP Implementations".
Here's the URL: <www.caip.rutgers.edu/TASSL/Papers/p2p-p2pws02-soap.pdf>
They do a much nicer job than I can of describing the interaction of Nagle
and TCP delayed ACK.
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
There is a pretty good discussion of this stuff, specifically regarding
Apache SOAP, in the paper "Latency Performance of SOAP Implementations".
Here's the URL: <www.caip.rutgers.edu/TASSL/Papers/p2p-p2pws02-soap.pdf>
They do a much nicer job than I can of describing the interaction of Nagle
and TCP delayed ACK.
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Re: setTcpNoDelay; why not true by default?
Posted by Dan Davis <da...@caip.rutgers.edu>.
It's about 200 ms on Windows 2000 Server, Linux, and Tru64 UNIX.
I believe TcpNoDelay should be true by default. While the Nagle algorithm
was originally designed to reduce 1-byte payloads, this was in the era of
single LANs, not of switched-networks and over-provisioning.
We should be so lucky to cause congestion via SOAP -- the causes of
congestion will likely be streaming media applications that use a TCP
connection per client; if web services catch on this much (and it's Apache
SOAP and not .NET), we'd all be very happy.
>
> Oops, I spoke too soon. The Nagle algorithm will only accumulate packets
> and wait for the ACK while it has a packet less than the segment size. For
> large payloads, it will keep accumulating segment size packets and sending
> them, so it should suffer the delayed ACK penalty only on the last packet.
>
> Also, I read more about delayed ACK. It is 200 ms at most, not a fixed 200
> ms. The implementation is described as a timer that goes off every 200 ms.
> It is not a 200 ms timer started with the packet is received.
>
> Scott Nichol
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Dan Davis <da...@caip.rutgers.edu>.
It's about 200 ms on Windows 2000 Server, Linux, and Tru64 UNIX.
I believe TcpNoDelay should be true by default. While the Nagle algorithm
was originally designed to reduce 1-byte payloads, this was in the era of
single LANs, not of switched-networks and over-provisioning.
We should be so lucky to cause congestion via SOAP -- the causes of
congestion will likely be streaming media applications that use a TCP
connection per client; if web services catch on this much (and it's Apache
SOAP and not .NET), we'd all be very happy.
>
> Oops, I spoke too soon. The Nagle algorithm will only accumulate packets
> and wait for the ACK while it has a packet less than the segment size. For
> large payloads, it will keep accumulating segment size packets and sending
> them, so it should suffer the delayed ACK penalty only on the last packet.
>
> Also, I read more about delayed ACK. It is 200 ms at most, not a fixed 200
> ms. The implementation is described as a timer that goes off every 200 ms.
> It is not a 200 ms timer started with the packet is received.
>
> Scott Nichol
>
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
> > > I have also understood that turning on no delay causes more
> > > network traffic. That was partly the reason for leaving it off
> > > by default.
> >
> > That's the idea behind the Nagle algorithm, but in practice it only
> matters
> > for things that resemble interactive typing. The idea is that you get a
> > lot of 1-byte payloads with 41 bytes or so of packet overhead, so the
> Nagle
> > algorithm waits a bit (200 ms) to see if you're going to type more. In
> > the case of a SOAP request, all the payload is ready to go at once, so
> > there is nothing to wait for. Using the Nagle algorithm in this context
> > always inserts the delay and never reduces any network traffic.
>
> I *hate* to be pedantic, but I just whipped out my Stevens "TCP/IP
> Illustrated" to brush up on Nagle. The Nagle algorithm itself accumulates
> segments into a single segment while it is waiting for an ACK. If ACKs
come
> fast enough, segments don't have to be accumulated. The 200 ms enters the
> picture from the server side. The "delayed ACK algorithm" waits 200 ms to
> send the ACK to a packet, so that if the server wants to send data, the
ACK
> can be part of the data packet.
>
> Having read this, it sounds like disabling Nagle should help large
payloads
> as well as small, but the experimental physicist in me still wants to make
> some measurements.
Oops, I spoke too soon. The Nagle algorithm will only accumulate packets
and wait for the ACK while it has a packet less than the segment size. For
large payloads, it will keep accumulating segment size packets and sending
them, so it should suffer the delayed ACK penalty only on the last packet.
Also, I read more about delayed ACK. It is 200 ms at most, not a fixed 200
ms. The implementation is described as a timer that goes off every 200 ms.
It is not a 200 ms timer started with the packet is received.
Scott Nichol
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
> > > I have also understood that turning on no delay causes more
> > > network traffic. That was partly the reason for leaving it off
> > > by default.
> >
> > That's the idea behind the Nagle algorithm, but in practice it only
> matters
> > for things that resemble interactive typing. The idea is that you get a
> > lot of 1-byte payloads with 41 bytes or so of packet overhead, so the
> Nagle
> > algorithm waits a bit (200 ms) to see if you're going to type more. In
> > the case of a SOAP request, all the payload is ready to go at once, so
> > there is nothing to wait for. Using the Nagle algorithm in this context
> > always inserts the delay and never reduces any network traffic.
>
> I *hate* to be pedantic, but I just whipped out my Stevens "TCP/IP
> Illustrated" to brush up on Nagle. The Nagle algorithm itself accumulates
> segments into a single segment while it is waiting for an ACK. If ACKs
come
> fast enough, segments don't have to be accumulated. The 200 ms enters the
> picture from the server side. The "delayed ACK algorithm" waits 200 ms to
> send the ACK to a packet, so that if the server wants to send data, the
ACK
> can be part of the data packet.
>
> Having read this, it sounds like disabling Nagle should help large
payloads
> as well as small, but the experimental physicist in me still wants to make
> some measurements.
Oops, I spoke too soon. The Nagle algorithm will only accumulate packets
and wait for the ACK while it has a packet less than the segment size. For
large payloads, it will keep accumulating segment size packets and sending
them, so it should suffer the delayed ACK penalty only on the last packet.
Also, I read more about delayed ACK. It is 200 ms at most, not a fixed 200
ms. The implementation is described as a timer that goes off every 200 ms.
It is not a 200 ms timer started with the packet is received.
Scott Nichol
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
> > I have also understood that turning on no delay causes more
> > network traffic. That was partly the reason for leaving it off
> > by default.
>
> That's the idea behind the Nagle algorithm, but in practice it only
matters
> for things that resemble interactive typing. The idea is that you get a
> lot of 1-byte payloads with 41 bytes or so of packet overhead, so the
Nagle
> algorithm waits a bit (200 ms) to see if you're going to type more. In
> the case of a SOAP request, all the payload is ready to go at once, so
> there is nothing to wait for. Using the Nagle algorithm in this context
> always inserts the delay and never reduces any network traffic.
I *hate* to be pedantic, but I just whipped out my Stevens "TCP/IP
Illustrated" to brush up on Nagle. The Nagle algorithm itself accumulates
segments into a single segment while it is waiting for an ACK. If ACKs come
fast enough, segments don't have to be accumulated. The 200 ms enters the
picture from the server side. The "delayed ACK algorithm" waits 200 ms to
send the ACK to a packet, so that if the server wants to send data, the ACK
can be part of the data packet.
Having read this, it sounds like disabling Nagle should help large payloads
as well as small, but the experimental physicist in me still wants to make
some measurements.
Scott Nichol
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
> > I have also understood that turning on no delay causes more
> > network traffic. That was partly the reason for leaving it off
> > by default.
>
> That's the idea behind the Nagle algorithm, but in practice it only
matters
> for things that resemble interactive typing. The idea is that you get a
> lot of 1-byte payloads with 41 bytes or so of packet overhead, so the
Nagle
> algorithm waits a bit (200 ms) to see if you're going to type more. In
> the case of a SOAP request, all the payload is ready to go at once, so
> there is nothing to wait for. Using the Nagle algorithm in this context
> always inserts the delay and never reduces any network traffic.
I *hate* to be pedantic, but I just whipped out my Stevens "TCP/IP
Illustrated" to brush up on Nagle. The Nagle algorithm itself accumulates
segments into a single segment while it is waiting for an ACK. If ACKs come
fast enough, segments don't have to be accumulated. The 200 ms enters the
picture from the server side. The "delayed ACK algorithm" waits 200 ms to
send the ACK to a packet, so that if the server wants to send data, the ACK
can be part of the data packet.
Having read this, it sounds like disabling Nagle should help large payloads
as well as small, but the experimental physicist in me still wants to make
some measurements.
Scott Nichol
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
> I have also understood that turning on no delay causes more
> network traffic. That was partly the reason for leaving it off
> by default.
That's the idea behind the Nagle algorithm, but in practice it only matters
for things that resemble interactive typing. The idea is that you get a
lot of 1-byte payloads with 41 bytes or so of packet overhead, so the Nagle
algorithm waits a bit (200 ms) to see if you're going to type more. In
the case of a SOAP request, all the payload is ready to go at once, so
there is nothing to wait for. Using the Nagle algorithm in this context
always inserts the delay and never reduces any network traffic.
PS:- "Nagle" might actually be "Nagel". I can never remember. Sorry,
Mr Nag[le][el]. :-)
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
> I have also understood that turning on no delay causes more
> network traffic. That was partly the reason for leaving it off
> by default.
That's the idea behind the Nagle algorithm, but in practice it only matters
for things that resemble interactive typing. The idea is that you get a
lot of 1-byte payloads with 41 bytes or so of packet overhead, so the Nagle
algorithm waits a bit (200 ms) to see if you're going to type more. In
the case of a SOAP request, all the payload is ready to go at once, so
there is nothing to wait for. Using the Nagle algorithm in this context
always inserts the delay and never reduces any network traffic.
PS:- "Nagle" might actually be "Nagel". I can never remember. Sorry,
Mr Nag[le][el]. :-)
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
I have also understood that turning on no delay causes more
network traffic. That was partly the reason for leaving it off
by default.
I suggest we consider making it default to "on" in the future.
Sanjiva.
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Friday, July 26, 2002 8:01 AM
Subject: Re: setTcpNoDelay; why not true by default?
> The default is simply for backward compatibility. This is like when the
> ability to set the output buffer size was added. The objective was to
> ensure unchanged behavior for users working without the feature,
especially
> given that the feature was virtually untested at the release date, and no
> one have quantitative measurements of the actual benefits.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "WJCarpenter" <bi...@carpenter.org>
> To: <so...@xml.apache.org>
> Sent: Thursday, July 25, 2002 6:43 PM
> Subject: setTcpNoDelay; why not true by default?
>
>
> > It's very nice indeed that SOAP 2.3 has direct API support for setting
> > the TcpNoDelay option. It seems curious to me, though, that it's not
> > defaulted to true (which, in the strange lingo of this option, means
> > "yes, I want no delay"). I don't imagine any SOAP calls would ever
> > benefit from having the Nagle algorithm delay.
> >
> > Shouldn't we just default it to true instead of depending on callers to
> > be wise enough to do it on their own? Just like in the stock market,
> > where theinsiders will always have better performance than people like
me,
> Apache
> > SOAP insiders will know to call
> SOAPHttpConnection.setTcpNoDelay(BooleanTRUE)
> > and have better performance than the unwashed.
> > --
> > bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> > 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
I have also understood that turning on no delay causes more
network traffic. That was partly the reason for leaving it off
by default.
I suggest we consider making it default to "on" in the future.
Sanjiva.
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Friday, July 26, 2002 8:01 AM
Subject: Re: setTcpNoDelay; why not true by default?
> The default is simply for backward compatibility. This is like when the
> ability to set the output buffer size was added. The objective was to
> ensure unchanged behavior for users working without the feature,
especially
> given that the feature was virtually untested at the release date, and no
> one have quantitative measurements of the actual benefits.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "WJCarpenter" <bi...@carpenter.org>
> To: <so...@xml.apache.org>
> Sent: Thursday, July 25, 2002 6:43 PM
> Subject: setTcpNoDelay; why not true by default?
>
>
> > It's very nice indeed that SOAP 2.3 has direct API support for setting
> > the TcpNoDelay option. It seems curious to me, though, that it's not
> > defaulted to true (which, in the strange lingo of this option, means
> > "yes, I want no delay"). I don't imagine any SOAP calls would ever
> > benefit from having the Nagle algorithm delay.
> >
> > Shouldn't we just default it to true instead of depending on callers to
> > be wise enough to do it on their own? Just like in the stock market,
> > where theinsiders will always have better performance than people like
me,
> Apache
> > SOAP insiders will know to call
> SOAPHttpConnection.setTcpNoDelay(BooleanTRUE)
> > and have better performance than the unwashed.
> > --
> > bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> > 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
> It was certainly an extremely cautious decision, perhaps too extreme.
> Still, the timing difference you quote is just one scenario (BTW, is
> this a connect-send-get-disconnect, or an average of multiple send-get
> within a single connect-disconnect?). What about other scenarios, such
I did my tests specifically with Apache SOAP 2.3.1 as a client and
IIS as the server. So, it was connect/send/get/disconnect because
that's all that's available. However, I believe the problem would
also show up mulitple times in a persistent connection trial if there
were delays between the individual SOAP requests. I haven't completely
thought that through, but I'm imagining that after a small delay the
Nagle stuff basically starts over.
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
> It was certainly an extremely cautious decision, perhaps too extreme.
> Still, the timing difference you quote is just one scenario (BTW, is
> this a connect-send-get-disconnect, or an average of multiple send-get
> within a single connect-disconnect?). What about other scenarios, such
I did my tests specifically with Apache SOAP 2.3.1 as a client and
IIS as the server. So, it was connect/send/get/disconnect because
that's all that's available. However, I believe the problem would
also show up mulitple times in a persistent connection trial if there
were delays between the individual SOAP requests. I haven't completely
thought that through, but I'm imagining that after a small delay the
Nagle stuff basically starts over.
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
Bill,
It was certainly an extremely cautious decision, perhaps too extreme.
Still, the timing difference you quote is just one scenario (BTW, is this a
connect-send-get-disconnect, or an average of multiple send-get within a
single connect-disconnect?). What about other scenarios, such as what
appear to be the many people transfering payloads of 100k or several MB?
Perhaps you have enough experience to know what the result will be, but I do
not. It seems like the benefit of sending fewer IP packets might outweigh
the elimination of the delay. I would not want to change the default value
to improve performance when I don't know that I really am improving it for
everyone, or at least being armed with numbers to inform users how they will
be affected. Without actual measurements, I am reluctant to change the
defaults.
This thread has reminded me that I wanted to take an old, relatively simple
performance test I had, spruce it up and add it as a sample, then run it to
measure the effect of changing output buffer size, Nagle disabling and the
use of a JAXP Transform in place of a DocumentBuilder. That could help
establish tuning guidelines and possibly indicate defaults that should be
changed.
Scott Nichol
----- Original Message -----
From: "WJCarpenter" <bi...@carpenter.org>
To: <so...@xml.apache.org>
Sent: Friday, July 26, 2002 1:02 PM
Subject: Re: setTcpNoDelay; why not true by default?
> > The default is simply for backward compatibility. This is like when
> > the ability to set the output buffer size was added. The objective was
> > to ensure unchanged behavior for users working without the feature,
> > especially given that the feature was virtually untested at the release
> > date, and no one have quantitative measurements of the actual benefits.
>
> I understand and agree with that principle, but in this case it's just
> a performance difference, not a functional difference. The performance
> difference is very clear ... a SOAP request takes under 10 ms with
TcpNoDelay
> set true and 200 ms with it set false (which is the effective default).
> --
> bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
Bill,
It was certainly an extremely cautious decision, perhaps too extreme.
Still, the timing difference you quote is just one scenario (BTW, is this a
connect-send-get-disconnect, or an average of multiple send-get within a
single connect-disconnect?). What about other scenarios, such as what
appear to be the many people transfering payloads of 100k or several MB?
Perhaps you have enough experience to know what the result will be, but I do
not. It seems like the benefit of sending fewer IP packets might outweigh
the elimination of the delay. I would not want to change the default value
to improve performance when I don't know that I really am improving it for
everyone, or at least being armed with numbers to inform users how they will
be affected. Without actual measurements, I am reluctant to change the
defaults.
This thread has reminded me that I wanted to take an old, relatively simple
performance test I had, spruce it up and add it as a sample, then run it to
measure the effect of changing output buffer size, Nagle disabling and the
use of a JAXP Transform in place of a DocumentBuilder. That could help
establish tuning guidelines and possibly indicate defaults that should be
changed.
Scott Nichol
----- Original Message -----
From: "WJCarpenter" <bi...@carpenter.org>
To: <so...@xml.apache.org>
Sent: Friday, July 26, 2002 1:02 PM
Subject: Re: setTcpNoDelay; why not true by default?
> > The default is simply for backward compatibility. This is like when
> > the ability to set the output buffer size was added. The objective was
> > to ensure unchanged behavior for users working without the feature,
> > especially given that the feature was virtually untested at the release
> > date, and no one have quantitative measurements of the actual benefits.
>
> I understand and agree with that principle, but in this case it's just
> a performance difference, not a functional difference. The performance
> difference is very clear ... a SOAP request takes under 10 ms with
TcpNoDelay
> set true and 200 ms with it set false (which is the effective default).
> --
> bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
> The default is simply for backward compatibility. This is like when
> the ability to set the output buffer size was added. The objective was
> to ensure unchanged behavior for users working without the feature,
> especially given that the feature was virtually untested at the release
> date, and no one have quantitative measurements of the actual benefits.
I understand and agree with that principle, but in this case it's just
a performance difference, not a functional difference. The performance
difference is very clear ... a SOAP request takes under 10 ms with TcpNoDelay
set true and 200 ms with it set false (which is the effective default).
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by WJCarpenter <bi...@carpenter.org>.
> The default is simply for backward compatibility. This is like when
> the ability to set the output buffer size was added. The objective was
> to ensure unchanged behavior for users working without the feature,
> especially given that the feature was virtually untested at the release
> date, and no one have quantitative measurements of the actual benefits.
I understand and agree with that principle, but in this case it's just
a performance difference, not a functional difference. The performance
difference is very clear ... a SOAP request takes under 10 ms with TcpNoDelay
set true and 200 ms with it set false (which is the effective default).
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
The default is simply for backward compatibility. This is like when the
ability to set the output buffer size was added. The objective was to
ensure unchanged behavior for users working without the feature, especially
given that the feature was virtually untested at the release date, and no
one have quantitative measurements of the actual benefits.
Scott Nichol
----- Original Message -----
From: "WJCarpenter" <bi...@carpenter.org>
To: <so...@xml.apache.org>
Sent: Thursday, July 25, 2002 6:43 PM
Subject: setTcpNoDelay; why not true by default?
> It's very nice indeed that SOAP 2.3 has direct API support for setting
> the TcpNoDelay option. It seems curious to me, though, that it's not
> defaulted to true (which, in the strange lingo of this option, means
> "yes, I want no delay"). I don't imagine any SOAP calls would ever
> benefit from having the Nagle algorithm delay.
>
> Shouldn't we just default it to true instead of depending on callers to
> be wise enough to do it on their own? Just like in the stock market,
> where theinsiders will always have better performance than people like me,
Apache
> SOAP insiders will know to call
SOAPHttpConnection.setTcpNoDelay(BooleanTRUE)
> and have better performance than the unwashed.
> --
> bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: setTcpNoDelay; why not true by default?
Posted by Scott Nichol <sn...@scottnichol.com>.
The default is simply for backward compatibility. This is like when the
ability to set the output buffer size was added. The objective was to
ensure unchanged behavior for users working without the feature, especially
given that the feature was virtually untested at the release date, and no
one have quantitative measurements of the actual benefits.
Scott Nichol
----- Original Message -----
From: "WJCarpenter" <bi...@carpenter.org>
To: <so...@xml.apache.org>
Sent: Thursday, July 25, 2002 6:43 PM
Subject: setTcpNoDelay; why not true by default?
> It's very nice indeed that SOAP 2.3 has direct API support for setting
> the TcpNoDelay option. It seems curious to me, though, that it's not
> defaulted to true (which, in the strange lingo of this option, means
> "yes, I want no delay"). I don't imagine any SOAP calls would ever
> benefit from having the Nagle algorithm delay.
>
> Shouldn't we just default it to true instead of depending on callers to
> be wise enough to do it on their own? Just like in the stock market,
> where theinsiders will always have better performance than people like me,
Apache
> SOAP insiders will know to call
SOAPHttpConnection.setTcpNoDelay(BooleanTRUE)
> and have better performance than the unwashed.
> --
> bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>