我们有一个关于lighttpd作为php5作为后端通过fast-cgi的networking服务器的问题。 有时，当请求调用phpinfo();的简单文件时，服务器的响应时间超过5秒（最多20秒phpinfo(); 。 服务器日志不显示任何错误，并且HTTP响应为200。
当我请求一个没有任何PHP内容的静态HTML文件时，没有问题，并且所有的请求都被快速地处理。
这是lighttpd-fcgiconfiguration：
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" ) )) )
该服务器正在运行Debian 7 64位。
检查你没有任何孤立的fcgi处理程序，最简单的方法是停止lighttpd，然后`ps auX'并查找php-cgi。 如果有的话，把它们杀掉，然后重新开始。
在lightyconfiguration中设置服务器状态处理程序。 这将允许您刷新一个页面，并查看当前正在处理的所有连接，以及它们处于什么状态.. http://redmine.lighttpd.net/projects/1/wiki/Docs_ModStatus
检查lighty实际上是能够写入其错误日志。 在停止并重新启动lighty时，应该在error.log中保留一个日志。 这样，如果你的fcgi-handler被捆绑在一起，并且lighty必须拖延一个请求，它会logging下来。
我不会推荐max-procs => 7，除非你有一个很好的理由。 尝试降低max-procs为1，并显着提高您的FCGI_CHILDREN。 我的高stream量服务器被configuration为使用max-procs 1和FCGI_CHILDREN 120.我意识到这与用户编辑的lighttpd wiki相矛盾，而我的build议是基于经validation据和直接来自lighty团队的build议。
另外要记住的是每个进程都有一个独立的操作码caching。 所以通过将其减less到1，所有脚本都使用相同的操作码caching，这意味着编译和修剪7个不同的caching所花的时间更less。
每个php工作进程一次只能处理一个请求; 每个“proc”（在你的情况7）通常有一个主进程（不处理请求）和PHP_FCGI_CHILDREN （在你的情况5）工作进程，这总共有35个工作进程。
lighttpd为每个“proc”分配一个单独的套接字，每个套接字都有自己的请求队列。 因此，如果处理请求需要很长时间，则所选后端很可能需要处理很长的请求队列。
所以只要做一些简单的计算：如果一个请求需要约2秒的PHP来处理，你的设置可以处理#workercount / #timeperrequest = 17.5请求/秒。
为了增加每秒请求的数量，你有两个select：
top和其他工具） PS：不要把你的套接字插入/tmp ; 将它们放入(/var)/run/lighttpd/ ，确保只有您的lighttpd用户（ www-data ）有权访问，请参阅CVE-2013-1427