Message-ID: <383EB7ED.DB9A3FD1@w3.org> Date: Fri, 26 Nov 1999 11:40:13 -0500 From: Philipp Hoschka <ph@w3.org> To: www-wca@w3.org Subject: data on what makes web access slow [Fwd: end user impact of TCP speed (was: Re: fast tcp && win2000)]
attached mail follows:
Message-Id: <4.1.19991123134857.00972c10@mailee.research.telcordia.com> Date: Tue, 23 Nov 1999 13:57:16 -0500 To: Joe Touch <touch@isi.edu>, ph@w3.org, chase@cs.duke.edu, gray@microsoft.com From: Christian Huitema <huitema@research.telcordia.com> Subject: RE: end user impact of TCP speed (was: Re: fast tcp && win2000) Cc: sandrof@microsoft.com, feldy@myri.com, end2end-interest@isi.edu, gallatin@duke.cs.duke.edu, grant@duke.cs.duke.edu, SABAMA@exchange.microsoft.com, jawadk@exchange.microsoft.com I have been conducting a little experiment to try assess precisely that -- are the long web delays due to network performance, or are they due to server overload? One way to get a cue is to look at the delay between the sending of the HTTP/GET command and the arrival of the first byte of the response. In theory, most of the delays here will be due to the server, which has to dequeue the connection (accept), get to read the command (select, recv), then process the command, format the response and send it. I know there are obviously limits to such evaluations... Anyhow, you can get a look at the early results at ftp://ftp.telcordia.com/pub/huitema/stats/quality_today.html The "delays between GET and first byte" that I observed represent between 30 and 40% of the duration of the average transaction. To ease that, you probably need more powerful servers. Getting faster connections would obviously help the other 60% of the delay. -- Christian Huitema