What you are missing is that, in php-fpm, while the interpreter process itself is not destroyed after every request, it does cleanup everything on the php-side

What you are missing is that, in php-fpm, while the interpreter process itself is not destroyed after every request, it does cleanup everything on the php-side (ie, it closes all open descriptors, it unloads all php code, etc.). This is awesome ergonomically (because a past request cannot affect a future one in any way), but has terrible performance because all of the PHP code has to be re-bootstrapped for every request (think: read config files, open db connection, setup the injection-container, etc.). Thus, this thing is like php-fpm but letting you bootstrap once and then just reply to requests within that php-space. Aside from the "now you have an extra gun to shoot your foot with" issue, the other major difference is that php-fpm can execute any php file, whereas this approach requires a different process for each entry point (aka "front controller" in modern frameworks, aka "index.php").