Re: [RFC] Single binary for CLI and FPM

On Tue, Oct 6, 2026 at 4:35 AM Matthieu Napoli <matthieu@mnapoli.fr> wrote: > > Hi internals, > > I'd like to start the discussion on a new RFC: > https://wiki.php.net/rfc/single-binary-cli-fpm > > It proposes a new --enable-cli-fpm build option that links the > FPM SAPI into the php executable. A combined > php binary runs FPM when its first argument is > --fpm, or when it is invoked under a name starting with > php-fpm (e.g. a php-fpm symlink to > php). Everything else is the CLI, unchanged. The standalone > php-fpm executable is still built. > > ``` > php script.php # CLI, as today > php --fpm --nodaemonize -y /etc/php-fpm.conf # FPM > > ln -s php php-fpm > ./php-fpm --nodaemonize -y /etc/php-fpm.conf # FPM, through a symlink > ``` > > The motivation is that the two executables share almost all their code. I did some measurements > with [Bref](https://bref.sh) on AWS Lambda to illustrate its usefulness for this specific system. > Shipping one binary instead of two: > > - removes one of the two ~26 MB executables from the runtime (leaving more room under the 250 > MB limit for application code) > - cuts the cold start of a minimal FPM application by 70 ms (-25%), because FPM no longer loads > a second copy of the engine right after the CLI loaded it > > It makes a difference on AWS Lambda, it might also help on other systems where boot speed > (autoscaling, serverless, etc.) or disk size is important. > > And from a simplicity perspective I like the idea of having a single binary with FPM > "built-in". > > There's a secondary vote on enabling the option by default, as Marc suggested when I > requested RFC karma. > > I'd especially welcome feedback from packagers: > > 1. Would you consider shipping php-fpm as a symlink to a > combined php binary, with the FPM package keeping only the > configuration and service files? > 2. Should this stay opt-in, or be enabled by default? > > The implementation is at > https://github.com/php/php-src/pull/23558 (thanks Jakub and Marc for > the reviews so far). > > Thanks, > Matthieu Napoli Perhaps there's another alternative: libzend.so. It was actually possible to build this in the past. I assume it was partly removed in the never-ending quest for more performance, but it is something I have considered for other reasons as well. One reason is that it allows (most) extensions to link their symbols to libzend.so instead of leaving them undefined for the binary to provide. In any case, the performance penalty would be something to measure, but I would prefer this solution if it's viable, personally.