Php – lighttpd + PHP-fcgi slow response

fastcgifcgilighttpdPHP

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.

Best Answer

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.

Related Topic