一個讓人沮喪的訊息是絕大多數 PHP 程式設計師都忽視了池的價值。這裡所說的池可不是指資料庫連線池之類的東西，而是指程式池，PHP 允許同時啟動多個池，每個池使用不同的配置，各個池之間尊重彼此的主權領土完整，互不干涉內政。
有什麼好處呢？預設情況下，PHP 只啟用了一個池，所有請求均在這個池中執行。一旦某些請求出現擁堵之類的情況，那麼很可能會連累整個池出現火燒赤壁的結局；如果啟用多個池，那麼可以把請求分門別類放到不同的池中執行，此時如果某些請求出現擁堵之類的情況，那麼只會影響自己所在的池，從而控制故障的波及範圍。
listen
雖然 Nginx 和 PHP 可以部署在不同的伺服器上，但是實際應用中，多數人都習慣把它們部署在同一臺伺服器上，如此就有兩個選擇：一個是 TCP，另一個是 Unix Socket。
和 TCP 比較，Unix Socket 省略了一些諸如 TCP 三次握手之類的環節，所以相對更高效，不過需要注意的是，在使用 Unix Socket 時，因為沒有 TCP 對應的可靠性保證機制，所以最好把 backlog 和 somaxconn 設定大些，否則面對高併發時會不穩定。
pm
程式管理有動態和靜態之分。動態模式一般先啟動少量程式，再按照請求數的多少實時調整程式數。如此的優點很明顯：節省資源；當然它的缺點也很明顯：一旦出現高併發請求，系統將不得不忙著 FORK 新程式，必然會影響效能。相對應的，靜態模式一次性 FORK 足量的程式，之後不管請求量如何均保持不變。和動態模式相比，靜態模式雖然消耗了更多的資源，但是面對高併發請求，它不需要執行高昂的 FORK。
對大流量網站而言，除非伺服器資源緊張，否則靜態模式無疑是最佳選擇。
pm.max_children
啟動多少個 PHP 程式合適？在你給出自己的答案之前，不妨看看下面的文章：
一個 CPU 在某一個時刻只能處理一個請求。當請求數大於 CPU 個數時，CPU 會劃分時間片，輪流執行各個請求，既然涉及多個任務的排程，那麼上下文切換必然會消耗一部分效能，從這個意義上講，程式數應該等於 CPU 個數，如此一來每個程式都對應一個專屬的 CPU，可以把上下文切換損失的效率降到最低。不過這個結論僅在請求是 CPU 密集型時才是正確的，而對於一般的 Web 請求而言，多半是 IO 密集型的，此時這個結論就值得商榷了，因為資料庫查詢等 IO 的存在，必然會導致 CPU 有相當一部分時間處於 WAIT 狀態，也就是被浪費的狀態。此時如果程式數多於 CPU 個數的話，那麼當發生 IO 時，CPU 就有機會切換到別的請求繼續執行，雖然這會帶來一定上下文切換的開銷，但是總比卡在 WAIT 狀態好多了。
那多少合適呢？要理清這個問題，我們除了要關注 CPU 之外，還要關注記憶體情況：
如上所示 top 命令的結果中和記憶體相關的列分別是 VIRT，RES，SHR。其中 VIRT 表示的是記憶體佔用的理論值，通常不用在意它，RES 表示的是記憶體佔用的實際值，雖然 RES 看上去很大，但是包含著共享記憶體，也就是 SHR 顯示的值，所以單個 PHP 程式實際獨立佔用的記憶體大小等於「RES – SHR」，一般就是 10M 上下。以此推算，理論上 1G 記憶體能支撐大概一百個 PHP 程式，10G 記憶體能大概支撐一千個 PHP 程式。當然並不能粗暴認為越多越好，最好結合 PHP 的 status 介面，通過監控活躍連線數的數量來調整。
評論(1)