[RFC] Socket activation support for PHP-FPM

On Thu, Oct 18, 2012 at 2:03 PM, Reinis Rozitis <r@roze.lv> wrote:

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.

On Thu, Oct 18, 2012 at 4:06 PM, David Muir <davidkmuir@gmail.com> wrote:

I'm aware of Upstart having some basic socket activation support, and I'm happy to provide advice on the PHP-FPM/Linux side for integrating it in follow-up work. All socket activation basically works the same way, in the sense of a file descriptor getting handed into the daemon. I eventually foresee either a standardization of environmental variables for handing in sockets or a "libsocketactivation" that looks for the appropriate environmental variables for your superserver or init daemon.

I didn't really think about it because we've always run an instance of PHP-FPM per pool to have such capability, but that's certainly the case. If template-based services (not discussed in or related to the RFC) like those in systemd become more widespread, I'd imagine a lot of applications like nginx, Apache, and PHP-FPM could cede their internal virtual host/multi-pool models in favor of standardized provisioning of multiple instances.