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
<dandreescu(a)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
<bblack(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
_______________________________________________
Analytics mailing list
Analytics(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics