隨手小記：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-

---

贈圖幾枚：

一副圖說明好的技術構架和差的技術構架