Re: Proposal to measure end-user latency

I've also wanted this-- this would allow servers to perform automatic
testing/analysis without requiring content writers to add code. This is
desirable for doing things like changing the order/frequency of server
push, etc.
This would be something in addition to what is available at the application
layer.
In particular, a server could add a header indicating that it would like to
see the WebTiming results for the page POSTed to a particular URI after
some condition (e.g. X seconds, X resource loaded, etc) had been met.

Despite the fact that I believe this is truly useful, I believe also that
this is probably not the right place to standardize such a thing-- I
believe the W3C is.

-=R


On Tue, Sep 3, 2013 at 11:23 AM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Martin,
>
> On Tue, Sep 03, 2013 at 11:11:29AM -0700, Martin Thomson wrote:
> > On 3 September 2013 10:07, Sébastien  BARNOUD
> > <sebastien.barnoud@prologism.fr> wrote:
> > > You can always develop your custom application.
> >
> > You are right.  But you didn't answer my question.  How is an
> > application layer solution inadequate?
>
> It is not inadequate, it is different. What I'm noticing is that
> server-side software has no idea what response times are and worse,
> what the transfer time is. Some companies develop client-side gadgets
> to provide this feedback to the server, but all in all very few web
> sites rely on such techniques and have a measurement of their response
> time.
>
> So the result is that server-side software has no clue what their
> response time is nor how it variates with time and load. I had to
> put timers in haproxy precisely to provide this information, but
> that does not cover the transfer time, and (unfortunately) not
> everyone uses haproxy yet :-)
>
> > Arguably, it's superior because it can also measure other factors that
> > the protocol cannot.
>
> 100% agreed, I'm tempted to balance between seeing a strandard way to
> propose browsers to upload their feedback using HTTP headers (but with
> what request, when, and measure what) and maybe suggesting a standard
> method for a sender to measure the time it takes to flush a complete
> window. The first one is accurate but not easy to report nor easy to
> standardize. The second one only covers transport (not response time)
> but allows the server to measure the time taken by the transport.
>
> Probably something useful would be between the two, maybe have the browser
> measure the time elapsed between a request is sent and the first bytes
> start flowing back and report that using very few bytes of protocol in
> the other direction could be useful.
>
> I'm sure that adding such metrics can provide many useful help to improve
> overall user experience, but it's not obvious to me how.
>
> Willy
>
>
>