今天调式PHP程序时，发现后台会自动停止运行，尝试设置过max_execution_time，但无效，

后台无任何日志，前台提示如下

jquery.min.js:3 POST http://sitemap.2kb.com

 net::ERR_INCOMPLETE_CHUNKED_ENCODING 200 (OK)

后面设置了一下request_terminate_timeout成功跑完PHP后台程序

这边作一下关于PHP超时运行相关的记录

PHP-FPM 模式下PHP超时

PHP-FPM 模式，max_execution_time 参数不能完全控制，其控制的是进程的CPU占用时间， 默认值30秒；

真正起作用的是 php-fpm.conf 里的request_terminate_timeout

其的含义是 

The timeout (in seconds) for serving a single request after which the worker process will be terminated； 默认值0，即off；

既然 request_terminate_timeout = 0 &  max_execution_time = 30s ，那么默认情况下 

很难准确地说 PHP 脚本在被 PHP FPM 终结掉前，到底执行时间是多少秒。

set_time_limit()函数和配置指令 max_execution_time只影响脚本本身执行的时间。

任何发生在诸如使用  system()的系统调用，不包括流操作，数据库操作等的脚本执行的最大时间，当该脚本已运行。

PHP::Stomp 的（每次）连接超时时间=默认值 60秒；（一般设置2～3秒超时。）

PHP::Stomp 最终放弃连接抛出异常前，尝试连接不同主机的次数=默认值 10次；（randomize=false时，每次循环都会更换一个主机）

mysql

innodb_lock_wait_timeout：一个 InnoDB 事务遇到一个行锁，等待的超时时间， 默认值50秒，届时会打印“Lock wait timeout exceeded; try restarting transaction”错误

Nginx

note：Nginx 504 Gateway Time-out：所请求的网关没有请求到，即没有请求到可以执行的 PHP-CGI 。这可能此时 PHP 进程已经达到了最大进程数且均在执行中（或阻塞中），所以无法处理新请求，新请求在等待 fastcgi_connect_timeout 秒后就收到504错误。

fastcgi_connect_timeout：同 FastCGI 服务器的连接超时时间，默认值 60秒， 它不能超过75秒；线上设为 300秒=5分钟；

fastcgi_send_timeout： Nginx 进程向 FastCGI 进程发送 request ，整个过程的超时时间，默认值60秒；线上设为300秒；

fastcgi_read_timeout：  FastCGI  进程向  Nginx  进程发送 response ，整个过程的超时时间，默认值60秒；线上设为300秒。

关于Pragma

Pragma 仅仅是一个 Request 头域指令，如果你在 Response 头域里放了 Pragma:no-cache，没有意义。

HTTP/1.1缓存应该把"Pragma：no_cache"当作好像客户端发送了"cache_control:no-cache"。

在http中不会有新的pragma指令会被定义。

关于post-check

真的需要 post-check 和 pre-check 控制指令吗？

常看见 response 头域里，有“Cache-control: post-check=0,pre-check=0”的控制指令。

其实，post-check 和 pre-check 都是 微软从 IE5 引入的扩展指令，HTTP 1.1 

第14节 Header Field Definitions 里并未定义这两个指令。

所以，如果你仅仅是写习惯了 post-check=0,pre-check=0，可以停止这种书写方式，

请使用 HTTP 1.1 标准的 Cache-control 控制指令。