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 17:38:19 GMT
After a poke and a prod from someone else here about this delay
algorithm being used for timeouts, having that default to 0 doesn't seem
like it would be appropriate either as it could severely hamper network
connectivity in legitimate timeout cases.

It seems like MS' TCP stack seems to think a RST is the same as a
timeout.  argh!!

Andy

Jess Holle wrote:
> I just set this parameter to 0 and the issue went away entirely.
>
> Good catch, Ruediger!  Thank you -- and all who helped on this thread!
>
> It would appear that Microsoft's documentation slipped a decimal place
> somewhere as it would appear there is about 0.3 second delay on the
> initial retry and about a 0.6 second on the second -- resulting in
> about a 1 second overall delay when other overhead/latency is included.
>
> I don't see a way to reduce this delay and overall concur with Andy
> that this parameter should be 0 by all rights.  Any thoughts?
>
> --
> Jess Holle
>
> Andy Wang wrote:
>> 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