PHP優化雜燴

edithfang發表於2014-12-30
pool

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

相關文章