Re: [RFC] Single binary for CLI and FPM

Hi Matthieu, > 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? > I like the direction of the proposal and believe it will be a positive change. In Debian/Ubuntu, shipping SAPIs as separate packages (php-cli, php-fpm, libapache2-mod-php8.6, etc) is the norm, and to not break the packages, I would imagine symlinking would be necessary one way or the other. Alternately, php-fpm could be a shim that calls CLI with --fpm flag, and it depends on php-cli package. I'm also concerned about CLI and FPM parameters. For example, CLI has -F argument is to execute a file, but FPM's -F flag is an alias to --nodaemonize. Changing what they do based on the binary/symlink name or another flag (such as --fpm) is not really a good idea. Thank you, Ayesh.