如果你在网站的apache错误日志里看到mod_fcgid: read data timeout in 31 seconds，那么八成是php执行时间太短导致的，我们通常会加大php参数max_execution_time）但是，我们可能还是在上传大文件的时候，发现执行时间timeout错误，怎么回事？经过研究，我们发现网站还有一个php程序的执行时间的参数需要修改，这就是IPCCommTimeout，如何修改IPCCommTimeout？请看下图：

点击编辑指令，找到IPCCommTimeout，默认是31，改成351试一试，然后保存，重启apache

提示：上述设置重启apache后，如果测试还有类似错误，可以在apache配置文件的最底部，直接加上 IPCCommTimeout 633 然后重启apache在试一试。

IPCCommTimeout参数原理分析范例：

webmin的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解析修改过来了，别的参数都保持默认未动）：

<IfModule mod_fcgid.c>
AddHandler fcgid-script .php .py .pl .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IPCConnectTimeout 20
</IfModule>

开始觉得IPCConnectTimeout 20的值太小了，于是调整到300，重启Apache后执行出错的php脚本文件，结果还是报500错误。上网仔细一查，这个模块下可用的参数还真不少。另外一个叫做“IPCCommTimeout”的参数吸引了我的注意力，这是FastCGI模块在与程序通讯的时候的超时时间。不管三七二十一，死马当活马医，将这个参数添加后，也设置为300，这样一来文件的内容就如下了：

<IfModule mod_fcgid.c>
AddHandler fcgid-script .php .py .pl .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IPCConnectTimeout 300
IPCCommTimeout 300
</IfModule>

再次重启apache，运行出错的php脚本测试，成功得到结果，没有再出现500错误，问题解决。为了不使FastCGI模块因为连接超时时间过长而占据服务器内存，又将IPCConnectTimeout参数恢复为默认的20。

总结一下，本次问题出现的关键就是，PHP脚本中需要与别的网址进行通讯，而可能中间时间读取过长导致超时。虽然php脚本中使用函数设置了脚本超时时间，php设置中超时的设置亦很长，不过FastCGI模块还是按照它自己的设置在工作着，导致40秒超时错误。经过参数的添加后，设置为300秒超时时间，足够脚本执行完毕了。

此外，FastCGI下面还有多个参数，常用的参数的意义如下：

IdleTimeout 发呆时限
ProcessLifeTime 一个进程的最长生命周期，过期之后无条件kill
MaxProcessCount 最大进程个数
DefaultMinClassProcessCount 每个程序启动的最小进程个数
DefaultMaxClassProcessCount 每个程序启动的最大进程个数
IPCConnectTimeout 程序响应超时时间
IPCCommTimeout 与程序通讯的最长时间，上面的超时错误就是这个值设置过小造成的
MaxRequestsPerProcess 每个进程最多完成处理个数，达成后自杀

留做备用，以后如果还有FastCGI的问题，再进行检查。