| php-fpm request_terminate_timeout 設置 | 0 | 15 |
| php.ini max_execution_time 設置 | 30 | 30 |
| 執行結果 | php有Fatal error超時日志，http狀態碼為500 | php無Fatal error超時日志，http狀態碼為502，php-fpm日志中有殺掉子進程日志 |
好吧，結論是web請求php執行時間受到2方面控制，一個是php.ini的max_execution_time（要注意的是sleep，http請求等待響應的時間是不算的，這里算的是真正的執行時間），另一個是php-fpm request_terminate_timeout 設置，這個算的是請求開始n秒。
request_terminate_timeout引起的資源問題
request_terminate_timeout的值如果設置為0或者過長的時間，可能會引起file_get_contents的資源問題。
如果file_get_contents請求的遠程資源如果反應過慢，file_get_contents就會一直卡在那里不會超時。我們知道php.ini 里面max_execution_time 可以設置 PHP 腳本的最大執行時間，但是，在 php-cgi(php-fpm) 中，該參數不會起效。
真正能夠控制 PHP 腳本最大執行時間的是 php-fpm.conf 配置文件中的request_terminate_timeout參數。
request_terminate_timeout默認值為 0 秒，也就是說，PHP 腳本會一直執行下去。
這樣，當所有的 php-cgi 進程都卡在 file_get_contents() 函數時，這臺 Nginx+PHP 的 WebServer 已經無法再處理新的 PHP 請求了，
Nginx 將給用戶返回“502 Bad Gateway”。修改該參數，設置一個 PHP 腳本最大執行時間是必要的，
但是，治標不治本。例如改成 30s，如果發生 file_get_contents() 獲取網頁內容較慢的情況，這就意味著 150 個 php-cgi 進程，每秒鐘只能處理 5 個請求，WebServer 同樣很難避免”502 Bad Gateway”。
解決辦法是：request_terminate_timeout設置為10s或者一個合理的值，
或者給file_get_contents加一個超時參數。
$ctx = stream_context_create(array(
'http' => array(
'timeout' => 10 //設置一個超時時間，單位為秒
)
));
file_get_contents($str, 0, $ctx);
php-fpm中的request_terminate_timeout最好不要設置
剛轉到php-fpm沒幾天就發現，進入我的joomla后臺，firefox偶爾會給我白屏的那種http 503，這種情況僅出現在天翼云的服務器上，而我在國外的同樣配置的服務器一點問題都沒有，后來發現是request_terminate_timeout的問題。
每次登陸joomla后臺，joomla都會去檢查是否有更新（檢查成功后cache，默認保存該cache 6小時），而且分為joomla主程序和joomla擴展兩個部分，如下圖：
不出意外的話，服務器會發起兩個php進程，分別分配給兩個php-fpm children，去連接joomla的官方update服務器。好，問題就來了，我的request_terminate_timeout = 30s，30秒不完成則超時，參見天翼云主機的國際出口相當蛋疼！沒錯，30秒內，天翼云主機根本無法完成連接joomla更新服務器并檢查是否有更新這整個過程。這也很好解釋了為什么同樣配置的國外服務器就沒有問題，因為它們完成上述更細過程僅需要在2~5秒左右。
我的apache超時設置是30秒，php.ini中最長執行時間野是30秒，多年來都沒有任何問題，沒有30秒還打不開的網頁，所以我就沒多想給php-fpm的request_terminate_timeout = 30s。經過這次的事情發現此30秒非鄙30秒啊……
php-fpm設置request_terminate_timeout后，php.ini中的max_execution_time和max_input_time都會失效，以php-fpm中的設置為準；
apache+mod_php在timeout后，只會在日志中記錄一下，僅此而已。php-fpm中的request_terminate_timeout超時之后，日志中記錄http 503的同時，最要命的，它還會直接殺死造成這個http 503的php-fpm child，并生成新的child。
在我的joomla更新這個實例中，就會有兩個php-fpm children同時被殺死。而我的天翼云主機是低配，只有一個cpu核心，我也只啟動了兩個php-fpm children，兩個同時死了，我的firefox這邊也就http 503 Service Unavailable的白屏了。php-fpm的error_log如下:
[27-Sep-2014 10:41:06] WARNING: [pool www] child 1882, script '/home/onepx/public_html/administrator/index.php' (request: "POST /administrator/index.php") execution timed out (30.004534 sec), terminating
[27-Sep-2014 10:41:06] WARNING: [pool www] child 1882 exited on signal 15 (SIGTERM) after 164.717323 seconds from start
[27-Sep-2014 10:41:06] NOTICE: [pool www] child 1886 started
[27-Sep-2014 10:41:06] WARNING: [pool www] child 1883, script '/home/onepx/public_html/administrator/index.php' (request: "POST /administrator/index.php") execution timed out (30.005201 sec), terminating
[27-Sep-2014 10:41:06] WARNING: [pool www] child 1883 exited on signal 15 (SIGTERM) after 166.718162 seconds from start
[27-Sep-2014 10:41:06] NOTICE: [pool www] child 1887 started
像joomla這種全php的網站，每個連接都需要apache+php-fpm協同運作。即便php-fpm中的request_terminate_timeout時間設置很長，apache中的timeout時間設置略短，只要apache的timeout到了，php-fpm照樣在后面殺進程……
如果網站的訪問者比較多，php-fpm的child是被許多訪問者共用的，殺一個child，就有可能導致幾個用戶同時http 503 Service Unavailable。所以，我的建議是——php-fpm中的request_terminate_timeout最好不要設置，只給apache一個timeout就夠了。
