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函式都回轉化成內部的一個函式指標。比如說擴充套件中函式
1 |
ZEND_FUNCTION ( my_function );//類似function my_function(){} |
在內部展開後就會是一個函式
1 2 3 4 5 6 7 8 |
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的動態執行特點,比如說程式碼:
1 2 3 |
<?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 -a
Linux 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/Linux
Red Hat Enterprise Linux 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 (cli) (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框架。
其他說明:
測試壓力機器和目標機器獨立部署。
3.2裸PHP效能
最簡單的PHP指令碼。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<?php require_once ‘./actions/indexAction.php’; $objAction = new indexAction(); $objAction->init(); $objAction->execute(); ?> Acitons/indexAction.php裡面的程式碼如下 <?php class indexAction { public function execute() { echo ‘hello, world!’; } } ?> |
通過壓力工具測試結果如下:
3.3裸PHP框架效能
為了和3.2的對比,基於bingo2框架實現了類似的功能。程式碼如下
1 2 3 4 5 6 7 |
<?php 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來寫。那時候大家寫的真是一個痛苦:除錯難、敏捷不要談。
那麼,本章節要談論的一個話題就是:C寫的業務邏輯和PHP寫的業務邏輯模組進行效能對比,採用真實的資料來說話。
4.1前提
為什麼要特別說出這個前提呢?因為在理想情況下,一個功能採用PHP實現,該效能鐵定不可能比理想的C寫出來好。這個前提需要特別注意。
但為什麼還要對比呢?因為在現實情況下,能寫出非常有些的C程式,並且在頻繁修改的情況下還能做到完全高效能的又有幾個呢?
所以,本章節的對比是基於現實中的情況來進行的。
4.2 貼吧的feye和pbui效能對比
Feye和pbui是貼吧帖子列表頁面的業務層模組。
參考文件:
https://wiki.php.net/internals/zend_mm
http://blog.xiuwz.com/2011/11/09/php-using-internal-zval/