Nginx+FastCGI到底是谁影响超时时间

242次阅读

没有评论

共计 2826 个字符，预计需要花费 8 分钟才能阅读完成。

需求：

一个 php 程序要跑一段时间，但是时间不确定。

问题：

当该 php 程序运行超过一段时间被强制断开连接。

PHP 本身超时处理

在 php.ini 中，有一个参数 max_execution_time 可以设置 PHP 脚本的最大执行时间，但是，在 php-cgi(php-fpm) 中，该参数不会起效。真正能够控制 PHP 脚本最大执行时：

就是说如果是使用 mod_php5.so 的模式运行 max_execution_time 是会生效的，但是如果是 php-fpm 模式中运行时不生效的。

max_execution_time

计算的只是 PHP 脚本本身执行的时间，执行之外的时间都不会计算在内。哪些属于执行之外的时间呢？包含 sleep、数据交互、socket 交互等等。

request_terminate_timeout = 0 即为不受时间控制，永不超时

request_terminate_timeout 引起的资源问题

request_terminate_timeout 的值如果设置为 0 或者过长的时间，可能会引起 file_get_contents 的资源问题。

如果 file_get_contents 请求的远程资源如果反应过慢，file_get_contents 就会一直卡在那里不会超时。我们知道 php.ini 里面 max_execution_time 可以设置 PHP 脚本的最大执行时间，但是，在 php-cgi(php-fpm) 中，该参数不会起效。真正能够控制 PHP 脚本最大执行时间的是 php-fpm.conf 配置文件中的 request_terminate_timeout 参数。

request_terminate_timeout 默认值为 0 秒，也就是说，PHP 脚本会一直执行下去。这样，当所有的 php-cgi 进程都卡在 file_get_contents() 函数时，这台 Nginx+PHP 的 WebServer 已经无法再处理新的 PHP 请求了，Nginx 将给用户返回“502 Bad Gateway”。修改该参数，设置一个 PHP 脚本最大执行时间是必要的，但是，治标不治本。例如改成 30s，如果发生 file_get_contents() 获取网页内容较慢的情况，这就意味着 150 个 php-cgi 进程，每秒钟只能处理 5 个请求，WebServer 同样很难避免”502 Bad Gateway”。解决办法是 request_terminate_timeout 设置为 10s 或者一个合理的值，或者给 file_get_contents 加一个超时参数

如果常有请求超时，请打开 php-fpm 的慢日志，通过日志来确认评估超时时间。

Ngnix 中的 fastcgi 请求时间控制

fastcgi_connect_timeout

语法：fastcgi_connect_timeout time

默认值：fastcgi_connect_timeout 60

使用字段：http, server, location

指定同 FastCGI 服务器的连接超时时间，这个值不能超过 75 秒。

fastcgi_read_timeout

语法：fastcgi_read_timeout time

默认值：fastcgi_read_timeout 60

使用字段：http, server, location

前端 FastCGI 服务器的响应超时时间，如果有一些直到它们运行完才有输出的长时间运行的 FastCGI 进程，或者在错误日志中出现前端服务器响应超时错误，可能需要调整这个值。