Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 68217 invoked from network); 13 Oct 2008 16:34:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Oct 2008 16:34:29 -0000 Received: (qmail 94016 invoked by uid 500); 13 Oct 2008 16:34:26 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 93969 invoked by uid 500); 13 Oct 2008 16:34:26 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 93960 invoked by uid 99); 13 Oct 2008 16:34:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Oct 2008 09:34:26 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [12.11.148.84] (HELO irp2.ptc.com) (12.11.148.84) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Oct 2008 16:33:19 +0000 X-IronPort-AV: E=Sophos;i="4.33,404,1220241600"; d="scan'208,217";a="27034285" Received: from unknown (HELO HQ-EX3FE2.ptcnet.ptc.com) ([132.253.201.63]) by irp2.ptc.com with ESMTP; 13 Oct 2008 12:32:55 -0400 Received: from [132.253.11.202] ([132.253.11.202]) by HQ-EX3FE2.ptcnet.ptc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 12:32:55 -0400 Message-ID: <48F37836.7000101@ptc.com> Date: Mon, 13 Oct 2008 11:32:54 -0500 From: Andy Wang User-Agent: Thunderbird 2.0.0.17 (X11/20081001) MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: Speeding up mod_proxy_balancer on Windows References: <532607.11592.qm@web58305.mail.re3.yahoo.com> <48F27F26.3070800@ptc.com> <48F281E9.50706@apache.org> <48F318EC.2080405@ptc.com> <48F3266B.2080707@apache.org> <48F338A8.7080509@apache.org> <48F3532C.4050406@kippdata.de> <48F35D50.8010003@apache.org> In-Reply-To: <48F35D50.8010003@apache.org> Content-Type: multipart/alternative; boundary="------------040305020904040804010700" X-OriginalArrivalTime: 13 Oct 2008 16:32:55.0124 (UTC) FILETIME=[5825C140:01C92D51] X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------040305020904040804010700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Ruediger Pluem wrote: >>> >>> According to the Microsoft >>> (http://support.microsoft.com/default.aspx/kb/314053) >>> >>> TcpMaxConnectRetransmissions >>> Key: Tcpip\Parameters >>> Value Type: REG_DWORD - Number >>> Valid Range: 0 - 0xFFFFFFFF >>> Default: 2 >>> Description: This parameter determines the number of times that TCP >>> retransmits a connect request (SYN) before aborting the attempt. The >>> retransmission timeout is doubled with each successive retransmission >>> in a particular connect attempt. The initial timeout value is three >>> seconds. >>> >>> >>> So, looks like with default of 2 retransmits there is at least 9 >>> second delay. >>> >> I thought the problem was with local connects to a port, to which no >> process listens to. In this case the OS should immediately sending a RST >> (reset) and the client should not resend the SYN. I expect this >> TcpMaxConnectRetransmissions to be used in the case, were the remote >> server doesn't send any answer (neither RST nor SYN/ACK) and the client >> needs to retry the connection establishment after some timeout. That >> shouldn't be the case here, because the local system should always be >> able to send a RST if nothing is listening on the port. >> >> Except there's a local firewall with packet drop coming into the game >> (or name resolution timeouts, or ...). >> > > Exactly my understanding of the problem. So I see no use in TcpMaxConnectRetransmissions > for this case. > > Regards > > R�diger > > > Looks like it might be the retry issue: 3963 13.831213 source destination TCP 1230 > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 4087 14.280717 source destination TCP 2608 > 1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 4088 14.280735 source destination TCP 1230 > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 4238 14.827581 source destination TCP 2608 > 1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 4239 14.827603 source destination TCP 1230 > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 The RSTs occur remotely and Windows retries twice. 1428 4.025656 unixsource destination TCP 57864 > 1230 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=0 1429 4.025674 unixsource destination TCP 1230 > 57864 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 That's the same exchange from an HP-UX source to a linux destination. I'm assuming that windows pulls the same crap for localhost traffic even though we can't capture it to prove the case. Oh the joys of TCP/IP troubleshooting on Windows :) Andy --------------040305020904040804010700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ruediger Pluem wrote: 

According to the Microsoft
(http://support.microsoft.com/default.aspx/kb/314053)

TcpMaxConnectRetransmissions
Key: Tcpip\Parameters
Value Type: REG_DWORD - Number
Valid Range: 0 - 0xFFFFFFFF
Default: 2
Description: This parameter determines the number of times that TCP
retransmits a connect request (SYN) before aborting the attempt. The
retransmission timeout is doubled with each successive retransmission
in a particular connect attempt. The initial timeout value is three
seconds.


So, looks like with default of 2 retransmits there is at least 9
second delay.
      
I thought the problem was with local connects to a port, to which no
process listens to. In this case the OS should immediately sending a RST
(reset) and the client should not resend the SYN. I expect this
TcpMaxConnectRetransmissions to be used in the case, were the remote
server doesn't send any answer (neither RST nor SYN/ACK) and the client
needs to retry the connection establishment after some timeout. That
shouldn't be the case here, because the local system should always be
able to send a RST if nothing is listening on the port.

Except there's a local firewall with packet drop coming into the game
(or name resolution timeouts, or ...).
    

Exactly my understanding of the problem. So I see no use in TcpMaxConnectRetransmissions
for this case.

Regards

Rüdiger
Looks like it might be the retry issue:
   3963 13.831213   source         destination         TCP      1230 > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
   4087 14.280717   source         destination         TCP      2608 > 1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
   4088 14.280735   source         destination         TCP      1230 > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
   4238 14.827581   source         destination         TCP      2608 > 1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
   4239 14.827603   source         destination         TCP      1230 > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0


The RSTs occur remotely and Windows retries twice.

1428    4.025656    unixsource     destination    TCP    57864 > 1230 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=0
1429    4.025674    unixsource     destination    TCP    1230 > 57864 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

That's the same exchange from an HP-UX source to a linux destination.

I'm assuming that windows pulls the same crap for localhost traffic even though we can't capture it to prove the case.  Oh the joys of TCP/IP troubleshooting on Windows :)

Andy

--------------040305020904040804010700--