On Mon, Feb 4, 2013 at 5:21 PM, Asher Feldman <afeldman(a)wikimedia.org>wrote;wrote:
On Mon, Feb 4, 2013 at 4:59 PM, Arthur Richards
<arichards(a)wikimedia.org>wrote;wrote:
In the case of the cookie, the header would
actually get set by the
backend
response (from Apache) and I believe Dave cooked up or was planning on
cooking some magic to somehow make that information discernable when
results are cached.
Opting into the mobile beta as it is currently implemented bypasses
varnish caching for all future mobile pageviews for the life of the
cookie. So this probably isn't quite right (at least the "when results are
cached" part.)
Thinking about this further.. So long as all beta optins bypass all caching
and always have to hit an apache, it would be fine for mf to set a response
header reflecting the version of the site the optin cookie triggers (but
only if there's an optin, avoid setting on standard.) I'd just prefer this
to be logged without adding a field to the entire udplog stream that will
generally just be wasted space. Mobile already has one dedicated udplog
field currently intended for zero carriers, wasted log space for nearly
every request. Make it a key/value field that can contain multiple keys,
i.e. "zc:orn;v:b1" (zero carrier = orange whatever, version = beta1)
If by some chance mobile beta gets implemented in a way that doesn't kill
frontend caching for its users (maybe solely via different js behavior
based on the presence of the optin cookie?) the above won't be applicable
anymore, so using the event log facility / pixel service to note beta usage
becomes more appropriate. If beta usage is going to be driven upwards, I
hope this approach is seriously considered. Mobile currently only has
around a 58% edge cache hitrate as it is and it sounds like upcoming
features will place significant new demands on the apaches and for
memcached space. If a non cache busting beta site is doable, go for the
logging method now that will later be compatible with it to avoid having to
change processing methods.