Re: [RFC] Socket activation support for PHP-FPM
| From: | David Strauss | Date: | Thu, 18 Oct 2012 21:39:41 +0000 |
| Subject: | Re: [RFC] Socket activation support for PHP-FPM | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63536@lists.php.net to get a copy of this message | ||
On Thu, Oct 18, 2012 at 2:03 PM, Reinis Rozitis <r@roze.lv> wrote:
> What would be the advantage on using systemd instead of using FPMs native
> 'ondemand' process manager?
The ondemand process manager still keeps considerable memory
allocated, and PHP-FPM currently has some idle CPU load (<1% per
service, but it adds up when you manage 500+ pools on a box) when not
processing requests.
The ondemand process manager doesn't solve the dependency issue
mentioned in the RFC (a web server requiring PHP-FPM to be ready) or
allow privileges to be dropped before PHP-FPM gets invoked at all. The
latter is useful for platform providers that let users configure
PHP-FPM for their individual use cases but want to provide assigned
"listening" sockets.
Socket activation also supports replacing the entire binary (as with a
PHP-FPM security update) without interrupting listening on the socket.
PHP-FPM supports reloading to a limited degree, but I don't think it's
possible to fully replace the executable.
There is also work underway to have socket activation on the base
system spawn or start full containers (like LXC) on-demand. Since
PHP-FPM will, itself, be in the container, something else needs to
listen on its behalf.
Finally, it's a platform consistency issue. As more services move to
socket activation in Fedora and Red Hat, socket units will become a
sort of "common currency" for configuring which services listen where.
--
David Strauss
| david@davidstrauss.net