Nginx wont auto-spawn workers if they don’t exist so you do need to start them outside of Nginx. Many people use the spawn-fastcgi script or some other startup script to do it, but the smart people use a process monitor.
There are a lot of people using supervisord for keeping their fastcgi PHP workers working and most of them are in my opinion doing it wrong. Not very wrong, just a few things that could be done better.
If you simply wanted PHP running as a certain user suphp and similar solutions are perfectly fine. FastCGI is slightly faster, but is more complex to manage – you need to keep it running. The way most people do it is something like the following:
[fcgi-program:php5-cgi] socket=tcp://127.0.0.1:9000 command=/usr/bin/php5-cgi numprocs=5 priority=999 process_name=%(program_name)s_%(process_num)02d user=www-data autorestart=true autostart=true startsecs=1 startretries=3 stopsignal=QUIT stopwaitsecs=10 redirect_stderr=true stdout_logfile=/var/log/php5-cgi.log stdout_logfile_maxbytes=10MB
Which spawns many separate PHP threads and it works. The problem with it is that if you use APC or similar opcode caches or in memory caches they are done on a per interpreter basis and as such if you spawn 20 PHP processes, you will have 20 separate opcode caches each with similar information.
A better way is to use the ability of the FastCGI PHP binary to manage its own children:
[fcgi-program:php-cgi] command=/usr/bin/php-cgi -b 127.0.0.1:9000 socket=tcp://127.0.0.1:9000 process_name=%(program_name)s user=www-data numprocs=1 priority=999 autostart=true autorestart=true startsecs=1 startretries=3 exitcodes=0,2 stopsignal=QUIT stopwaitsecs=10 redirect_stderr=true stdout_logfile=/var/log/supervisor/php.log stdout_logfile_maxbytes=5MB stdout_logfile_backups=10 environment=PHP_FCGI_CHILDREN=50,PHP_FCGI_MAX_REQUESTS=500
If you use APC or similar op-code caches this is much more efficient as only one cache is kept and has the side effect of much faster restarts within supervisord.