httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wang <aw...@ptc.com>
Subject Re: Speeding up mod_proxy_balancer on Windows
Date Mon, 13 Oct 2008 16:32:54 GMT
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


Mime
View raw message