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

How about merging the cacheable ones (filerepoinfo/imageusage/globalusage) into a single client call? Wouldn't the server come back with proper caching headers? If not, we can combine it into a meta server-side call with caching turned on, right?. 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.

This would make the number of requests per image go from 4 to 2.

Failing that, I'm in favor of dropping imageusage/globalusage, which have only very limited usefulness in the way they're currently implemented, which is a kind of placeholder until proper search results can be used.


On Sat, Apr 26, 2014 at 4:32 AM, Gergo Tisza <gtisza@wikimedia.org> wrote:
On Fri, Apr 25, 2014 at 6:27 PM, Ori Livneh <ori@wikimedia.org> wrote:
On Thu, Apr 17, 2014 at 1:13 AM, Gilles Dubuc <gilles@wikimedia.org> 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>.

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.

_______________________________________________
Multimedia mailing list
Multimedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia