Ubuntu的Apache Worker模式，是一种能够负载多个并发连接的设置。对于访问量和流量较大的服务器，我在装好后都会将Apache的工作模式调整到worker模式以提高服务器负载能力。调整为Worker模式后，PHP将使用FastCGI模块来加载，也就是mod_fcgid。
不过最近遇到一个头疼的问题，就是访问一些执行时间较长的PHP程序的时候，服务器会返回500错误。将PHP的错误输出功能打开，在500错误之前未见到任何错误信息输出。检查Apache的日志文件也没有发现PHP报错。
如此反复的检查了几次后，对PHP文件权限和目录权限进行了调整，也检查了php程序没有问题（之前都一直正常的）。怪事了，难道这500错误解决不了了吗？肯定还有什么原因！
于是，仔细再查阅了apache的错误日志，发现了一行提示：
[warn] mod_fcgid: read data timeout in 40 seconds
这个说明fcgid模块在读取数据的时候超时了。经过多次测试，证明500错误的时候会产生这条记录，看来罪魁祸首就是这个模块了。立马输入命令：
#vim /etc/apache2/mods-available/fcgid.conf
打开后默认的情况如下（我在配置Apache Worker模式的时候，只将PHP解析修改过来了，别的参数都保持默认未动）：
AddHandler fcgid-script .php .py .pl .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IPCConnectTimeout 20
开始觉得IPCConnectTimeout 20的值太小了，于是调整到300，重启Apache后执行出错的php脚本文件，结果还是报500错误。上网仔细一查，这个模块下可用的参数还真不少。另外一个叫做“IPCCommTimeout”的参数吸引了我的注意力，这是FastCGI模块在与程序通讯的时候的超时时间。不管三七二十一，死马当活马医，将这个参数添加后，也设置为300，这样一来文件的内容就如下了：
AddHandler fcgid-script .php .py .pl .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IPCConnectTimeout 300
IPCCommTimeout 300
再次重启apache，运行出错的php脚本测试，成功得到结果，没有再出现500错误，问题解决。为了不使FastCGI模块因为连接超时时间过长而占据服务器内存，又将IPCConnectTimeout参数恢复为默认的20。
总结一下，本次问题出现的关键就是，PHP脚本中需要与别的网址进行通讯，而可能中间时间读取过长导致超时。虽然php脚本中使用函数设置了脚本超时时间，php设置中超时的设置亦很长，不过FastCGI模块还是按照它自己的设置在工作着，导致40秒超时错误。经过参数的添加后，设置为300秒超时时间，足够脚本执行完毕了。
此外，FastCGI下面还有多个参数，常用的参数的意义如下：
IdleTimeout 发呆时限
ProcessLifeTime 一个进程的最长生命周期，过期之后无条件kill
MaxProcessCount 最大进程个数
DefaultMinClassProcessCount 每个程序启动的最小进程个数
DefaultMaxClassProcessCount 每个程序启动的最大进程个数
IPCConnectTimeout 程序响应超时时间
IPCCommTimeout 与程序通讯的最长时间，上面的超时错误就是这个值设置过小造成的
MaxRequestsPerProcess 每个进程最多完成处理个数，达成后自杀
留做备用，以后如果还有FastCGI的问题，再进行检查。
Source：Ren的Linux大杂坛