- From: Ilya Grigorik <igrigorik@google.com>
- Date: Thu, 30 Apr 2015 15:34:53 -0700
- To: "Nottingham, Mark" <mnotting@akamai.com>
- Cc: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CADXXVKrc7CpdLUtpXxzCyujJCN0cPFsdJQ6sRQ_9NuV5jJqVgw@mail.gmail.com>
On Wed, Apr 29, 2015 at 7:17 PM, Nottingham, Mark <mnotting@akamai.com> wrote: > """ > 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 ig
Received on Thursday, 30 April 2015 22:36:01 UTC