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.
