隨手小記：PHP-FPM模式下PHP最大執行時間、Pragma和post-check

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-贈圖幾枚：一副圖說明好的技術構架和差的技術構架