1

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.

2
  • What is your question? Feb 6, 2015 at 10:31
  • how can i debug or fix the slow responses?
    – robert
    Feb 6, 2015 at 11:06

2 Answers 2

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.

3
  • I have changed the settings according to your recommendations but I can still see the same behaviour. Mod status shows no overloaded backends so far. The error log is working but there is no information about this issue.
    – robert
    Feb 6, 2015 at 14:14
  • I'm pretty sure the access to the cache is synchronized; if the php requests are fast the cache access might become a bottleneck with too many children
    – Stefan
    Feb 7, 2015 at 7:29
  • @Stefan I think you're right, although I imagine its only synchronised when the opcode cache is written to. Unless his scripts are changing frequently, I don't think it should be a bottleneck. At least, I have never seen any concurrency issues attributed to the opcode cache, and Im pushing quite a lot of constant traffic through my 1 proc, 120 children setup
    – carpii
    Feb 7, 2015 at 20:08
1

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .