On Sat, Nov 22, 2014 at 3:34 PM, Ben Maurer <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
