On Mon, Feb 4, 2013 at 7:12 PM, Asher Feldman afeldman@wikimedia.orgwrote:
On Mon, Feb 4, 2013 at 5:21 PM, Asher Feldman <afeldman@wikimedia.org
wrote:
On Mon, Feb 4, 2013 at 4:59 PM, Arthur Richards <arichards@wikimedia.org 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. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
OK - this is all making a lot more sense to me now, thanks for your clarifications and suggestions, Asher.
So, from the mobile team's perspective a straightforward implementation to get us to our goal might be to: 1) add a query parameter to identify 'secondary' API hits (eg an API request for page content made after an initial request for that page was made, all other requests stay the same) 2) use the header solution to identify beta/alpha cookies (HTTP header set by backend response when user is opted in).
One thing I'd like to double check though is that 'Opting into the mobile beta as it is currently implemented bypasses varnish caching for all future mobile pageviews for the life of the cookie' - I thought the Varnish cache was just varied by the optin cookies, not totally bypassed. I've looked at headers from some sample requests I've made with the beta opt-in and I'm not seeing any cache hits, so I gather you are correct. Can you please confirm this?
Analytics folks, is this workable from your perspective?