A central performance problem in the World Wide Web, in recent years, has been client latency. Client latency may be defined as the time a client has to wait, between requesting data from a server, and finishing to download the requested data, and all data associated with the request.
Impatience with poor performance is the most common reason a user's visit to a web sites is abandoned. For e-commerce sites, these abandonments translate into lost revenue. Measurements of client latencies are critical in order to minimize client latencies, so that users are satisfied with their experience, and do not abandon the download. Once the client latency is understood, a site can reduce its latency in a number of ways, for example:
(a) deploying a mirror site,
(b) buying wider connectivity to the Internet,
(c) deploying a more powerful web server
(d) load balancing
(e) altering the objects on the site, and
(f) altering the placement of the objects on the site.
As of today, the main way of conducting client latency measurements is to use agents external to the site. The agents are deployed at a limited number of locations around a network, be it an intranet, or on the Internet, and the agents fetch specific web pages from a web server, specifically to measure the latency from the limited number of locations where those agents reside. The disadvantages of this method are:
(1) The server is dependent upon an external body for conducting the measurements,
(2) The agent's measurements do not necessarily reflect actual client experience,
(3)The perceived latency measured by the agents does not have a breakdown of the various latency components, and
(4)The agents' DNS lookup time is effected by prior DNS lookup queries.
Client latencies will vary based on what version of HTTP a client is using. In HTTP 1.0 a client would establish a new TCP connection for each HTTP request. Using a new TCP connection for each request led to incurring connection-establishment latencies on each request. Connection establishment times will be described in greater detail below. With HTTP 1, clients establish a persistent TCP connection with the server, and those connections are re-used for multiple HTTP requests, and responses.
What is needed is a solution that does not require agents to be placed at external locations on the network. Preferably, such a solution should analyze, for each client of the server, what latencies are experienced by the individual client. It would be additionally beneficial if such a measuring device required no additional hardware, and could be optionally run during actual server operation, or during off peak times.
An attempt at a description of such a solution was made by Balachander Krishnamurthy, and Jennifer Rexford in their paper “En Passant: Predicting HTTP/1.1 traffic. Proc. Global Internet Symposium, 1999. ” Their means required accurate clock synchronization, between a client and a server, and low level TCP/IP traces.