Re: Proposal to measure end-user latency

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

Received on Tuesday, 3 September 2013 18:24:05 UTC