You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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).
Activity
bukka commentedon Jul 17, 2023
Here is a list of related issues that would be resolved by this:
bukka commentedon Mar 2, 2025
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_requestnoted 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).