On Mon, Apr 28, 2014 at 3:00 AM, Gilles Dubuc <gilles(a)wikimedia.org> wrote:
How about merging the cacheable ones (filerepoinfo/imageusage/globalusage)
into a single client call?
imageusage/globalusage are the best candidates for a merge, we use them in
a fully identical way. Not so sure about filerepoinfo, which is fired once
per page (not once per image) and is always the same for a given wiki, so
every client would only request it once per cache lifetime, and it would
never be a Varnish miss. Adding it to every single per-image API request
would just bloat the amount of data that has to be transferred, without any
significant gain. But as Ori says, we might want to test those assumptions
instead of just making them - we should consider how much effort it takes
to set up multiple versions (everything separate, imageusage+globalusage
merged, imageusage+globalusage+filerepoinfo merged, all merged) and compare
them. (Writing the code for it should be pretty simple since the current
response parsing code would keep working; not so sure about the
deployment/measurement parts.)
Wouldn't the server come back with proper caching headers?
Yes, if every component of an API call can be cached in Varnish, then the
whole thing can be cached as well.
If they're aggregated on the client side, since Media Viewer would always
> construct the request string the same way, it would cache across users.
It would, although I wouldn't be absolutely sure of MediaViewer always
constructing the same request. We pass the query parameters to mw.Api (and
eventually $.ajax) in a JS object literal, which has no well-defined
ordering, and Chrome for example is known to iterate object keys
differently from other browsers. Although I think that only happens if you
have numeric keys, so yeah, the URL will probably be stable.
> This would make the number of requests per image go from 4 to 2.
2-ish, yes. (There is still the users request, which is cross-wiki and
would be very hard to merge because of that, but we generate gendered
messages (or message; actually there is just one at the moment) with all
possible genders and only do an API request for the gender if there is a
difference. Only about 10% of languages make use of gender, and most of
them are smaller ones (ru and pl are the largest), so the amount of users
API requests should be negligible.)