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