[devicenull]

FastCGI makes little to no sense on shared web hosting machines. With FastCGI, each user on the machine needs at least one long-running process to handle requests. This is a waste when you consider that large numbers of the sites may be idle 99% of the time. With CGI, you only have PHP processes running when they are actually handling requests, it's really a much better solution for shared hosting.

[mikey_p]

With PHP 5.3.9 or 5.3.10 and php-fpm a new method of process management called ondemand was introduced that handles this use care very well. With a super short idle timeout (a few seconds) this could work very well for shared hosting, but I doubt there are many folks using it since it does still require the process manager to stay running in order to start the workers (this makes it hard to have user configurable php.ini settings since it would require restarting the master).

See http://www.php.net/manual/en/install.fpm.configuration.php under 'pool' group and the 'pm' setting.

[rmccue]

You can send a signal to php-fpm to reload configuration without restarting (at least, the way I read it). My /etc/init.d/php-fpm has "reload" with `kill -USR2 $PHP_PID`

[kbolino]

What is it wasting? If the process is idle, then it is only taking up space in memory.

If that space isn't needed, then the cost is nil (it takes the same amount of power to store a 1 as a 0; the real power cost is in moving data in and out of memory, not in storing it).

If the space is needed, then the idle process can be swapped out to disk. So again, no practical cost.

FastCGI may not be the best solution, but CGI is not an improvement (the overhead of starting a new runtime to handle every request will introduce a lot of latency, which will be especially noticeable on pages that make a lot of asynchronous requests).

[DougBTX]

> then the idle process can be swapped out to disk.

If the FastCGI process is swapped out, does it still have a performance benefit?

[kbolino]

Caveat: As they say, one good test is worth a thousand expert opinions, and I'm no expert.

I'm inclined to say yes, it would still have a benefit. My thoughts:

- Swapping the FastCGI process back in shouldn't be any worse than loading a CGI process cold and initializing it (disk caching will probably be no help to CGI here: with so little free memory, the cache will be small or nonexistent and aggressively purged);

- Once swapped in, the FastCGI process will be able to handle multiple requests in less time and less memory than it would take just to start the many CGI processes necessary to do the same work.

Also, if the performance of your server is an issue, your FastCGI process should never be in a situation where it would be swapped out. You need to add more memory, and/or reduce the other loads on your server.