Search squid archive

Re: squid speedup to client using TCP fast start?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27/11/10 19:26, Linda Walsh wrote:


There's an article pointed to by slashdot @
http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html
where the author found that instead of a slow start of sending a packet
or two and waiting for an ACK, some sites like Google and Microsoft,
optimize for their initial web page display by NOT "slow starting" and
sending 4 or more packets w/o waiting for the initial ACK. This gives
them a LARGE boost for that initial page -- and would for any initial
start of a TCP connection.

Since many connections to squid are small TCP session, it seems

This statement is no longer certain. HTTP/1.1 defauts to longer connections than HTTP/1.0 to avoid these same TCP delays.

eliminating the 'slow start' might provide a significant boost when
loading pages with browsers that use many small TCP connections.

Browsers load a max of 10 connections. With the older HTTP/1.0 Squid this could result is log as these few connections were opened and closed on the same client-proxy link. (avoided by turning client_persistent_connections ON).


Is this something the squid designers have given any consideration to
for inclusion as an option -- is it something that could be done when
setting up a connection to a remote server? I.e. when 'fetching', is it
possible to set the initial window 'larger' -- since most of the benefit
comes from using a larger window where the RTT is 'large' (~>30ms).

You had best ask those designers... over on the squid-dev mailing list where they hang out. I'm the only dev that reads this list regularly and any such decisions were made well before my time in the project.


If the RTT times between the squid cache and the client are very low
already, then the benefit wouldn't be as noticeable.

Some research papers from presentations on the benefit of increasing the
initial startup window:
Abstract:
http://www.google.com/research/pubs/pub36640.html
Full Paper:
http://www.isi.edu/lsam/publications/phttp_tcp_interactions/node2.html

Some simulations from 1998 on the value of increasing the initial TCP
window size:
http://www.rfc-archive.org/getrfc.php?rfc=2414

Apparently, a patch may be necessary to give applications control over
this, this patch was shown here:
http://www.amailbox.org/mailarchive/linux-netdev/2010/5/26/6278007


ICMP, MTU, ECN and Window scaling have only partial support in the IPv4 Internet. When they work things go great. Squid leaves most of this to the underlying system settings for tuning. Several things like buffers are handled dynamically from the OS provided information at runtime.

-----


Also another method of speeding up web page delivery has to do with
HTTP pipelining -- however, some paper (forget the link, had too many
open and then the window crashed...ARG)...said this wasn't widely used
due to problems with proxy support.

Doesn't (or does?) squid support this?

Squid supports pipelining since 2.5 or earlier.

The design flaw with pipelines is that if the connection closes for any reason the entire requests set is lost has to be re-sent by the browser. There are a great many reasons for closing a TCP link in HTTP/1.0. Dynamic content of unknown length being the overwhelming cause. So HTTP/1.1 support is essentially a requirement for reliability on the pipieline.

Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.9
  Beta testers wanted for 3.2.0.3


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux