On Tue, Oct 6, 2026 at 4:35 AM Matthieu Napoli <[email protected]> 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.
