On Fri, May 2, 2014 at 2:38 AM, Gilles Dubuc <gilles@wikimedia.org> wrote:
More spiky, yet quite stable, but my understanding is that Media Viewer is far from being the only consumer of that API call. Not sure how we could differentiate the effect of Media Viewer from the rest of the traffic for this one.

I stupidly named the JS class that gets user information UserInfo, but we are actually using the users API:
https://graphite.wikimedia.org/render/?width=586&height=308&_salt=1397062971.274&from=-7days&target=MediaWiki.API.users.tp50
The big drop is because we don't request it anymore for languages where it won't actually make a difference to the translation. (That and caching.) Curently the only big user is plwiki; the other one will be ruwiki. The largest languages won't use it. (This depends on the translations so it might change at any time without any MediaViewer code/config change, but that is unlikely to happen.)

Confirmed this manually; our client-side stats don't show much difference in the number of users API requests though, I wonder whether there is something wrong with our logging:
http://multimedia-metrics.wmflabs.org/dashboards/mmv#overall_network_performance-graphs-tab

This one is the odd bird compared to the other ones, as it's noticeably growing, but the scale shows us that it's called a lot less than the others. The effect of the caching launch on the 24th is counter-intuitive: there are more invocations and they're more spiky afterwards. Might be worth double-checking that caching was done right for that one.

I confirmed manually that filerepoinfo is cached both in Varnish and the user's browser. We might be seeing usage from some other source - since MediaViewer was deployed to frwiki with the normal deploy train, any number of other extensions might have changed their behavior.

Again, our own stats don't show any reduction. The way we differentiate cached and uncached requests might be wrong.