2013/5 记录一： PHP PHP::Stomp?的（每次）连接超时时间=默认值 60秒 ；（郑昀注1，这种超时时间设置在生产环境是难以容忍的。一般设置2～3秒超时。） PHP::Stomp?最终放弃连接抛出异常前，尝试连接不同主机的次数=默认值 10次 ；（郑昀注2，randomize=fals
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 里的?0s，它的含义是?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-
赠图几枚：
一副图说明好的技术构架和差的技术构架
?
?
本文链接
原文地址：随手小记：PHP-FPM模式下PHP最大执行时间、Pragma和post-check, 感谢原作者分享。
