高檔程序員關于PHP優化常識分享

關于PHP優化方面的常識，咱們或許都對怎么編寫高效代碼有所了解，本文會從另外一個角度來評論問題，教咱們怎么裝備高效的環境，如此相同能夠到達優化的目的。
pool
 一個讓人沮喪的音訊是絕大多數 PHP 程序員都忽視了池的價值。這里所說的池可不是指數據庫連接池之類的東西，而是指進程池，PHP 答應一起啟動多個池，每個池運用不同的裝備，各個池之間尊重互相的主權領土完整，互不干涉內政。

 -pool
有什么優點呢？默認情況下，PHP 只啟用了一個池，所有懇求均在這個池中履行。一旦某些懇求呈現擁堵之類的情況，那么很或許會拖累整個池呈現火燒赤壁的結局；假如啟用多個池，那么能夠把懇求分門別類放到不同的池中履行，此時假如某些懇求呈現擁堵之類的情況，那么只會影響自己地點的池，然后操控故障的觸及規模。
 listen
 盡管 Nginx 和 PHP 能夠布置在不同的服務器上，可是實踐應用中，多數人都習慣把它們布置在同一臺服務器上，如此就有兩個挑選：一個是 TCP，另一個是 Unix Socket。

-listen
和 TCP 比較，Unix Socket 省略了一些比如 TCP 三次握手之類的環節，所以相對更高效，不過需要注意的是，在運用 Unix Socket 時，因為沒有 TCP 對應的可靠性確保機制，所以最好把 backlog 和 somaxconn 設置大些，不然面臨高并發時會不穩定。
 pm
 進程辦理有動態和靜態之分。動態形式一般先啟動少量進程，再按照懇求數的多少實時調整進程數。如此的優點很明顯：節約資源；當然它的缺陷也很明顯：一旦呈現高并發懇求，系統將不得不忙著 FORK 新進程，必然會影響性能。相對應的，靜態形式一次性 FORK 足量的進程，之后不論懇求量怎么均堅持不變。和動態形式相比，靜態形式盡管耗費了更多的資源，可是面臨高并發懇求，它不需要履行高昂的 FORK。

-pm
對大流量網站而言，除非服務器資源嚴重，不然靜態形式無疑是最佳挑選。
 pm.max_children
 啟動多少個 PHP 進程適宜？在你給出自己的答案之前，不妨看看下面的文章：
php-fpm的max_chindren的一些誤區
Should PHP Workers Always Equal Number Of CPUs
一個 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 接口，經過監控活潑連接數的數量來調整。