PHP-PHP-FPM的max_children一些誤區

如今nginx + fpm 基本成爲主流的配置，其中咱們比較關注的是pm.max_chindren的配置

首先，咱們關注一個前提設置： pm = static/dynamic，

這個選項是標識fpm子進程的產生模式：

static ：表示在fpm運行時直接fork出pm.max_chindren個worker進程，

dynamic：表示，運行時fork出start_servers個進程，隨着負載的狀況，動態的調整，最多不超過max_children個進程。

通常推薦用static，優勢是不用動態的判斷負載狀況，提高性能，缺點是多佔用些系統內存資源。

上面的告訴咱們max_chindren表明的worker的進程數。廣泛認爲，這個配置越多能同時處理的併發也就越多，這是一個比較大的誤區：

1） 查看了fpm的相關源碼， 管理進程和worker進程是經過pipe進行數據通信的。因此進程多了，增長進程管理的開銷，系統進程切換的開銷，更核心的是，能併發執行的fpm進程不會超過cpu個數。經過多開worker的個數來提高qps， 是錯誤的理解，不會說你多開了幾個進程，就多出幾個cpu來處理。

2） 但worker進程開少了，若是server比較繁忙的話，會導到nginx把數據打到fpm的時候，發現全部的woker都在工做中，沒有空閒的worker來接受請求，從而致使502。

那worker數到底該怎麼配置呢？

理論上woker進程數=cpu的個數是最合理的，但因爲第2點的緣由，可能每一個worker都沒處理完請求，這樣，就會頻現502了。但多開請求，只是說避免502，暫時把請求hang住，但這只是緩解之道，實際上這不但不會增長系統的併發，並且會加劇系統的負荷，因此，設置一個合理的worker數就比較重要了。

天下武功，惟快不破，只有儘量的提高程序的效率，把單個請求的時間壓縮到最低，這樣，單個worker的處理時間變短了，那在單位時間裏能處理的請求天然就多了。

那麼能夠經過每一個worker在單位時間內處理的請求數來預估max_children的個數。假如最大的一個請求的處理時間是100ms內，而在100ms以內同時有100個請求過來，那了理論上就須要配置100個worker進程，先把請求給hang住。

但最大的請求耗時可能會受不少外在的狀況影響，不太好預估，其實這裏有一個捷徑，來配置你的max_children數， 就是你前期先把max_childnren設置成一個比較大的值，穩定運行一段時間後，觀察fpm的status裏的 max active processes 是多少，而後把max_children配置比他大一些就ok了。