随手小记：PHPFPM模式下PHP最大执行时间、Pragma和postcheck

2013/5

记录一：

• PHP
  • PHP::Stomp 的（每次）连接超时时间=默认值60秒；（郑昀注1，这种超时时间设置在生产环境是难以容忍的。一般设置2～3秒超时。）
  • PHP::Stomp 最终放弃连接抛出异常前，尝试连接不同主机的次数=默认值10次；（郑昀注2，randomize=false时，每次循环都会更换一个主机）
  • PHP 脚本的最大执行时间=？：
    • PHP-FPM 模式下，max_execution_time 参数没有太大效果，它控制的是进程的CPU占用时间，默认值30秒；
      • note：set_time_limit()函数和配置指令max_execution_time只影响脚本本身执行的时间。任何发生在诸如使用 system()的系统调用，流操作，数据库操作等的脚本执行的最大时间不包括其中，当该脚本已运行。
    • 真正起点儿作用的是 php-fpm.conf 里的 <value name="request_terminate_timeout">0s</value>，它的含义是 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 终结掉前，到底执行时间是多少秒。

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

• Nginx
  • fastcgi_connect_timeout：同 FastCGI 服务器的连接超时时间，默认值60秒，它不能超过75秒；线上设为300秒=5分钟；
    • note：Nginx 504 Gateway Time-out：所请求的网关没有请求到，即没有请求到可以执行的 PHP-CGI 。这可能意味着此时 PHP 进程已经达到了最大进程数且均在执行中（或阻塞中），所以无法处理新请求，新请求在等待 fastcgi_connect_timeout 秒后就收到504错误。
  • fastcgi_send_timeout： Nginx 进程向 FastCGI 进程发送 request ，整个过程的超时时间，默认值60秒；线上设为300秒；
  • fastcgi_read_timeout：  FastCGI  进程向  Nginx  进程发送 response ，整个过程的超时时间，默认值60秒；线上设为300秒。

---

记录二：

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

HTTP/1.1缓存应该把"Pragma：no_cache"当作好像客户端发送了"cache_control:no-cache"。在http中不会有新的pragma指令会被定义。

---

记录三：

真的需要 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 控制指令。

 

-over-

---

赠图几枚：

一副图说明好的技术构架和差的技术构架