On Thu, Apr 17, 2014 at 11:38 AM, Max Semenik <msemenik@wikimedia.org> wrote:

On Thu, Apr 17, 2014 at 11:21 AM, Gergo Tisza <gtisza@wikimedia.org> wrote:

Four of those could be combined, but that would complicate the code a lot even in its current state (and much more if we do some sort of caching, and need to deal with invalidation, which is different for every API query).

I am not sure there is much benefit to it; when cached, those queries should be fast anyway, and when not cached, the single query might actually be slower since everything happens sequentially in PHP, while the independent JS requests would be parallel to some extent. (We should probably measure this.)

Wrong. Every request has an overhead in MediaWiki, Apache and Varnish.

On the server side, sure. On the client side, the overhead is tiny and the requests will be spread out over multiple machines and processed in parallel, so the actual performance might be better.

I would expect the servers to be able to deal with a couple API requests per user action (I think this approach of firing small separate queries is pretty much standard these days - as a quick comparison, Flickr fires 12 AJAX requests per image). Is that not the case?

Also, batching everything together makes efficient caching very hard. filerepoinfo is per-wiki and could be cached pretty much forever, imageusage/globalusage can be cached for days because we do not care terribly whether it is up to date, imageinfo cannot be cached for long because description, license etc. is based on it. If you batch everything together, you get the lowest common denominator in caching. I would expect the overhead of splitting a query into multiple ones to be smaller than the overhead of Apache/MediaWiki handling of a query (or query part) which could be handled entirely by Varnish.