一個讓人沮喪的訊息是絕大多數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)