Extension:Translate's QueryMessageGroupsActionApi module (action=query&meta=messagegroups) takes more than 20 seconds to respond with default parameter set on mediawiki.org (link; the wiki itself can be generalised as a wiki with the Translate extension, page translation enabled, and simply a large number of translatable pages, meaning a large number of message groups). It seems it's possible to push it as far as 35 seconds if all properties (mgprop) are queried.
The high wall time appears to result from a lot of network roundtrips from unbatched SQL and memcached/Redis queries that are done separately for each group (spanning MessageCache, LinkCache, Title::getPageLanguage and probably others at least for the default parameter set). High wall time appears present even with warm caches due to WAN cache network roundtrips.

The resultset should probably be paginated (after all, if a wiki has 30k translatable pages, this single response will try to include all 30k pages). Ideally the queries themselves would be reduced with batching. (Maybe it's possible to do it dirty and split the message group objects into chunks, and warm-up LinkCache + MessageCache).

Creating this ticket through the security issue form as this might be a possible DoS vector via PHP-FPM worker process exhaustion. Whether it actually can be considered that, I'm not sure and it might be debatable. This issue is not compute or DB-intensive.