RE: [Web Timing] Getting root timings to recommendation

Thank you for the detailed response! It's great to hear from another user agent on the definition on these timings. We agree that it definitely would be the easiest and will not lose any information about the time the user agent queues the request to waiting for the first byte from the network layer.

The recommended text you provided for the definition of requestEnd captures what we are currently doing in the beta for IE9 "... the point the browser receives the first byte of the response from the server...". The rationale here is that this time phase then captures the time associated with the transmission of the request to the server and waiting for the first byte response as IE does not have insight into the last buffer sent over TCP.

In the IE9 beta platform preview, we have the connectStart time reflected as the time either the socket has become available or the time the socket would have been accessed. Thus it approximates to the definition for Time 1 you've outlined. The current thinking here is that this helps provide a complete timeline that best reflects this time phase from the browser's perspective.

Anderson Quach 
IE Program Manager

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Sigbjørn Vik
Sent: Thursday, September 16, 2010 3:09 AM
To: public-web-perf@w3.org
Subject: Re: [Web Timing] Getting root timings to recommendation

On Thu, 16 Sep 2010 03:18:29 +0200, Anderson Quach <aquach@microsoft.com>
wrote:

> The definition for requestEnd may need some more specificity, the spec 
> currently states "the time when the user agent finishes requesting the 
> current document from the server". Here are a few approaches to how 
> request end can be interpreted.
>
>
> *         When the browser has finished generating its request (often,  
> building a memory buffer) that it hands off to the network API. If so, 
> this time will be very close to 0.
>
> *         When the network API is done constructing its last buffer to  
> be sent over TCP. Some browsers may not have insight into this and 
> lower levels.
>
> *         When the TCP layer has send out its last packet to the server.
>
> *         When the server receives the last packet.
>
> Nic and I recommend defining requestEnd as "the point the browser 
> receives the first byte from the server", we maintain a 
> browser-centric POV that is well-defined and the easiest implementable 
> solution by all user agents.
>
> Defining it as such would also remove the large, very important gap of 
> waiting on the server.
>
> It would be great to get the perspective from Mozilla and Opera on the 
> request and response phase.

I haven't read the spec in detail before, and trying to make sense of it now I get somewhat confused.

The time taken to wait for the server is important, and should be easily available. I see a possible ambiguity in requestStart, which means (requestEnd - requestStart) might not equal the time spent waiting for the server. Consider the following scenario:


Time 0: The fetching starts
Time 1: The user agent asks the cache for the resource Time 2: The cache responds: No hit Time 3: The user agent queues the request for sending to the network layer Time 4: A socket becomes available, and the user agent sends the request to the network layer Time 5: The first byte reaches the user agent from the network layer

The time spent between time 0 and time 1 can in some cases be significant, waiting for a thread or DNS, the time between 1 and 2 can be significant particularly on devices with slow disks, and the time between time 3 and 4 can also be significant in some scenarios.

The time taken waiting for the server is best estimated with (Time 5 - Time 4). According to various readings of the spec, requestStart might be either of Time 1, Time 3, and Time 4. Either connectStart is equal to Time
0 (fetchStart), or connectStart indicates Time 4, so that can be used, but just sometimes.

It also confuses me that connectStart can have either of two values. Maybe connectStart should be Time 4 in the case of reusing a connection (and connectEnd the same)? And when using cached resources, connectStart should likely be Time 1, not Time 0 as currently? This would allow requestStart to be clarified as Time 1, even if the user agent later on sends the request to the network instead. With these changes, the time spent waiting for the resource plus the latency, can better be estimated using (requestEnd - connectStart) (the latency can be estimated with connectStart and connectEnd), and the overall time taken is available as (requestEnd - requestStart).

The definition of requestEnd needs to take into the account of pipelining.  
Thus it needs to be defined as "the point the browser receives the first byte *of the response* from the server", there might be many bytes before that.

Given that, most time periods are available (except 2 and 3 above), and defining requestEnd as above will be the easiest, and not lose any important information.

Nitpick on the http://dev.w3.org/2006/webapi/WebTiming/ spec:
The first instance of ResourceTiming links to a missing link.
responseEnd should be defined identically to responseStart, i.e. both should use either "document" or "response", and responseEnd should substitute "from from" with "from the server, or from".
Could the spec be made more reader friendly by substituting all occurences of "the number of milliseconds between midnight of January 1, 1970 (UTC) and the time" with "the <a href='#time'>time</a>", and an explanation?
Does domainLookupStart need a clarification that if DNS lookup was started before fetchStart (in the case of DNS prefetching), domainLookupStart should still be set to fetchStart?

--
Sigbjørn Vik
Quality Assurance
Opera Software

Received on Wednesday, 22 September 2010 01:27:59 UTC