Re: [Web Timing] Getting root timings to recommendation

    Great comments. My appology for missing this thread earlier. Consider me
grounded in the past week...

On Thu, Sep 16, 2010 at 3:09 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> 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.
>

  Good point. The question is what we would consider as a "request". Here is
my interpretation:
      * cache hit: looking up the resource from the cache
  * cache miss: issue the request to the server.
   You are suggesting including the cache lookup time in case of a cache
miss, which sounds good to me too.



>
> 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?


    Agree.


> 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).
>

    As long as this is all we agree on (which appears to be), let it so.


>
> 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?
>

   Make sense. Out of curiosity, how does the user agent prefetch a DNS for
the root page before the fetch? Part of the fetching processing is to
formulate the address of the resource.
I can only imagine the user agent prefetch DNS for embedded links/elements
on the current page.

   I have some problem dealing with the newly setup mercurial repository. I
will update the draft once I get it working.

thanks,
Zhiheng


>
> --
> Sigbjørn Vik
> Quality Assurance
> Opera Software
>
>