On Tue, Oct 6, 2026 at 7:59 PM Nicolas Grekas <[email protected]> wrote:
> > > Le mar. 6 oct. 2026, 18:30, Larry Garfield <[email protected]> a > écrit : > >> On Tue, Oct 6, 2026, at 5:32 AM, Matthieu Napoli 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 >> >> I can see the value here, and I am not opposed in concept. My one >> question is that this essentially privileges the FPM SAPI, right at the >> time that we're seeing more and more alternate SAPIs. (FrankenPHP, Swoole, >> various async tools that just run on the CLI, etc.). Would there be any >> negative impact for them? If at some point in the future another SAPI (eg, >> FrankenPHP or something similar to it) became a first-class web-serving >> SAPI in php-src, would we then need to package multiple variants? >> (FPM-CLI, Franken-CLI, etc.). >> >> I just want to make sure we don't inadvertently lock in FPM as The Way >> PHP Runs(tm) just at the time that it no longer is. >> >> --Larry Garfield >> > > > I share this concern. > The fpm binary should embed the cli if we go this way. Not the other way > around. > Same as frankenphp shipping also the cli, especially since it's been made > easier in PHP 8.6. > > I was actually thinking about this and it really makes more sense and also better in terms of implementation as we will just do what FrankenPHP does. Kind regards, Jakub
