I am not convinced this is a great idea.

Warmup at restart makes all operating procedures more complex, and frankly the perfomance gain seems pretty minimal to me, and all to be demonstrated.

We're regularly restarting php-fpm for months now, and I don't see any demonstrable performance degradation caused by it.

I suggest we decline this task until there is a proven need for something like this.

During the first three switch overs the impact and gains was imho quite clearly proven given that on a cold server (at the time HHVM), latencies were in the dozens of seconds up to a minute even for load.php. After the warmup, responses were generally around 10-20ms with some 1-5s outliers due to unrelated reasons.

We're also currently in the midst of at least a dozen perf regressions, with small ones added almost every week, adding up. I have yet to learn that this isn't at least in part caused by the switch to PHP7 and/or the increased or continued use of app server restarts without MediaWiki's hot code paths being refactored to deal with such operational model. From what I can tell, it has at least in part reversed 2-3 years of optimisation work. There is no blame here and I fully agree such restarts should be tolerated, and it would certainly be nice not to need any warm ups. However I can say with certainty that warmups woud significantly shorten the tail of load.php latencies, and real-users from having to wait 60 seconds for the page to render e.g. when they are the first to request a given stylesheet after CDN cache miss and app server restart.

We are currently restarting and wiping php/fpm/opcache/apcu on a regular basis. This isn't great and I think there's room for improvement here.

Having said that, it's would be better if we "simply" don't need warmups and rely less solely local APC for really expensive stuff. Things happening toward that end:

• T248005: Evaluate need for a "local server stash" - This might take the form of a local Memcached that wouldn't be subject to regular restarts.
• Sustainability (MediaWiki-MultiDC) - If we serve from both always there aren't generally switchovers to a cold cluster.

With the above we'd reduce our exposure of timeouts to cases where the server is freshly restarted as a whole. E.g. after maintenance before repooling, or in a future that involves containers. For the general pooling process I think it's worth still looking into a brief warmup of sorts, also for e.g. Etcd (which surprisingly can fail in ways I wasn't aware of - T256900). But.. that's less urgent, so lowering priority on this for now in favour of the above two things.

Link to T240775: RFC: Support PHP 7.4 preload given this other one could be part of some warmup procedure.

I mention also PHP-PM, which is an equivalent of PHP-FPM, essentially with a common loading of PHP classes and services then a loop handling PSR-7 HTTP requests/answers. I quickly tried to handle MW requests within PHP-PM, but it’s not really possible and/or not useful regarding a performance gain. There would be a lot of refactoring of entry points to make it fully compatible, so nothing possible without a long-term refactoring.

Even if a warmup procedure per-se complicates operations, perhaps it could be better partitionned the initial MW loading to have more flexibility and be able to open the following options on an optional basis:

1. 7.4-preload classes
2. use PHP-PM
3. use some warmup script

I know it doesn’t address the issue of heterogeneous deployments, which could weight in the decision.