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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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. > > -- > > [EMAIL PROTECTED] (WJCarpenter) PGP 0x91865119 > > 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 > > > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
