PHP的效能探討和測試_PHP教程

　　 1.緣起

　　關於PHP，很多人的直觀感覺是PHP是一種靈活的指令碼語言，庫類豐富，使用簡單，安全，非常適合WEB開發，但效能低下。PHP的效能是否真 的就如同大家的感覺一樣的差呢？本文就是圍繞這麼一個話題來進行探討的。從源碼、應用情境、基準效能、對比分析等幾個方面深入分析PHP之效能問題，並通 過真實的資料來說話。

　　2.從原理分析PHP效能

　　從原理分析PHP的效能，主要從以下幾個方面：記憶體管理、變數、函數、運行機制來進行分析。

　　2.1記憶體管理

　　類似Nginx的記憶體管理方式，PHP在內部也是基於記憶體池，並且引入記憶體池的生命週期概念。在記憶體池方面，PHP對PHP指令碼和擴充的所有內 存相關操作都進行了託管。對大記憶體和小記憶體的管理採用了不同的實現方式和最佳化，具體可以參考以下文檔：https://wiki.php.net /internals/zend_mm。在記憶體配置和回收的生命週期內，PHP採用一次初始化申請+動態擴容+記憶體標識回收機制，並且在每次請求結束後直 接對記憶體池進行重新mask。

　　2.2變數

　　總所周知，PHP是一種弱變數類型的語言，所以在PHP內部，所有的PHP變數都對應成一種類型Zval，其中具體定義如下：

圖一PHP變數

　　在變數方面，PHP做了大量的最佳化工作，比如說Reference counting和copy on writer機制。這樣能夠保證記憶體使用量上的最佳化，並且減少記憶體拷貝次數（請參考http://blog.xiuwz.com/2011/11/09 /php-using-internal-zval/）。在數組方面，PHP內部採用高效的hashtable來實現。

　　2.3函數

　　在PHP內部，所有的PHP函數都迴轉化成內部的一個函數指標。比如說擴充中函數

　　ZEND_FUNCTION ( my_function );//類似function my_function(){}

　　在內部展開後就會是一個函數

　　void zif_my_function ( INTERNAL_FUNCTION_PARAMETERS );

　　void zif_my_function(

　　int ht,

　　zval * return_value,

　　zval * this_ptr,

　　int return_value_used,

　　zend_executor_globals * executor_globals

　　);

　　從這個角度來看，PHP函數在內部也是對應一個函數指標。

　　2.4運行機制

　　在話說PHP效能的時候，很多人都會說“C/C++是編譯型，JAVA是半編譯型，PHP是解釋型”。也就是說PHP是先動態解析再代碼啟動並執行，所以從這個角度來看，PHP效能必然很差。

　　的確，從PHP指令碼運行來輸出，的確是一個動態解析再代碼啟動並執行過程。具體來說，PHP指令碼的運行機制如所示：

圖二 PHP運行機制

　　PHP的運行階段也分成三個階段：

　　Parse。文法分析階段。

　　Compile。編譯產出opcode中間碼。

　　Execute。運行，動態運行進行輸出。

　　所以說，在PHP內部，本身也是存在編譯的過程。並且據此產生了大量的opcode cache工具，比如說apc、eacc、xcache等等。這些opcode cache在生產環境基本上在標配。基於opcode cache，能到做到“PHP指令碼編譯一次，多次運行”的效果。從這點上，PHP就和JAVA的半編譯機制非常類似。

　　所以，從運行機制上來看，PHP的運行模式和JAVA是非常類似的，都是先產生中間碼，然後運行在不同虛擬機器上。

　　2.5動態運行

　　從上面的幾個分析來看，PHP在記憶體管理、變數、函數、運行機制等幾個方面都做了大量的工作，所以從原理來看，PHP不應該存在效能問題，效能至少也應該和Java比較接近。

　　這個時候就不得不談PHP動態語言的特性所帶來的效能問題了，由於PHP是動態運行時，所以所有的變數、函數、對象調用、範圍實現等等都是在 執行階段中才確定的。這個從根本上決定了PHP效能中很難改變的一些東西：在C/C++等能夠在靜態編譯階段確定的變數、函數，在PHP中需要在動態運行 中確定，也就決定了PHP中間碼不能直接運行而需要運行在Zend Engine上。

　　說到PHP變數的具體實現，又不得不說一個東西了：Hashtable。Hashtable可以說在PHP靈魂之一，在PHP內部廣泛用到，包含變數符號棧、函數符號棧等等都是基於hashtable的。

　　以PHP變數為例來說明下PHP的動態運行特點，比如說代碼：

　　

　　$var = “hello, blog.xiuwz.com”;

　　?>

　　該代碼的執行結果就是在變數符號棧（是一個hashtable）中新增一個項

　　當要使用到該變數時候，就去變數符合棧中去尋找（也就是變數調用對出了一個hash尋找的過程）。

　　同樣對於函數調用也基本上類似有一個函數符號棧（hashtable）。

　　其實關於動態啟動並執行變數尋找特點，在PHP的運行機制中也能看出一些。PHP代碼通過解釋、編譯後的流程：

圖3 PHP運行執行個體

　　從可以看出，PHP代碼在compile之後，產出的了類符號表、函數符號表、和OPCODE。在真正執行的時候，zend Engine會根據op code去對應的符號表中進行尋找，處理。

　　從某種程度上，在這種問題的上，很難找到解決方案。因為這是由於PHP語言的動態特性所決定的。但是在國內外也有不少的人在尋找解決方案。因為 通過這樣，能夠從根本上完全的最佳化PHP。典型的列子有facebook的hiphop(https://github.com/facebook /hiphop-php)。

　　2.6結論

　　從上面分析來看，在基礎的記憶體管理、變數、函數、運行機制方面，PHP本身並不會存在明顯的效能差異，但由於PHP的動態運行特性，決定了 PHP和其他的編譯型語言相比，所有的變數尋找、函數運行等等都會多一些hash尋找的CPU開銷和額外的記憶體開銷，至於這種開銷具體有多大，可以通過後 續的基準效能和對比分析得出。

　　因此，也可以大體看出PHP不太適合的一些情境：大量計算性任務、大資料量的運算、記憶體要求很嚴格的應用情境。如果要實現這些功能，也建議通過擴充的方式實現，然後再提供鉤子函數給PHP調用。這樣可以減低內部計算的變數、函數等系列開銷。

　　3.基準效能

　　對於PHP基準效能，目前缺少標準的資料。大多數同學都存在感性的認識，有人認為800QPS就是PHP的極限了。此外，對於架構的效能和架構對效能的影響很沒有響應的權威數字。

　　本章節的目的是給出一個基準的參考效能指標，通過資料給大家一個直觀的瞭解。

　　具體的基準效能有以下幾個方面：

　　1.裸PHP效能。完成基本的功能。

　　2.裸架構的效能。只做最簡單的路由分發，只走通核心功能。

　　3.標準模組的基準效能。所謂標準模組的基準效能，是指一個具有完整服務模組功能的基準效能。

　　3.1環境說明

　　測試環境：

Uname -aPnux db-forum-test17.db01.baidu.com 2.6.9_5-7-0-0 #1 SMP Wed Aug 12 　　　17:35:51 CST 2009 x86_64 x86_64 x86_64 GNU/Pnux 　　Red Hat Enterprise Pnux AS release 4 (Nahant Update 3) 　　8 Intel(R) Xeon(R) CPU E5520 @ 2.27GHz

　　軟體相關：

Nginx：nginx version: nginx/0.8.54 built by gcc 3.4.5 20051201 (Red Hat 3.4.5-2) 　　Php5：（採用php-fpm） 　　PHP 5.2.8 (cP) (built: Mar 6 2011 17:16:18) 　　Copyright (c) 1997-2008 The PHP Group 　　Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies 　　with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator 　　bingo2：

　　PHP架構。

　　其他說明：

　　目標機器的部署方式：nginx->php-fpm->php指令碼。

　　測試壓力機器和目標機器獨立部署。

　　3.2裸PHP效能

　　最簡單的PHP指令碼。

　　

　　require_once ‘./actions/indexAction.php’;

　　$objAction = new indexAction();

　　$objAction->init();

　　$objAction->execute();

　　?>

　　Acitons/indexAction.php裡面的代碼如下

　　

　　class indexAction

　　{

　　pubPc function execute()

　　{

　　echo ‘hello, world!’;

　　}

　　}

　　?>

　　通過壓力工具測試結果如下：

　　3.3裸PHP架構效能

　　為了和3.2的對比，基於bingo2架構實現了類似的功能。代碼如下

　　

　　require_once ‘Bingo/Controller/Front.php’;

　　$objFrontController = Bingo_Controller_Front::getInstance(array(

　　‘actionDir’ => ‘./actions’,

　　));

　　$objFrontController->dispatch();

　　壓力測試結果如下：

　　從該測試結果可以看出：架構雖然有一定的消耗，但對整體的效能來說影響是非常小的。

　　3.4標準PHP模組的基準效能

　　所謂標準PHP模組，是指一個PHP模組所必須要具體的準系統：

　　路由分發。

　　自動載入。

　　LOG初始化&Notice日誌列印。所以的UI請求都一條標準的日誌。

　　錯誤處理。

　　時間校正。

　　自動計算每個階段耗時開銷。

　　編碼識別&編碼轉化。

　　標準設定檔的解析和調用

　　採用bingo2的代碼自動產生工具產生標準的測試PHP模組：test。

　　測試結果如下：

　　3.5結論

　　從測試資料的結論來看，PHP本身的效能還是可以的。基準效能完全能夠達到幾千甚至上W的QPS。至於為什麼在大多數的PHP模組中表現不佳， 其實這個時候更應該去找出系統的瓶頸點，而是簡單的說OK，PHP不行，那我們換C來搞吧。（下一個章節，會通過一些例子來對比，採用C來處理不見得有特 別的優勢）

　　通過基準資料，可以得出以下幾個具體的結論：

　　1.PHP本身效能也很不錯。簡易功能下能夠達到5000QPS，極限也能過W。

　　2.PHP架構本身對效能影響非常有限。尤其是在有一定商務邏輯和資料互動的情況下，幾乎可以忽略。

　　3.一個標準的PHP模組，基準效能能夠達到2000QPS（80 cpu idle）。

　　4.對比分析

　　很多時候，大家發現PHP模組效能不行的時候，就來一句“ok，我們採用C重寫吧”。在公司內，採用C/C++來寫商務邏輯模組的現象到處都有，在前幾年甚至幾乎全部都是採用C來寫。那時候大家寫的真是一個痛苦：調試難、敏捷不要談。

http://www.bkjia.com/PHPjc/371766.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/371766.htmlTechArticle1.緣起 關於PHP，很多人的直觀感覺是PHP是一種靈活的指令碼語言，庫類豐富，使用簡單，安全，非常適合WEB開發，但效能低下。PHP的效能是否...

