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
