講 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 介面，通過監控活躍連線數的數量來調整。
說明：關於 web 併發模型方面的知識建議參考范凱的「web併發模型粗淺**」。
[**：
第六天 大雜燴雜燴
農夫約翰想修復牧場周圍的一小部分籬笆。他測量圍欄，並發現他需要 1 20000 厚木板，每乙個都具有一些整數長度大號我 1 大號我 50000 單元。然後，他購買了一塊足夠長的單塊長板，足以切入n塊木板 即，其長度為長度l i的總和 fj忽略了 鋸縫 即鋸切時因鋸末而損失的額外長度 您也應該忽略它。...
c 基礎雜燴
include include using namespace std define max line length 100 int main while infileptr eof onearraya n 演算法是解決特定問題求解步驟的描述，在計算機中為指令的有限序列，並且每條指令表示為乙個或多個...
Linux問題雜燴
1.userdel error deleting shadow password entry userdel warning var spool mail user1 not owned by user1,not removing userdel error removing directory h...