RE: Cache information [was: Support for page/resource size]

+1, we would like to see some of these being instrumented as well. the benefits help us measure the effectiveness of the CDN a lot better without many of the specific user metrics we need to instrument today.

These are some of the overall metrics I can think of:
Total resources cached vs un-cached
Total bytes cached vs un-cached
Per resource bytes cached vs un-cached
Payload / content with/without http overhead

Thanks,
Jayanth




-----Original Message-----
From: Nottingham, Mark [mailto:mnotting@akamai.com] 
Sent: Monday, August 25, 2014 9:37 AM
To: Ritesh Maheshwari
Cc: Ilya Grigorik; Boris Zbarsky; public-web-perf
Subject: Cache information [was: Support for page/resource size]

FWIW - I've brought this up a number of times, IIRC on-list as well as privately with various folks.

AIUI implementers remain unconvinced of the value here -- at least enough to overcome the privacy concerns (which IMO are fairly minimal, but if you don't see the value in something, why take the risk?).

Maybe it's time to have the conversation again. I have a proposal that I can dust off...

Cheers,


On 11 Jul 2014, at 5:52 pm, Ritesh Maheshwari <riteshm@gmail.com> wrote:

> Not to hijack the thread, but having a clear indication of whether the resource was fetched from browser cache or not would be really useful to have..
> 
> Chrome, e.g., currently would report non-zero values even when the resource is loaded from cache. I am assuming its reporting the time it took to load the resource from disk, but it doesn't help us trying to figure out, e.g.., the browser cache-hit ratio of our apps.
> 
> Thanks,
> Ritesh
> 
> 
> On Thu, Jul 10, 2014 at 8:03 PM, Ilya Grigorik <igrigorik@google.com> wrote:
> 
> 
> 
> On Thu, Jul 10, 2014 at 5:54 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/10/14, 5:03 PM, Philippe Le Hegaret wrote:
> On Wed, 2014-07-09 at 18:13 -0400, Anthony van der Hoorn wrote:
> Additionally (and I say this hoping it's not pushing my luck), I would 
> like to know the "over-the-wire" size vs the "actual" size (chrome dev 
> tools calls this "content" vs "size"). That way we can start flagging 
> requests that aren't compressed, see bandwidth cost of payload, etc.
> 
> We'd need feedback from implementers here to know if it's possible.
> 
> It depends on how "over the wire" size is defined.  Are we talking about the size of the HTTP "payload body" (in RFC 7231 terms; "message body" in RFC 2616 terms)?  Or are we talking the size of the actual HTTP messages?  Or are we talking about actual bytes on the wire, whatever wire means?
> 
> Specifically, given some data that is sent with Content-Encoding:gzip and Transfer-Encoding:chunked over an SSL connection, are we measuring the size of the HTTP "message body" (which in this case is gzipped, note), or the "payload body" (which has the extra bytes for the chunked encoding) or the actual HTTP messages (which include headers in addition to the data) or the size of the TCP packets (which include SSL overhead bits and the HTTP messages in encrypted form, plus the TCP handshake itself) or something else?
> 
> Basically, what is the goal of measuring this number?
> 
> Approaching this from the point of view of the developer who will be using this API: I expect this number to match whatever Content-Length reports in my developer tools. First and foremost it should provide me with an accurate measure of bytes transferred between client and server (i.e. compressed size if compression was applied), and if possible, the decoded size as well. The size of HTTP headers and other overhead is a separate story, and I'm not sure we need to get into that.
>  
> As far as I can tell, we discussed it back in 2011 [1], but didn't 
> follow on it either. At the time, the conclusion was that it was 
> possible to do it for same-origin resources at least. However, again, 
> the response may come from the cache.
> 
> Caches have to know the status code of the cached response, generally, so they can provide it to consumers.
> 
> More interesting is what the status code should be reported as if the browser did a conditional request and got back a 304.  Is the status code 304 or whatever the status code for the cached response is?
> 
> Once again, it should match what I see in developer tools: 304, and 0 for size (Chrome DevTools shows "from cache").
> 
> ig
> 

--
Mark Nottingham    mnot@akamai.com    https://www.mnot.net/

Received on Monday, 25 August 2014 09:29:02 UTC