W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2015

Re: [server-timing] CDN use case

From: Ilya Grigorik <igrigorik@google.com>
Date: Thu, 30 Apr 2015 15:34:53 -0700
Message-ID: <CADXXVKrc7CpdLUtpXxzCyujJCN0cPFsdJQ6sRQ_9NuV5jJqVgw@mail.gmail.com>
To: "Nottingham, Mark" <mnotting@akamai.com>
Cc: public-web-perf <public-web-perf@w3.org>
On Wed, Apr 29, 2015 at 7:17 PM, Nottingham, Mark <mnotting@akamai.com>

> """
> For example, a CDN edge node may want to report which data center was
> being used, if the resource was available in cache, and how long it took to
> retrieve the response from cache or from the origin server. Further, the
> same process may be repeated by other proxies, thus allowing full
> end-to-end visibility into how the request was routed and where the time
> was spent.
> """
> I guess I'm kind of finding that hard to believe — the syntax of S-T is
> quite constrained, and it's not clear how this information would be
> visualised. Is this really a use case for S-T?

There are some limitations, but yes, I do believe you can deliver useful
data.. Further, the application can add its own smarts where needed:

- The UA can't rely on order of headers (or even the order of multiple
metrics within a single header) to sort them in any meaningful way.
- Since multiple servers may be emitting metrics, and each may have a
different clock, there is no meaningful startTime equivalent for ST metrics.

As a result, the UA receives the metrics and returns them in some arbitrary
order. From there, the application can apply own smarts to visualize it,
either as as a table, or as a sorted sequence if it can apply some smarts
to order the metrics. Concretely... let's say I get the following response.

< 200 OK
< Server-Timing: db=53, app=47.2
< Server-Timing: dc;atl, origin=141.2
< Server-Timing: squid;miss

Without any further knowledge the UA can simply output the table with
appropriate metric name, value, and description. But, as an owner of the
site I could sort this based on knowledge of my routing architecture:

1) request hit Atlanta data center (dc;atl), and total time to fetch from
origin was 141.2ms
2) My CDN routed to Squid cache at origin, which resulted in a cache miss
3) Squid forwarded request to app server, which took 53ms to fetch data
from the database, and 47.2ms to generate the response

Received on Thursday, 30 April 2015 22:36:01 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 30 April 2015 22:36:01 UTC