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
