Yes - thanks Brandon for the detailed explanation. Not urgent but I'd love to see a list of the low hanging fruit for where our pages are inefficient.
> On Apr 29, 2015, at 07:55, Dan Andreescu <dandree...@wikimedia.org> wrote: > > Thanks Brandon, that works for me. The cookie has been great btw, we're > learning great stuff. > >> On Wednesday, April 29, 2015, Brandon Black <bbl...@wikimedia.org> wrote: >> Re: the header name: >> >> Keep in mind this header does get sent back to clients as a response >> header as well. It's probably not a great practice to be using a >> generic-sounding header name like "Last" there and waiting to find out >> what it conflicts with now or in the future (although I'll note that >> the only thing even close in current common use is "Last-Modified"). >> The norm would be at least X-Something for a custom weird header, but >> I feel the WMF-Something prefix is pretty valid in this context as >> well. >> >> We could blend up the best of all of these concerns if we don't care >> about human readability much and just make it something like >> "X-WMFLA", too. Regardless, to be honest our pages are so inefficient >> and huge on average that I'm not overly concerned about the size of >> this one header's name to begin with. There's a ton of lower-hanging >> fruit than that to go after for reducing response sizes... >> >> Re: date formats: >> >> The stringification VCL offers of the current timestamp "now" was >> chosen to match the format used in Expires fields of Cookie headers, >> which is rfc822/rfc1123 -based (with 4 digit years and fixed GMT >> timezone for best compat with various cookie "standards"), so we get >> something like "Wed, 01 Jan 2000 01:01:01 GMT". The form we're using >> for Last-Access is just the easiest transformation we could do on that >> while throwing out the redundancy and excess precision and making it >> compatible with cookie data-value formatting. >> >> In defense of minimizing our processing complexity here: In general >> it's important that we minimize not only the runtime perf hit of our >> frontline VCL (as *every* single HTTP request to us runs through this >> code, including DDoS attacks and celebrity death traffic inrushes and >> such), but also the complexity of the VCL codebase (as it's both >> operations-critical and horribly difficult to work on), so we tend to >> prefer to offload any post-processing that's not strictly necessary to >> elsewhere down the stats pipeline. >> >> -- Brandon >> >> _______________________________________________ >> Analytics mailing list >> Analytics@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/analytics > _______________________________________________ > Analytics mailing list > Analytics@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/analytics
_______________________________________________ Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
