lighttpd + PHP-fcgi slow response

Question

We have a problem regarding lighttpd as the webserver with php5 as backend via fast-cgi. Sometimes the server's response is taking more than 5 seconds (up to 20 seconds) when requesting a simple file that calls phpinfo();. The server log does not show any errors and the HTTP response is 200.

When I request a static html file without any PHP content, there is no problem and all the requests are being served fast.

This is the lighttpd-fcgi Config:

fastcgi.debug = 1 fastcgi.server += ( ".php" => (( "bin-path" => "/usr/bin/php-cgi", "socket" => "/tmp/php.socket", "max-procs" => 7, "bin-environment" => ( "PHP_FCGI_CHILDREN" => "5", "PHP_FCGI_MAX_REQUESTS" => "5000" ) )) ) 

The server is running Debian 7 64 bit.

Answer 1

Check you don't have any orphaned fcgi handlers, easiest way is to stop lighttpd and then `ps auX' and look for php-cgi. Kill them off if any exist, then start lighty up again.

Set up a server-status handler in your lighty config. This will allow you to refresh a page and see all connections currently being handled, and what state they are in.. http://redmine.lighttpd.net/projects/1/wiki/Docs_ModStatus

Check lighty is actually able to write to its error log. When stopping and restarting lighty, it should leave a log in error.log. This way if your fcgi-handlers are all tied up and lighty has to stall a request, it will log this.

I wouldn't recommend max-procs => 7 unless youve a very good reason for it. Try lowering max-procs to 1, and raising your FCGI_CHILDREN significantly. My high traffic server is configured to use max-procs 1 and FCGI_CHILDREN 120. I realise this contradicts the lighttpd wiki, however that is edited by users, whereas my suggestion is based on empirical evidence and also advice directly from the lighty team.

The other thing to bear in mind is that there is a separate opcode cache being maintained for each process. So by reducing it to 1, all scripts are using the same opcode cache, which means less time spent compiling and pruning 7 different caches.

Answer 2

Each php worker process can handle only one request at a time; each "proc" (in your case 7) usually has a master process (which doesn't handle requests) and PHP_FCGI_CHILDREN (in your case 5) worker process, which makes a total of 35 worker processes.

lighttpd allocates a separate socket for each "proc", and each socket has its own request queue. So if it takes a long time to handle your request it is most likely that the selected backend has a long queue of requests to handle.

So just do some simple math: if one request takes php about 2 seconds to handle, your setup can handle #workercount / #timeperrequest = 17.5 requests/sec.

In order to increase number of requests per second you have two options:

• start more php worker processes (and make sure you have enough memory/CPU for them to run, watch top and other tools)
• improve the response time of single requests (look out for slow SQL queries, http requests to internal services, ...); again check for memory and CPU bottlenecks with top - if your server starts swapping everything will get super slow.

PS: don't put your sockets into /tmp; put them into (/var)/run/lighttpd/ instead and make sure only your lighttpd user (www-data) has access, see CVE-2013-1427