On Fri, May 2, 2014 at 2:38 AM, Gilles Dubuc <gilles(a)wikimedia.org> wrote:
- userinfo
https://graphite.wikimedia.org/render/?width=586&height=308&_salt=1…
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=1…
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_perfor…
-filerepoinfo:
https://graphite.wikimedia.org/render/?width=586&height=308&_salt=1…
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.