Apache used to have this with mod_fastcgi (which was written by the original creators of FastCGI) but it's been unmaintained for... a decade, maybe closer to two decades, and the approved replacement (mod_proxy_fcgi) is less ergonomic.

For better or worse, that whole model of doing things is out of fashion. We run our apps as full-on servers now, rather than letting them be hosted by a "real" webserver — and although there's some value in the part-way approach that FastCGI allows (where the app is able to run outside of the webserver, and privilege-separated from it, but still sees an environment like it was hosted by the server), most people aren't really keen on the benefits (like not having to deal with X-Forwarded-everything or path remapping). They just see FastCGI as a niche protocol with no real reason to exist, and would rather proxy HTTP requests over HTTP.

This made me interested as I used to regard CGI as slow, because each invocation is a complete process lifecycle. Or is the CGI process started and kept in there, acting like a REPL but for requests and responses? Caches in play?

PHP has traditionally had it too, although my vague understanding is that people often use PHP application servers these days.

We are certainly using php-fpm to run things. We have this PPA which is one a2enconf php8.2-fpm away from providing PHP service in the classic model. Although I'm pretty sure we customize the fpm/pool.d/www.conf file as well.

I believe Apache resolves the URL to a file, then passes that through to PHP-FPM for execution.

Thus, initial setup of PHP is two-stage, but then it runs like a classic mod_php setup, running anything named *.php through the default pool.

Caveat: It's all code we own, so we haven't worried too hard about isolation between vhosts. It might not be possible to set this up for user dirs.

The FastCGI protocol and its equivalents (such as the much simpler SCGI) put 'CGI' in their name not because the normal model of how their servers worked was like CGI, but because they intended to give the code running in their application servers an environment that often looked a lot like CGI, with headers pre-parsed and extracted for the code and so on. Mechanically your typical FastCGI application server pre-loaded your code at startup (or, hopefully, on hot reload) and then executed it either in newly forked processes or in threads as (FastCGI) requests came in from the web server.

(A still in use logical relative of FastCGI/SCGI is Python's WSGI. Like FastCGI, SCGI, and CGIs, WSGI applications receive header information from the request, along with metadata, in the form of an 'environment', basically key/value pairs, instead of having to parse HTTP headers or something more structured. The WSGI application server that runs your Python WSGI application may well generate the WSGI environment by parsing all of the HTTP headers, but that's not your application's concern.)