随手小记:PHP-FPM模式下PHP最大执行时间、Pragma和post-check - 旁观者

旁观者 2013-06-06 13:24

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-
赠图几枚:
一副图说明好的技术构架和差的技术构架
 

 


本文链接:http://www.cnblogs.com/zhengyun_ustc/archive/2013/06/06/3120967.html,转载请注明。

[返回] [原文链接]