Page MenuHomePhabricator

When fetching siteinfo from the MediaWiki API, set the `maxage` and `smaxage` parameters.
Closed, ResolvedPublic

Description

As explained in T244204, the mobile applications (both Android and iOS, as far as I can tell) make a significant amount of requests to the MediaWiki API to fetch siteinfo.

Given they use urls like:

https://en.wikipedia.org/w/api.php?format=json&formatversion=2&errorformat=plaintext&action=query&meta=siteinfo

they get a response that is not cacheable by our caching infrastructure. This means that every time that an application needs to fetch those information, the request has to make it back all the way to the main datacenters, which is a cost both for the user[1] and for us, in terms of computational resources.

As explained in T244204#5877009, if you add &smaxage=N&maxage=N to the url, your result will be cached at the edge datacenters for N seconds.

Both applications should switch to using a cacheable url at the very least for the siteinfo requests.

[1] To quantify the advantage for users: a small benchmark from my mobile connection (a good 4G network in Europe) the mean time to fetch this information is 440 ms using the current url, while it drops to 314 ms if we use a cacheable url.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@Joe Thanks for that! We'll update our code asap.
Since we use the siteinfo data for things like the canonical language name of the wiki (i.e. things that are highly unlikely to change very frequently), we can use a very generous maxage, such as the 86400 (1 day) example mentioned in the other task.

jbond triaged this task as Medium priority.Feb 13 2020, 11:44 AM

@Joe could MediaWiki use a default value other than 0 if a client doesn't pass maxage and smaxage?

@JoeWalsh There's a separate task about the MW default where I just asked a similar question (see T244204#5894396).

I didn't see yours until now, but in short: Yes, it could, and I think we should! (Although it's possible there's another factor at play, which I described there.)