5

I have a HTTP server that serves only two kinds of page: about 10 KB and about 16 KB (both compressed, other files are from CDN). As the latency is quite high (ping takes more than 300 ms), I want to optimize the TCP stack so that client receives the whole page ASAP.

Thus, I have a double question:

  • Which parameter do I have to change (which value of TCP window)?
  • How to change in (a Debian box, and FYI, there is a Varnish before the HTTP server).
Improve this question

2 Answers 2

Reset to default
5

If you are stuck with this high latency, I guess one thing you would like to do is avoid TCP Slow Start. By default, the TCP stack will wait for a ACK after sending the first 3 packets, in your case this means a delay of 600 ms because of round trip time. It has already been disused here. According to this, you cannot change this number easily in Linux, except moving to kernel version 2.6.33.

Maybe you could recompile your kernel with a larger value for the correct parameter, or move to an OS that allows you to use a larger value on this parameter (I think Solaris can be tuned here).

On the application side, make sure to enable HTTP Keep-Alive to avoid Slow Start at each HTTP request.

Improve this answer
5
  • I am not sure if avoiding TCP slow start will help, because browsers try to work around this. Quoting the article: "The slow-start protocol performs badly for short-lived connections. Older web browsers would create many consecutive short-lived connections to the web server, and would open and close the connection for each file requested. This kept most connections in the slow start mode, which resulted in poor response time. To avoid this problem, modern browsers either open multiple connections simultaneously or reuse one connection for all files requested from a particular web server"
    – aseq
    Commented Apr 9, 2012 at 23:02
  • 2
    Because of the latency, downloading one file of 16K will take 2,4 seconds (600 ms for the SYN-SYN/ACK, 300 m for the request, 600 ms for the first 3 packets, 600 ms for the next 6 packets, and 300 ms for the lasts packets). You can get this down to 1,2 seconds if you are able to get the OS to send all the packets after the 2 way handshake and avoid Slow Start. Of course, if you also avoid the handshake (Keep-Alive) you can get down to 600 ms, but this last optimization is a tuning in Apache where you need help on the client side, not in the TCP stack as the requester asked.
    – jfg956
    Commented Apr 10, 2012 at 6:39
  • As the actual kernel in Debian Squeeze is 2.6.32, I think I'll have to get a new one from backports then try to increase cwnd to about 12 to fit my 16 KB file size.
    – jcisio
    Commented Apr 11, 2012 at 7:12
  • Avoiding slow-start is what you want to aim for. @samsaffron wrote about it here: samsaffron.com/archive/2012/03/01/… The guys from CDNPlanet have covered it too.
    – Andy Davies
    Commented Apr 13, 2012 at 15:42
  • @jfgagne, SYN + SYN-ACK would take not 600 ms, but 300 ms instead since 300 ms is Round Trip Time ping shows.
    – poige
    Commented Jun 23, 2012 at 12:35
0

I don't think there is much to do with regards to specific tcp/ip and other network related settings you can change in the kernel to decrease latency substantially, i.e. bring it down from 300 ms to less than 100 ms. Unless something is configured incorrectly to begin with that causes such lag, or the server is excessively busy (or a hardware issue).

You need to give more data such as traceroutes to and from your server as well as ping results to and from your server and anything else that may show possible reasons for such latency.

Improve this answer
1
  • 1
    The high latency is due to a long route (EU -> Asia). I have little choice on geographical location of the main server.
    – jcisio
    Commented Apr 11, 2012 at 7:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .