建站
咨詢
售后
建站咨詢
新聞中心
關于PHP，很多人的直觀感覺是PHP是一種靈活的腳本語言，庫類豐富，使用簡單，安全，非常適合WEB開發(fā)，但性能低下。PHP的性能是否真的就如同大家的感覺一樣的差呢?本文就是圍繞這么一個話題來進行探討的。從源碼、應用場景、基準性能、對比分析等幾個方面深入分析PHP之性能問題，通過真實的性能數(shù)據(jù)來說話，最終找出影響PHP模塊性能的關鍵因素。
網(wǎng)站建設、成都做網(wǎng)站服務團隊是一支充滿著熱情的團隊，執(zhí)著、敏銳、追求更好，是創(chuàng)新互聯(lián)的標準與要求，同時竭誠為客戶提供服務是我們的理念。成都創(chuàng)新互聯(lián)把每個網(wǎng)站當做一個產品來開發(fā)，精雕細琢，追求一名工匠心中的細致，我們更用心！
從原理分析PHP性能
從原理分析PHP的性能，主要從以下幾個方面：內存管理、變量、函數(shù)、運行機制、網(wǎng)絡模型來進行分析。
2.1內存管理
類似Nginx的內存管理方式，PHP在內部也是基于內存池，并且引入內存池的生命周期概念。在內存池方面，PHP對PHP腳本和擴展的所有內存相關操作都進行了托管。對大內存和小內存的管理采用了不同的實現(xiàn)方式和優(yōu)化，具體可以參考以下文檔：http://www.laruence.com/2011/11/09/2277.html。在內存分配和回收的生命周期內，PHP采用一次初始化申請+動態(tài)擴容+內存標識回收機制，并且在每次請求結束后直接對內存池進行重新mask。
2.2變量
總所周知，PHP是一種弱變量類型的語言，所以在PHP內部，所有的PHP變量都對應成一種類型Zval，其中具體定義如下：
圖一、PHP變量
在變量方面，PHP做了大量的優(yōu)化工作，比如說Reference counting和copy on writer機制。這樣能夠保證內存使用上的優(yōu)化，并且減少內存拷貝次數(shù)(請參考http://blog.xiuwz.com/2011/11/09/php-using-internal-zval/)。在數(shù)組方面，PHP內部采用高效的hashtable來實現(xiàn)。
2.3函數(shù)
在PHP內部，所有的PHP函數(shù)都回轉化成內部的一個函數(shù)指針。比如說擴展中函數(shù)
- ZEND_FUNCTION ( my_function );//類似function my_function(){}
在內部展開后就會是一個函數(shù)
- 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函數(shù)在內部也是對應一個函數(shù)指針。
2.4運行機制
在話說PHP性能的時候，很多人都會說“C/C++是編譯型，JAVA是半編譯型，PHP是解釋型”。也就是說PHP是先動態(tài)解析再代碼運行的，所以從這個角度來看，PHP性能必然很差。
的確，從PHP腳本運行來輸出，的確是一個動態(tài)解析再代碼運行的過程。具體來說，PHP腳本的運行機制如下圖所示：
圖二、PHP運行機制
PHP的運行階段也分成三個階段：
●Parse。語法分析階段。
● Compile。編譯產出opcode中間碼。
● Execute。運行，動態(tài)運行進行輸出。
通過上圖也可以看出，其實在PHP內部本身也是存在編譯的過程。事實上，在標準的生產環(huán)境中，也都基本上利用了這個特點，比如說opcode cache工具apc、eacc、xcache等等。基于opcode cache，能到做到“PHP腳本編譯一次，多次運行”的效果。從這點上，PHP就和JAVA的半編譯機制非常類似。
所以，從運行機制上來看，PHP的運行模式和JAVA是非常類似的，都是先產生中間碼，然后運行在不同虛擬機上。
2.5動態(tài)運行
從上面的幾個分析來看，PHP在內存管理、變量、函數(shù)、運行機制等幾個方面都做了大量的工作，所以從原理來看，PHP不應該存在性能問題，性能至少也應該和JAVA比較接近。
但為什么還有很多人感覺PHP慢呢?尤其是一些計算量的性能對比上，總發(fā)現(xiàn)PHP處理的性能相對比較低效(http://shootout.alioth.debian.org/u32/php.php)。這個時候就不得不談PHP動態(tài)語言的特性所帶來的性能問題了，由于PHP是動態(tài)運行時，所以所有的變量、函數(shù)、對象調用、作用域實現(xiàn)等等都是在執(zhí)行階段中才確定的。這個從根本上決定了PHP性能中很難改變的一些東西：在C/C++等能夠在靜態(tài)編譯階段確定的變量、函數(shù)，在PHP中需要在動態(tài)運行中確定，也就決定了PHP中間碼不能直接運行而需要運行在Zend Engine上。
說到PHP變量的具體實現(xiàn)，又不得不說一個東西了：hashtable。Hashtable可以說在PHP靈魂之一，在PHP內部廣泛用到，包含變量符號棧、函數(shù)符號棧等等都是基于hashtable的。
以PHP變量為例來說明下PHP的動態(tài)運行特點，比如說代碼：
- $var = “hello, blog.xiuwz.com”;
- ?>
該代碼的執(zhí)行結果就是在變量符號棧(是一個hashtable)中新增一個項
當要使用到該變量時候，就去變量符合棧中去查找(也就是變量調用對出了一個hash查找的過程)。
同樣對于函數(shù)調用也基本上類似有一個函數(shù)符號棧(hashtable)。
其實關于動態(tài)運行的變量查找特點，在PHP的運行機制中也能看出一些。PHP代碼通過解釋、編譯后的流程下圖：
圖3、PHP運行實例
從上圖可以看出，PHP代碼在compile之后，產出的了類符號表、函數(shù)符號表、和OPCODE。在真正執(zhí)行的時候，zend Engine會根據(jù)op code去對應的符號表中進行查找，處理。
從某種程度上，在這種問題的上，很難找到解決方案。因為這是由于PHP語言的動態(tài)特性所決定的。但是在國內外也有不少的人在尋找解決方案。因為通過這樣，能夠從根本上完全的優(yōu)化PHP。典型的列子有facebook的hiphop(https://github.com/facebook/hiphop-php)。
但所有的這種編譯優(yōu)化方案，都基本上是犧牲了PHP動態(tài)運行的特性。當然可以在具體的編譯優(yōu)化中去對動態(tài)特性做一些折中，但很難做到完完全全的兼容。
2.6網(wǎng)絡模型
目前采用PHP的方式，比較理想和通用的模式是采用fastcgi(PHP-FPM)。Php-fpm在網(wǎng)絡模型上比較類似nginx，采用了多進程Master+多worker的模式。Php-fpm本身是基于libevent中的epoll模型。從網(wǎng)絡模型來看，該方式也不會和其他網(wǎng)絡模型存在性能差異。
2.7結論
從上面分析來看，在基礎的內存管理、變量、函數(shù)、運行機制、網(wǎng)絡模型方面，PHP本身并不會存在明顯的性能差異，但由于PHP的動態(tài)運行特性，決定了PHP和其他的編譯型語言相比，所有的變量查找、函數(shù)運行等等都會多一些hash查找的CPU開銷和額外的內存開銷，至于這種開銷具體有多大，可以通過后續(xù)的基準性能和對比分析得出。
因此，也可以大體看出PHP不太適合的一些場景：大量計算性任務、大數(shù)據(jù)量的運算、內存要求很嚴格的應用場景。如果要實現(xiàn)這些功能，也建議通過擴展的方式實現(xiàn)，然后再提供鉤子函數(shù)給PHP調用。這樣可以減低內部計算的變量、函數(shù)等系列開銷。
3基準性能
對于PHP基準性能，目前缺少標準的數(shù)據(jù)。大多數(shù)同學都存在感性的認識，有人認為800QPS就是PHP的極限了。此外，對于框架的性能和框架對性能的影響很沒有響應的權威數(shù)字。
本章節(jié)的目的是給出一個基準的參考性能指標，通過數(shù)據(jù)給大家一個直觀的了解。
具體的基準性能有以下幾個方面：
1、 裸PHP性能。完成基本的功能。
2、 裸框架的性能。只做最簡單的路由分發(fā)，只走通核心功能。
3、 標準模塊的基準性能。所謂標準模塊的基準性能，是指一個具有完整服務模塊功能的基準性能。
3.1環(huán)境說明
測試環(huán)境：
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腳本。
- require_once ‘./actions/indexAction.php’;
- $objAction = new indexAction();
- $objAction->init();
- $objAction->execute();
- ?>
Acitons/indexAction.php里面的代碼如下
- class indexAction
- {
- public function execute()
- {
- echo ‘hello, world!’;
- }
- }
- ?>
通過壓力工具測試結果如下：
3.3裸PHP框架性能
為了和3.2的對比，基于bingo2框架實現(xiàn)了類似的功能。代碼如下
- require_once ‘Bingo/Controller/Front.php’;
- $objFrontController = Bingo_Controller_Front::getInstance(array(
- ‘actionDir’ => ‘./actions’,
- ));
- $objFrontController->dispatch();
- ?>
壓力測試結果如下：
從該測試結果可以看出：框架雖然有一定的消耗，但對整體的性能來說影響是非常小的。
3.4標準PHP模塊的基準性能
所謂標準PHP模塊，是指一個PHP模塊所必須要具體的基本功能：
●路由分發(fā)。
●自動加載。
●LOG初始化&Notice日志打印。所以的UI請求都一條標準的日志。
●錯誤處理。
●時間校正。
●自動計算每個階段耗時開銷。
●編碼識別&編碼轉化。
●標準配置文件的解析和調用
采用bingo2的代碼自動生成工具產生標準的測試PHP模塊：test。
測試結果如下：
3.5結論
從測試數(shù)據(jù)的結論來看，PHP本身的性能還是可以的?；鶞市阅芡耆軌蜻_到幾千甚至上W的QPS。至于為什么在大多數(shù)的PHP模塊中表現(xiàn)不佳，其實這個時候更應該去找出系統(tǒng)的瓶頸點，而不是簡單的說OK，PHP不行，那我們換C來搞吧。(下一個章節(jié)，會通過一些例子來對比，采用C來處理不見得有特別的優(yōu)勢)
通過基準數(shù)據(jù)，可以得出以下幾個具體的結論：
1、 PHP本身性能也很不錯。簡單功能下能夠達到5000QPS(50CPU IDLE)，極限也能過W。
2、 PHP框架本身對性能影響非常有限。尤其是在有一定業(yè)務邏輯和數(shù)據(jù)交互的情況下，幾乎可以忽略。
3、 一個標準的PHP模塊，基準性能能夠達到2000QPS(80 cpu idle)。
#p#
4 PHP與C性能對比分析
很多時候，大家發(fā)現(xiàn)PHP模塊性能不行的時候，就來一句“ok，我們采用C重寫吧”。在公司內，采用C/C++來寫業(yè)務邏輯模塊的現(xiàn)象到處都有，在前幾年甚至幾乎全部都是采用C來寫。那時候大家寫的真是一個痛苦：調試難、敏捷不要談。
那么，本章節(jié)要談論的一個話題就是：C寫的業(yè)務邏輯和PHP寫的業(yè)務邏輯模塊進行性能對比，采用真實的數(shù)據(jù)來說話。
4.1前提
為什么要特別說出這個前提呢?因為在理想情況下，一個功能采用PHP實現(xiàn)，該性能鐵定不可能比理想的C寫出來好。這個前提需要特別注意。
但為什么還要對比呢?因為在現(xiàn)實情況下，能寫出非常優(yōu)秀的C程序，并且在頻繁修改的情況下還能做到完全高性能的又有幾個呢?并且在現(xiàn)實的應用中C實現(xiàn)的性能是否真的全都都比PHP要好好幾倍呢?這些目前都沒有確切的數(shù)據(jù)來論證。
所以，本章節(jié)的對比是基于現(xiàn)實中的情況來進行的，并采用真實數(shù)據(jù)來說話。
4.2 真實業(yè)務模塊PHP模塊 VS C模塊
4.2.1業(yè)務模塊介紹
一個真實的案列，該業(yè)務模塊的流量高達數(shù)十億。該模塊的架構圖如下：
圖4、業(yè)務模塊架構圖
該業(yè)務模塊功能非常簡單，上層是web server，下游是各個數(shù)據(jù)模塊。都是基于socket進行數(shù)據(jù)交互。該業(yè)務模塊的主要工作模型是：響應web server的請求，根據(jù)請求從各個后端數(shù)據(jù)模塊讀取相應數(shù)據(jù)，并根據(jù)數(shù)據(jù)產出最終的HTML頁面返回給web服務器。
為了方便后續(xù)介紹，定義CUI表示用C實現(xiàn)的模塊，PHPUI表示用PHP實現(xiàn)的模塊。
4.2.2C/C++模塊的性能數(shù)據(jù)結果
09年，該模塊重構選擇了一個新的C/C++框架。當時重構的時候，該模塊連接的后端數(shù)據(jù)模塊規(guī)模在5-7個。
基于C/C++的模塊，最終測試數(shù)據(jù)數(shù)據(jù)分成兩個部分：
一、性能對比測試。
基于當時線上壓力，進行真實數(shù)據(jù)的性能測試。所以當時只測試一個壓力數(shù)據(jù)如下：
壓力：210QPS
CPU(IDLE)：84.18
二、極限性能測試1。
該測試模型是：CUI只連接一個核心數(shù)據(jù)模塊，其他數(shù)據(jù)模塊完全關閉。
三、極限性能測試2。
該測試模型是：CUI連接后端一個核心數(shù)據(jù)模塊，3個數(shù)據(jù)模塊，其他數(shù)據(jù)模塊不連接。
測試后性能數(shù)據(jù)如下：
4.2.3 PHP實現(xiàn)模塊的性能測試數(shù)據(jù)
到11年，基于09年的CUI基本上達到了代碼不看維護的地步。而且這個時候，CUI的極限性能已經不到600QPS(主要原因是隨著項目的發(fā)展，后端數(shù)據(jù)模塊的數(shù)目增加到14個)。據(jù)此，決定采用PHP方案來重寫整個模塊，并產出最終的pbui模塊。
性能測試結果分成兩種：
1、PHPUI連接一個核心模塊。測試數(shù)據(jù)如下：
圖5、PHPUI性能測試結果1
2、PHPUI連接后端所有模塊(14個)。測試性能數(shù)據(jù)如下：
圖6、PHPUI性能測試結果2
4.2.4數(shù)據(jù)對比結論
由于PHPUI和CUI的業(yè)務邏輯和測試方法都不完全相同，所以抽取了部分大體能對比的點進行整理。具體對比數(shù)據(jù)如下：
從上面的對比數(shù)據(jù)來看，在真實的業(yè)務項目中，PHPUI的性能并不會比CUI差。這個不是簡簡單單一個模塊來驗證的，在部門里面，我們有不少模塊都是從C/C++遷移到PHP，從遷移的結果來看，并沒有存在質的性能下降，大部分模塊遷移后性能指標都是非常接近的。
這個時候就需要思考為什么會這樣了?細分來說有兩個問題：
1、 為什么在真實業(yè)務項目中，PHPUI的性能并不會比CUI差太多?
2、 為什么基準的PHP性能這么高，80CPU的情況下2000QPS，但到了真實的PHP模塊中只能是200QPS?
其實這兩個問題，也可以歸結成一種原因：在真實業(yè)務項目中，影響性能更多的不是說采用了什么語言，而是其業(yè)務相關的部分，比如說socket交互次數(shù)，比如說字符串處理，也比如說網(wǎng)絡交互包大小。
OK。那么接下來的關鍵是找出影響性能的關鍵因素。
4.2.5影響PHP模塊性能的關鍵因素
從前面分析，我們得出，影響前端PHP模塊性能的關鍵因素不是語言本身(是否是PHP/JAVA/C都不重要)。那么到底影響PHP業(yè)務模塊性能的關鍵因素在哪里呢?CPU耗時是統(tǒng)計一個項目性能的關鍵點之一，考慮到系統(tǒng)中都打印出了系列日志。通過分析日志中請求的耗時分布可以大體上看出關鍵點。
在我們系統(tǒng)中，CPU耗時重點打印出以下幾個方面：
1、 請求總時間。
2、 請求關鍵函數(shù)的性能，其中所有的socket交互都有耗時計算。
3、 模版渲染也是好事的一個關鍵點。
在前面分析中，我們基本上判定socket和字符串處理是一個關鍵點之一，通過數(shù)據(jù)我們來驗證下。抽取一個模塊指定數(shù)目的日志，進行綜合分析得出以下數(shù)據(jù)：
通過這個可以看出，在一個業(yè)務模塊中，影響***的是socket數(shù)據(jù)交互，其次是大量的字符串處理。具體細分來說是以下幾個因素：socket交互次數(shù)、socket交互包大小、socket交互響應時間、字符串處理。
4.2.6結論
通過上述分析，可以得出以下結論：在前端業(yè)務模塊中，PHP語言本身不會成為性能瓶頸。因為影響性能的幾個關鍵因數(shù)是：
● 網(wǎng)絡交互數(shù)目。
● 網(wǎng)絡交互數(shù)據(jù)大小，包含數(shù)據(jù)打包解包開銷。
● 網(wǎng)絡交互響應時間。
● 大量的字符串處理。
5最終結論
通過上述三個章節(jié)的具體分析，可以得出以下結論：
1、從PHP實現(xiàn)原理來看，PHP屬于半編譯型語言，并且在各個方面都進行了大量的優(yōu)化工作，本身不會存在明顯的性能問題。但由于動態(tài)語言的特性，決定了PHP需要運行在Zend Engine虛擬機上，并且在變量查找、函數(shù)調用、作用域切換等各個方面需要一些額外開銷。
2、從PHP的基準性能來看，PHP本身不會存在明顯的資源消耗，單機QPS能夠輕松過W， PHP框架本身也不會對業(yè)務系統(tǒng)的性能帶來關鍵性的影響。
3、從真實的應用場景來看，基于C語言實現(xiàn)的模塊不見得比基于PHP實現(xiàn)的模塊性能高效很多。因為在真實的應用場景中，更多的性能開銷在于網(wǎng)絡數(shù)據(jù)交互和字符串處理。語言方面微小的性能差異不會成為瓶頸。
據(jù)此，可以推出：基于C語言實現(xiàn)的大部分業(yè)務系統(tǒng)都可以考慮遷移到PHP上來，一方面能夠快速開發(fā)，另外一方面性能也不會存在問題。
***，關于影響PHP性能的關鍵因素的具體分析和關于語言函數(shù)級別PHP與C的基準性能對比分析，請關注下文《深入探討PHP性能問題》。
原文：http://stblog.baidu-tech.com/?p=1343
分享名稱：大話PHP之性能
瀏覽路徑：http://www.dlmjj.cn/article/dhchoce.html
