> I'm surprised FastCGI isn't more popular for that reason.
FastCGI is more faf to configure where mod_php is more likely to be configured out of the box. Most shared hosting environment are configured entirely out-of-the-box as the market is so saturated and margins so low there is no way to justify anything else. Potential customers who care much about security will most likely be looking for their own dedicated server or VM instead so there isn't really much of a market for a more secure shared host.
Also if packing as many users as possible into as little hardware as possible, which is the only way to make any margin in shared hosting these days, you'll find mod_php more efficient by this measure. You don't have a pool of processes that only specific users can take advantage of, taking up an amount of RAM (however small) each even when not actively in use.
So FastCGI tends to be used less. When I ran PHP I used it, usually as you suggest one pool per vhost, but I was only hosting my own projects and some bits for friends & family, so I didn't need to justify the setup effort against any "bottom line".
More people are starting to realize that FastCGI is one of the keys to good and consistent performance (as much as PHP will allow, anyway) and are recognizing that mod_php for the disaster that it is.
So now more and more popular environments support it - cPanel gained native PHP-FPM support, and commercial shared web hosts are mostly using Litespeed (drop-in replacement for Apache httpd that is evented and invented its own FCGI-like called "LSAPI").
Not sure if I totally agree with mod_php being more efficient for a greedy host either - attaching the PHP runtime to the threaded/forked httpd request handler is very expensive.
You can set the per-pool minimum worker size to 0 with FCGI with a short keepalive, which allows you to keep a low average per-tenant memory footprint, but better performance when many requests arrive at once. That's also basically what Litespeed does.
"one of the keys to good and consistent performance (as much as PHP will allow, anyway)"
I've found that caching any results of logic that's repeated per request makes PHP pretty damn fast. I use apcu, it saves state with an mmap backed cache.
FastCGI is more faf to configure where mod_php is more likely to be configured out of the box. Most shared hosting environment are configured entirely out-of-the-box as the market is so saturated and margins so low there is no way to justify anything else. Potential customers who care much about security will most likely be looking for their own dedicated server or VM instead so there isn't really much of a market for a more secure shared host.
Also if packing as many users as possible into as little hardware as possible, which is the only way to make any margin in shared hosting these days, you'll find mod_php more efficient by this measure. You don't have a pool of processes that only specific users can take advantage of, taking up an amount of RAM (however small) each even when not actively in use.
So FastCGI tends to be used less. When I ran PHP I used it, usually as you suggest one pool per vhost, but I was only hosting my own projects and some bits for friends & family, so I didn't need to justify the setup effort against any "bottom line".