On Fri, Apr 25, 2014 at 6:27 PM, Ori Livneh <ori(a)wikimedia.org> wrote:
On Thu, Apr 17, 2014 at 1:13 AM, Gilles Dubuc
<gilles(a)wikimedia.org>wrote;wrote:
When the user opens media viewer, but there are 4 API calls per image and
we preload the next/previous images fairly quickly after opening one. So
generally within a few seconds, you're looking at 12 API calls when opening
Media Viewer.
That's way too high. Since you're planning to deploy this soon, we should
figure out how to meet the requirements using the infrastructure that we
have rather than the one we'd like to have. Have you considered adding a
MediaWiki API module to your extension that composes the data into a single
response? You could do this without duplicating code by
constructing DerivativeRequest objects to each endpoint, as described in <
https://www.mediawiki.org/wiki/API:Calling_internally>gt;.
This is the current behavior (in master):
- one filerepoinfo API call per page
- one imageinfo, imageusage, globalusage API call per image
- depending on the language, there might be a users API call per image,
possibly to another wiki (Commons).
- there might be another imageinfo call to get sizes for a specific
thumbnail. This on the file type/size, should be very rare.
All but the imageinfo call are cached on Varnish for one day. (Caching
imageinfo for more than a few minutes would be more problematic as users
would expect to see changes to image description etc. immediately.)
Merging filerepoinfo/imageinfo/imageusage/globalusage into a single API
call should be possible even on the client side, but it would mean that we
cannot cache anything; not sure how that affects server load (I suppose the
API has its own caching mechanism, but even that must have some overhead
compared to Varnish). Similarly, merging multiple calls to the same API
would be possible but would make caching mostly useless.
The users API call can go to a different wiki, so would be very difficult
to merge it directly with the other calls. We only use it to get the gender
of the uploader, though; maybe that information could be added to the
imageinfo API, which has its own mechanism of handling remote filerepos.
If you absolutely had to cut some functionality out in order to roll this
out more broadly, what would you eliminate?
IMO we could get rid of the users, imageusage and globalusage calls without
much trouble. The first one is only used for gender-correct translations.
The other two are used to show some pages which use the image - since there
is not enough place on the UI to show more than a few, this is not a very
useful feature as it exists now.
We could also only enable preloading after the user has used prev/next
navigation for the first time.