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 Thursday, 16 September 2010 10:09:40 UTC