前言

有很多前輩告誡過(guò)我們，reload 能保證整個(gè)過(guò)程的平滑性，所謂平滑性指的是在 reload 的過(guò)程中，舊的進(jìn)程在處理完當(dāng)前請(qǐng)求前不會(huì)提前終止。很多年來(lái)，我從來(lái)沒(méi)有質(zhì)疑過(guò)這種說(shuō)法，直到有一天，當(dāng)我 reload 的時(shí)候，出現(xiàn)了 502 錯(cuò)誤，讓我不得不重新思考。

如何重現(xiàn)問(wèn)題呢？讓我們寫(xiě)一個(gè)簡(jiǎn)單的腳本來(lái)模擬：

<?php

sleep(11);
echo "foo";

?>

此時(shí)用瀏覽器瀏覽這個(gè)網(wǎng)址，接著立刻執(zhí)行 reload 操作，就能看到 502 錯(cuò)誤了。

難道 PHP 這么弱？連 reload 基本的平滑性都無(wú)法保證？答案當(dāng)然是否定的，實(shí)際上通過(guò) process_control_timeout 參數(shù)可以實(shí)現(xiàn)我們的目標(biāo)?？上н@個(gè)參數(shù)缺省是 0，也就是不生效，本文把它設(shè)置成 10s。重新執(zhí)行之前的實(shí)驗(yàn)步驟，這一次正常輸出了結(jié)果。不過(guò)如果你多做幾次實(shí)驗(yàn)的話，可能會(huì)發(fā)現(xiàn)當(dāng)我們 reload 的時(shí)候，sleep 立刻就結(jié)束了，這是因?yàn)?sleep 收到 reload 發(fā)出的信號(hào)后直接返回了，下面讓我們?cè)俑膶?xiě)一下腳本：

<?php

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

?>

重新執(zhí)行之前的實(shí)驗(yàn)步驟，你會(huì)發(fā)現(xiàn) 502 錯(cuò)誤又出現(xiàn)了。這是因?yàn)?reload 雖然讓第一個(gè) sleep 立刻結(jié)束了，但是第二個(gè) sleep 還是有效的，而且超過(guò)了 process_control_timeout 的時(shí)間限制。如果我們把 process_control_timeout 設(shè)置為 12s，那么就又好了。

如此說(shuō)來(lái)，我們只要給 process_control_timeout 設(shè)置一個(gè)合理的數(shù)值就能保證 reload 操作的平滑性，不過(guò)到底多大是合理的數(shù)值呢？太小的話可能起不到作用，太大的話會(huì)不會(huì)有副作用？讓我們帶著疑問(wèn)重復(fù)上一次實(shí)驗(yàn)，不過(guò)這次我們?cè)偌右粋€(gè)監(jiān)控：

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

此監(jiān)控的目的是為了觀察 reload 過(guò)程中 PHP-FPM 進(jìn)程數(shù)的變化情況，為了讓效果更明顯些，建議把 PHP-FPM 的啟動(dòng)方式改成 static 模式，同時(shí)進(jìn)程數(shù)不要太多。

當(dāng)我們重復(fù)上一次實(shí)驗(yàn)的時(shí)候，結(jié)果發(fā)現(xiàn)除了正在執(zhí)行請(qǐng)求的進(jìn)程，其它進(jìn)程直接就被干掉了，而新進(jìn)程又沒(méi)有立刻啟動(dòng)，就這樣一直卡到最后一個(gè)舊進(jìn)程執(zhí)行完后新進(jìn)程才完成啟動(dòng)過(guò)程。在此期間，如果有別的請(qǐng)求進(jìn)來(lái)，那么無(wú)疑它無(wú)法立刻得到響應(yīng)。

根據(jù)我們的實(shí)驗(yàn)可以得出結(jié)論：缺省情況下，PHP-FPM 無(wú)法保證平滑的執(zhí)行 reload 操作，必須設(shè)置一個(gè)合理的 process_control_timeout 才行，同時(shí)需要注意的是其值不能設(shè)置的過(guò)大，否則系統(tǒng)可能出現(xiàn)更為嚴(yán)重的請(qǐng)求堵塞問(wèn)題。

總結(jié)

以上就是關(guān)于PHP中Reload操作的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來(lái)一定的幫助，如果有疑問(wèn)大家可以留言交流。

最新評(píng)論