Re: communicating server timing data to the client.. Server Timing?

On Sat, Nov 22, 2014 at 3:34 PM, Ben Maurer <ben.maurer@gmail.com> wrote:

> One thing that could potentially be useful is allowing start & end times
> (relative to the time the header was sent on the server). That can be used
> to give a timeline of server events in devtools (it takes a bit of work to
> correlate server timestamps to client ones, but is doable)
>

I'm not sure I follow. The problem is that we have two unsynchronized
clocks, plus a variable routing delay on each request.. which you have no
way to infer short of tracking some form of running RTT-median and using
that as a proxy. Can we kinda/sorta guess? Maybe. That said, I don't think
this is a path we want to go down. Or, am I missing your point?


> I'd also like to see the spec explicitly talk about how to send server
> metrics for pages that do chunked encoding / early flush. I'd like to make
> sure that's something that implementers are testing.
>

Yep, will have to add that. The mechanism is:
http://httpwg.github.io/specs/rfc7230.html#chunked.trailer.part

On Sun, Nov 23, 2014 at 9:37 PM, Nottingham, Mark <mnotting@akamai.com>
 wrote:
>
> Tell me if you need help with specifying the header ABNF, etc.
>

Yes, please! I'll try to take a first run at it.. but if you beat me to it,
that would be even better! :)

On Mon, Nov 24, 2014 at 7:15 AM, Patrick Meenan <pmeenan@webpagetest.org>
wrote:
>
> A straight-up list is probably going to be the easiest and only reliable
> way to present it because there's not really any conventions about the
> times that are being reported (specifically, no guarantee that the times
> won't be overlapping).
>

That's a great point. An application can report that "db" took X ms and
that "servlet" took Y ms... and "db" may be a subset of "servlet". We
shouldn't assume anything about ordering or overlap for the communicated
metrics.


> Reporting the times of a bunch of async operations (or top-level and lower
> level timings) are going to be really valuable but there's no way for the
> generic tooling to know if the operations are blocking on the back-end or
> overlapped.
>

Yep.

ig