FPM pool manager

[bukka]

Description

FPM allows creating multiple pools which except other things provides some sort of separation between processes. There is still however lots of shared resources because MINIT happens in master process which is common for all pools. That's problematic for extension like opcache that creates shared memory between all pools. This gets even more problematic if pools have different users / groups configured due to potential permission errors when accessing shared resources.

The proposed solution for this problem is to create extra layer between master and children processes. It would be a pool manager process that would handle creation of children, logs, MINIT and other things currently handled by master process. Master process would then become very thin and just supervise pool manager(s) as well as some other common things (e.g. loading configuration). This would be also beneficial for improving graceful reload and extending of status and access logging for resource information related to the whole pool like for example request for adding utime and stime.

[bukka]

Here is a list of related issues that would be resolved by this:

• https://bugs.php.net/bug.php?id=75440 - Fpm reload should be graceful, not killing running processes (possibly master could just re-read config and let proc mangers deal with it
• https://bugs.php.net/bug.php?id=60961 - Graceful Restart (USR2) isn't very graceful (similar to above bug listing problems with graceful reload)
• php-fpm: graceful restart without blocking/losing requests #3758 - php-fpm: graceful restart without blocking/losing requests (Mike's old PR with some useful discussion about reload)
• https://bugs.php.net/bug.php?id=74778 - opcache_clear() puts php-fpm master in a cpu loop
• https://bugs.php.net/bug.php?id=74709 - PHP-FPM process eating 100% CPU attempting to use kill_all_lockers (separating opache MINIT)
• php-fpm trying to kill another user's pool results in an infinite loop and 99% cpu usage #8072 - php-fpm trying to kill another user's pool results in an infinite loop and 99% cpu usage (separating opache MINIT)

[bukka]

I will throw one more idea here as we have been just discussing this privately on the foundation Slack.

This is in relation to early bootstrapping as initially proposed in #6772 . The problem with that implementation is that it does not really work well for persistent connections (keep-alive) because it just moves delay to the web server. Effectively web server does not know that FPM is doing other things and it just sends request to the open connection but it doesn't read it during the bootstrapping. We have got a similar problem already for fastcgi_finish_request noted in #10335 (comment) .

The solution for this would fit to this pool manager that could act as some sort of proxy balancer process that would be able to distribute request between children and be aware when they are ready. That could open path to other interesting features like TLS (or even QUIC) support and multiplexing (both would of course require web server support too). Specifically TLS (with client cert support) would resolve a long term problem of running FPM on open networks which was reported many time and we have got lots of open issues for that.

Implementation wise we would need some some high performant event loop (would be probably good to look to io_uring or threads offloading).