Forum Discussion

THi_89722's avatar
THi_89722
Icon for Nimbostratus rankNimbostratus
Jun 05, 2017

How to cope with very slow clients

I have a case where web server needs to be able to respond both to normal (fast) clients and very slow clients. Majority of client requests are for very small responses (full HTTP response in 1-3 TCP packets).

 

Occassionally, a client may request for a larger payload (not big, only 30-500kB), which the slow clients are able to receive at very slow pace, over 2-15 min. Servers are IIS with 120s default timeout. We would not like to change that. Request is HTTP/1.1 and have keepalives and also connection close headers.

 

Without F5 LTM in between, a slow client gets the whole HTTP response ok, as acking to HTTP response's TCP packets is well within the timeouts. With F5 in between, the LTM's TCP receive buffer will get most or the whole HTTP payload within the same second as it starts to send it to the client.

 

As the F5 has acked the whole HTTP payload within the first second, IIS starts its HTTP idle timeout counter, while the client has just started to receive the payload. Eventually IIS the timeout will expire and IIS will send a TCP reset. This will propagate to the client and the transfer will terminate prematurely..

 

I would not like to change the receive/transmit buffer settings to very small as these larger responses are very infrequent and majority of the clients are fast (or normal). Autosetting the buffers/windows in TCP profile did not help. Nor did enabling pacing.

 

I could make an irule separate the slow clients based client type header and do something to adjust to the slow clients. Any advice on this?

 

application delivery
BIG-IP
LTM

1 Reply

Sort By
  • dragonflymr's avatar
    dragonflymr
    Icon for Cirrostratus rankCirrostratus
    Jun 05, 2017

    Hi,

     

    Not an expert here but maybe changing Proxy Buffers for TCP connection based on mentioned client headers could be the choice? If you lower proxy buffer high then after receiving small part of the reply BIG-IP will send ser window, and probably will resend it (or maybe TCP keep alive will have to be used on serverside - via profile config) so IIS TCP connection will not timeout and there will be no reset from IIS.

     

    • TCP::proxybuffer - sets the TCP proxy buffer thresholds
    • TCP::proxybufferhigh - gets the proxy buffer high threshold
    • TCP::proxybufferlow - gets the proxy buffer low threshold
    • TCP::sendbuf - sets the TCP send buffer size

    Maybe as well manipulating receive window on serverside could be used

     

    TCP::recvwnd - sets the TCP receive window

     

    BTW: quoting TCP gurus on DevCentral:

     

    • proxy-buffer-high = send-buffer-size = (clientside bandwidth) * (clientside RTT)
    • proxy-buffer-low = (clientside bandwidth) * (serverside RTT)
    • proxy-buffer-low must be sufficiently below proxy-buffer-high to avoid flapping.

    Those commands probably can be used to estimate clienside RTT to be used in calculations above:

     

    • TCP::rtt - Returns the smoothed round-trip time estimate for a TCP connection.
    • TCP::rttvar - The measured RTT variance in units of "1/16 of a millisecond".

    Don't know how to estimate clienside bandwidth in easy way - maybe just be Wireshark analysis on big enough sample.

     

    Or maybe (if Analytics profile is assigned to VS) by qurying stats collected - maybe like described in Getting total bandwidth currently utilized in an iRule

     

    Piotr