I see a "time": "<current timestamp>" in the output by siteinfo. I don't know if and how anyone uses that timestamp, but the current time is also available via the curtimestamp parameter with any query (and this is the way suggested by the documentation for action=edit), so after a deprecation period the timestamp in the siteinfo output can probably be safely removed. But it is something to keep in mind when caching the output.

Caching in the caching layer might have been helpful for these specific requests, but would that merely have deferred the problem to the next request to some other module? Caching inside MediaWiki wouldn't have had any effect, as far as I can tell. There doesn't seem to have been any slowdown at the PHP level, based on logged response times for action=query&meta=siteinfo queries.

(queried from hadoop/beeline with select day, hour, count(*) as ct, percentile( backend_time_ms, 0.5 ) as p50, percentile( backend_time_ms, 0.75 ) as p75, percentile( backend_time_ms, 0.95 ) as p95, percentile( backend_time_ms, 0.99 ) as p99 from event.mediawiki_api_request WHERE year=2020 AND month=1 AND (day=26 AND hour>10 or day=27 and hour<10) AND params['action'] = 'query' and params['meta'] = 'siteinfo' and isnull(params['list']) and isnull(params['prop']) group by day, hour order by day, hour limit 100;, then lightly reformatted)

As for actually implementing this: HTTP caching in the Action API is, for historical reasons, somewhat lackluster. Currently for action=query&meta=siteinfo, the client must specify maxage and/or smaxage parameters to request cached results.

We can work around that, but for query submodules in particular it'll be somewhat roundabout: we'll have to add something to ApiQueryBase to return a "default" for when maxage/smaxage aren't specified, then have ApiQuery combine these for all used modules much like it already does for the caching mode.

In T244204#5847496, @Schnark wrote:

I see a "time": "<current timestamp>" in the output by siteinfo.

Meh. We might do well to keep it as an indication of when exactly the request was cached.

In T244204#5848838, @Anomie wrote:

[cut]

As for actually implementing this: HTTP caching in the Action API is, for historical reasons, somewhat lackluster. Currently for action=query&meta=siteinfo, the client must specify maxage and/or smaxage parameters to request cached results.

This is great - I wasn't aware of those action api parameters, and in fact https://en.wikipedia.org/w/api.php?format=json&formatversion=2&errorformat=plaintext&action=query&meta=siteinfo&maxage=86400&smaxage=86400 gets correctly cached for one day.

We can then ask our mobile apps developers to change the calls in the application to set a sensible caching time. This will reduce the calls to the API layer and also speed up the applications for people in Europe and Asia.

To be clear, I think what @Anomie described is a perfectly valid way of handling caching in this case - it leaves it as a option to the client, although it does so in a very cache-inefficient way (but that's a common issue with the action API caching, as stated above).

I think we should check external users of siteinfo, and have those switch to a cachable URL, while leaving internal consumers untouched - they should cache the result themselves after having fetched it from the application layer.

As of now, the only outstanding case seem to be the mobile applications, as tracked in T245033.

@Pchelolo feel free to close this task if you see no other outstanding client.

The Api classes in MediaWiki also have a way to enable caching by default, via setCacheMaxAge(). This is used by ApiOpenSearch.

If the siteinfo data is safe to cache, should we enable that by default in MW core? (Doing so currently means any manual smaxage query parameter will be ignored, but that's probably fine?)

I just looked ApiQuerySiteinfo and ApiMain, and noticed something else:

1. It looks like use of smaxage is ignored for API modules that return non-public in their getCacheMode() This makes sense but also means it might not work for this query.
2. ApiQuerySiteinfo::getCacheMode is public by default (though without any maxage), but if you set prop=interwikimap it becomes private because "this depends on user language".

Should we set setCacheMaxAge() by default in ApiQuerySiteinfo?

Are the mobile apps are using this parameter, and do I understand correctly that those won't be CDN-cacheable? If so, is there a way around that?

In T244204#5894396, @Krinkle wrote:

Should we set setCacheMaxAge() by default in ApiQuerySiteinfo?

No, because that would incorrectly set the cache max age for queries that include siteinfo and other query submodules too. As I said earlier,

In T244204#5848838, @Anomie wrote:

We can work around that, but for query submodules in particular it'll be somewhat roundabout: we'll have to add something to ApiQueryBase to return a "default" for when maxage/smaxage aren't specified, then have ApiQuery combine these for all used modules much like it already does for the caching mode.

In T244204#5921402, @Pchelolo wrote:

The only outstanding question left in this ticket is whether it's possible to set a non-zero default max-age in MW, which @Anomie declined in T244204#5894471

I declined calling setCacheMaxAge() from ApiQuerySiteinfo. I didn't decline setting a non-zero default max-age in the more roundabout manner I described in the quote at the end of that comment.

Right, hence removing good first task per its definition. :)