On Mon, Feb 4, 2013 at 7:12 PM, Asher Feldman <afeldman(a)wikimedia.org>wrote;wrote:
On Mon, Feb 4, 2013 at 5:21 PM, Asher Feldman
<afeldman(a)wikimedia.org
wrote:
> On Mon, Feb 4, 2013 at 4:59 PM, Arthur Richards <arichards(a)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(a)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?
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687