簡單談談PHP中的Reload操作

前言

有許多前輩告誡過我們，reload 能保證整個過程的平滑性，所謂平滑性指的是在reload 的過程中，舊的進程在處理完當前請求前不會提前終止。很多年來，我從來沒有質疑過這種說法，直到有一天，當我 reload 的時候，出現了 502 錯誤，讓我不得不重新思考。

如何重現問題呢？讓我們寫一個簡單的腳本來模擬：

<?php

sleep(11);
echo "foo";

?>

#此時用瀏覽器瀏覽這個網址，接著立刻執行reload 操作，就能看到502 錯誤了。

難道 PHP 這麼弱？連 reload 基本的平滑性都無法保證？答案當然是否定的，實際上透過

process_control_timeout

參數可以實現我們的目標。可惜這個參數缺省是 0，也就是不生效，本文把它設定成 10s。重新執行先前的實驗步驟，這次正常輸出了結果。不過如果你多做幾次實驗的話，可能會發現當我們reload 的時候，sleep 立刻就結束了，這是因為sleep 收到reload 發出的信號後直接返回了，下面讓我們再改寫一下腳本：

<?php

sleep(11);
echo "foo";
sleep(11);
echo "bar";

?>

重新執行先前的實驗步驟，你會發現502 錯誤又出現了。這是因為 reload 雖然讓第一個 sleep 立刻結束了，但第二個 sleep 還是有效的，而且超過了

process_control_timeout

的時間限制。如果我們把

process_control_timeout

設定為 12s，那麼就又好了。

如此說來，我們只要給

process_control_timeout

設定一個合理的數值就能保證 reload 操作的平滑性，不過到底多大是合理的數值呢？太小的話可能起不到作用，太大的話會不會有副作用？讓我們帶著疑問重複上一次實驗，不過這次我們再加一個監控：

shell> watch -n1 'ps aux | grep php[-]fpm'

此監控的目的是為了觀察reload 過程中PHP- FPM 進程數的變化狀況，為了讓效果更明顯些，建議把PHP-FPM 的啟動方式改成static 模式，同時進程數不要太多。

當我們重複上一次實驗的時候，結果發現除了正在執行請求的進程，其它進程直接就被幹掉了，而新進程又沒有立刻啟動，就這樣一直卡到最後一個舊進程執行完後新進程才完成啟動程序。在此期間，如果有別的請求進來，那麼無疑它無法立刻得到回應。

根據我們的實驗可以得出結論：缺省情況下，PHP-FPM 無法保證平滑的執行reload 操作，必須設定一個合理的

process_control_timeout

才行，同時需要注意的是其值不能設定的過大，否則系統可能出現更嚴重的請求堵塞問題。

總結

以上就是關於PHP中Reload操作的全部內容了，更多相關內容請關注PHP中文網（www.php.cn）！