大話PHP之性能

作者：佚名 2011-12-02 08:51:19

本文就是圍繞這么一個(gè)話題來(lái)進(jìn)行探討的。從源碼、應(yīng)用場(chǎng)景、基準(zhǔn)性能、對(duì)比分析等幾個(gè)方面深入分析PHP之性能問(wèn)題，通過(guò)真實(shí)的性能數(shù)據(jù)來(lái)說(shuō)話，最終找出影響PHP模塊性能的關(guān)鍵因素。

關(guān)于PHP，很多人的直觀感覺(jué)是PHP是一種靈活的腳本語(yǔ)言，庫(kù)類豐富，使用簡(jiǎn)單，安全，非常適合WEB開發(fā)，但性能低下。PHP的性能是否真的就如同大家的感覺(jué)一樣的差呢?本文就是圍繞這么一個(gè)話題來(lái)進(jìn)行探討的。從源碼、應(yīng)用場(chǎng)景、基準(zhǔn)性能、對(duì)比分析等幾個(gè)方面深入分析PHP之性能問(wèn)題，通過(guò)真實(shí)的性能數(shù)據(jù)來(lái)說(shuō)話，最終找出影響PHP模塊性能的關(guān)鍵因素。

從原理分析PHP性能

從原理分析PHP的性能，主要從以下幾個(gè)方面：內(nèi)存管理、變量、函數(shù)、運(yùn)行機(jī)制、網(wǎng)絡(luò)模型來(lái)進(jìn)行分析。

2.1內(nèi)存管理

類似Nginx的內(nèi)存管理方式，PHP在內(nèi)部也是基于內(nèi)存池，并且引入內(nèi)存池的生命周期概念。在內(nèi)存池方面，PHP對(duì)PHP腳本和擴(kuò)展的所有內(nèi)存相關(guān)操作都進(jìn)行了托管。對(duì)大內(nèi)存和小內(nèi)存的管理采用了不同的實(shí)現(xiàn)方式和優(yōu)化，具體可以參考以下文檔：http://www.laruence.com/2011/11/09/2277.html。在內(nèi)存分配和回收的生命周期內(nèi)，PHP采用一次初始化申請(qǐng)+動(dòng)態(tài)擴(kuò)容+內(nèi)存標(biāo)識(shí)回收機(jī)制，并且在每次請(qǐng)求結(jié)束后直接對(duì)內(nèi)存池進(jìn)行重新mask。

2.2變量

總所周知，PHP是一種弱變量類型的語(yǔ)言，所以在PHP內(nèi)部，所有的PHP變量都對(duì)應(yīng)成一種類型Zval，其中具體定義如下：

圖一、PHP變量

在變量方面，PHP做了大量的優(yōu)化工作，比如說(shuō)Reference counting和copy on writer機(jī)制。這樣能夠保證內(nèi)存使用上的優(yōu)化，并且減少內(nèi)存拷貝次數(shù)(請(qǐng)參考http://blog.xiuwz.com/2011/11/09/php-using-internal-zval/)。在數(shù)組方面，PHP內(nèi)部采用高效的hashtable來(lái)實(shí)現(xiàn)。

2.3函數(shù)

在PHP內(nèi)部，所有的PHP函數(shù)都回轉(zhuǎn)化成內(nèi)部的一個(gè)函數(shù)指針。比如說(shuō)擴(kuò)展中函數(shù)

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

在內(nèi)部展開后就會(huì)是一個(gè)函數(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  
);

從這個(gè)角度來(lái)看，PHP函數(shù)在內(nèi)部也是對(duì)應(yīng)一個(gè)函數(shù)指針。

2.4運(yùn)行機(jī)制

在話說(shuō)PHP性能的時(shí)候，很多人都會(huì)說(shuō)“C/C++是編譯型，JAVA是半編譯型，PHP是解釋型”。也就是說(shuō)PHP是先動(dòng)態(tài)解析再代碼運(yùn)行的，所以從這個(gè)角度來(lái)看，PHP性能必然很差。

的確，從PHP腳本運(yùn)行來(lái)輸出，的確是一個(gè)動(dòng)態(tài)解析再代碼運(yùn)行的過(guò)程。具體來(lái)說(shuō)，PHP腳本的運(yùn)行機(jī)制如下圖所示：

圖二、PHP運(yùn)行機(jī)制

PHP的運(yùn)行階段也分成三個(gè)階段：

●Parse。語(yǔ)法分析階段。

● Compile。編譯產(chǎn)出opcode中間碼。

● Execute。運(yùn)行，動(dòng)態(tài)運(yùn)行進(jìn)行輸出。

通過(guò)上圖也可以看出，其實(shí)在PHP內(nèi)部本身也是存在編譯的過(guò)程。事實(shí)上，在標(biāo)準(zhǔn)的生產(chǎn)環(huán)境中，也都基本上利用了這個(gè)特點(diǎn)，比如說(shuō)opcode cache工具apc、eacc、xcache等等。基于opcode cache，能到做到“PHP腳本編譯一次，多次運(yùn)行”的效果。從這點(diǎn)上，PHP就和JAVA的半編譯機(jī)制非常類似。

所以，從運(yùn)行機(jī)制上來(lái)看，PHP的運(yùn)行模式和JAVA是非常類似的，都是先產(chǎn)生中間碼，然后運(yùn)行在不同虛擬機(jī)上。

2.5動(dòng)態(tài)運(yùn)行

從上面的幾個(gè)分析來(lái)看，PHP在內(nèi)存管理、變量、函數(shù)、運(yùn)行機(jī)制等幾個(gè)方面都做了大量的工作，所以從原理來(lái)看，PHP不應(yīng)該存在性能問(wèn)題，性能至少也應(yīng)該和JAVA比較接近。

但為什么還有很多人感覺(jué)PHP慢呢?尤其是一些計(jì)算量的性能對(duì)比上，總發(fā)現(xiàn)PHP處理的性能相對(duì)比較低效(http://shootout.alioth.debian.org/u32/php.php)。這個(gè)時(shí)候就不得不談PHP動(dòng)態(tài)語(yǔ)言的特性所帶來(lái)的性能問(wèn)題了，由于PHP是動(dòng)態(tài)運(yùn)行時(shí)，所以所有的變量、函數(shù)、對(duì)象調(diào)用、作用域?qū)崿F(xiàn)等等都是在執(zhí)行階段中才確定的。這個(gè)從根本上決定了PHP性能中很難改變的一些東西：在C/C++等能夠在靜態(tài)編譯階段確定的變量、函數(shù)，在PHP中需要在動(dòng)態(tài)運(yùn)行中確定，也就決定了PHP中間碼不能直接運(yùn)行而需要運(yùn)行在Zend Engine上。

說(shuō)到PHP變量的具體實(shí)現(xiàn)，又不得不說(shuō)一個(gè)東西了：hashtable。Hashtable可以說(shuō)在PHP靈魂之一，在PHP內(nèi)部廣泛用到，包含變量符號(hào)棧、函數(shù)符號(hào)棧等等都是基于hashtable的。

以PHP變量為例來(lái)說(shuō)明下PHP的動(dòng)態(tài)運(yùn)行特點(diǎn)，比如說(shuō)代碼：

<?php 
$var = “hello, blog.xiuwz.com”;  
?>

該代碼的執(zhí)行結(jié)果就是在變量符號(hào)棧(是一個(gè)hashtable)中新增一個(gè)項(xiàng)

當(dāng)要使用到該變量時(shí)候，就去變量符合棧中去查找(也就是變量調(diào)用對(duì)出了一個(gè)hash查找的過(guò)程)。

同樣對(duì)于函數(shù)調(diào)用也基本上類似有一個(gè)函數(shù)符號(hào)棧(hashtable)。

其實(shí)關(guān)于動(dòng)態(tài)運(yùn)行的變量查找特點(diǎn)，在PHP的運(yùn)行機(jī)制中也能看出一些。PHP代碼通過(guò)解釋、編譯后的流程下圖：

圖3、PHP運(yùn)行實(shí)例

從上圖可以看出，PHP代碼在compile之后，產(chǎn)出的了類符號(hào)表、函數(shù)符號(hào)表、和OPCODE。在真正執(zhí)行的時(shí)候，zend Engine會(huì)根據(jù)op code去對(duì)應(yīng)的符號(hào)表中進(jìn)行查找，處理。

從某種程度上，在這種問(wèn)題的上，很難找到解決方案。因?yàn)檫@是由于PHP語(yǔ)言的動(dòng)態(tài)特性所決定的。但是在國(guó)內(nèi)外也有不少的人在尋找解決方案。因?yàn)橥ㄟ^(guò)這樣，能夠從根本上完全的優(yōu)化PHP。典型的列子有facebook的hiphop(https://github.com/facebook/hiphop-php)。

但所有的這種編譯優(yōu)化方案，都基本上是犧牲了PHP動(dòng)態(tài)運(yùn)行的特性。當(dāng)然可以在具體的編譯優(yōu)化中去對(duì)動(dòng)態(tài)特性做一些折中，但很難做到完完全全的兼容。

2.6網(wǎng)絡(luò)模型

目前采用PHP的方式，比較理想和通用的模式是采用fastcgi(PHP-FPM)。Php-fpm在網(wǎng)絡(luò)模型上比較類似nginx，采用了多進(jìn)程Master+多worker的模式。Php-fpm本身是基于libevent中的epoll模型。從網(wǎng)絡(luò)模型來(lái)看，該方式也不會(huì)和其他網(wǎng)絡(luò)模型存在性能差異。

2.7結(jié)論

從上面分析來(lái)看，在基礎(chǔ)的內(nèi)存管理、變量、函數(shù)、運(yùn)行機(jī)制、網(wǎng)絡(luò)模型方面，PHP本身并不會(huì)存在明顯的性能差異，但由于PHP的動(dòng)態(tài)運(yùn)行特性，決定了PHP和其他的編譯型語(yǔ)言相比，所有的變量查找、函數(shù)運(yùn)行等等都會(huì)多一些hash查找的CPU開銷和額外的內(nèi)存開銷，至于這種開銷具體有多大，可以通過(guò)后續(xù)的基準(zhǔn)性能和對(duì)比分析得出。

因此，也可以大體看出PHP不太適合的一些場(chǎng)景：大量計(jì)算性任務(wù)、大數(shù)據(jù)量的運(yùn)算、內(nèi)存要求很嚴(yán)格的應(yīng)用場(chǎng)景。如果要實(shí)現(xiàn)這些功能，也建議通過(guò)擴(kuò)展的方式實(shí)現(xiàn)，然后再提供鉤子函數(shù)給PHP調(diào)用。這樣可以減低內(nèi)部計(jì)算的變量、函數(shù)等系列開銷。

3基準(zhǔn)性能

對(duì)于PHP基準(zhǔn)性能，目前缺少標(biāo)準(zhǔn)的數(shù)據(jù)。大多數(shù)同學(xué)都存在感性的認(rèn)識(shí)，有人認(rèn)為800QPS就是PHP的極限了。此外，對(duì)于框架的性能和框架對(duì)性能的影響很沒(méi)有響應(yīng)的權(quán)威數(shù)字。

本章節(jié)的目的是給出一個(gè)基準(zhǔn)的參考性能指標(biāo)，通過(guò)數(shù)據(jù)給大家一個(gè)直觀的了解。

具體的基準(zhǔn)性能有以下幾個(gè)方面：

1、裸PHP性能。完成基本的功能。

2、裸框架的性能。只做最簡(jiǎn)單的路由分發(fā)，只走通核心功能。

3、標(biāo)準(zhǔn)模塊的基準(zhǔn)性能。所謂標(biāo)準(zhǔn)模塊的基準(zhǔn)性能，是指一個(gè)具有完整服務(wù)模塊功能的基準(zhǔn)性能。

3.1環(huán)境說(shuō)明

測(cè)試環(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

軟件相關(guān)：

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)

bingo2：

PHP框架。

其他說(shuō)明：

目標(biāo)機(jī)器的部署方式：

腳本。

測(cè)試壓力機(jī)器和目標(biāo)機(jī)器獨(dú)立部署。

3.2裸PHP性能

最簡(jiǎn)單的PHP腳本。

<?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!’;  
}  
}  
?>

通過(guò)壓力工具測(cè)試結(jié)果如下：

3.3裸PHP框架性能

為了和3.2的對(duì)比，基于bingo2框架實(shí)現(xiàn)了類似的功能。代碼如下

<?php 
require_once ‘Bingo/Controller/Front.php’;  
$objFrontController = Bingo_Controller_Front::getInstance(array(  
‘actionDir’ => ‘./actions’,  
));  
$objFrontController->dispatch();  
?>

壓力測(cè)試結(jié)果如下：

從該測(cè)試結(jié)果可以看出：框架雖然有一定的消耗，但對(duì)整體的性能來(lái)說(shuō)影響是非常小的。

3.4標(biāo)準(zhǔn)PHP模塊的基準(zhǔn)性能

所謂標(biāo)準(zhǔn)PHP模塊，是指一個(gè)PHP模塊所必須要具體的基本功能：

●路由分發(fā)。

●自動(dòng)加載。

●LOG初始化&Notice日志打印。所以的UI請(qǐng)求都一條標(biāo)準(zhǔn)的日志。

●錯(cuò)誤處理。

●時(shí)間校正。

●自動(dòng)計(jì)算每個(gè)階段耗時(shí)開銷。

●編碼識(shí)別&編碼轉(zhuǎn)化。

●標(biāo)準(zhǔn)配置文件的解析和調(diào)用

采用bingo2的代碼自動(dòng)生成工具產(chǎn)生標(biāo)準(zhǔn)的測(cè)試PHP模塊：test。

測(cè)試結(jié)果如下：

3.5結(jié)論

從測(cè)試數(shù)據(jù)的結(jié)論來(lái)看，PHP本身的性能還是可以的。基準(zhǔn)性能完全能夠達(dá)到幾千甚至上W的QPS。至于為什么在大多數(shù)的PHP模塊中表現(xiàn)不佳，其實(shí)這個(gè)時(shí)候更應(yīng)該去找出系統(tǒng)的瓶頸點(diǎn)，而不是簡(jiǎn)單的說(shuō)OK，PHP不行，那我們換C來(lái)搞吧。(下一個(gè)章節(jié)，會(huì)通過(guò)一些例子來(lái)對(duì)比，采用C來(lái)處理不見得有特別的優(yōu)勢(shì))

通過(guò)基準(zhǔn)數(shù)據(jù)，可以得出以下幾個(gè)具體的結(jié)論：

1、 PHP本身性能也很不錯(cuò)。簡(jiǎn)單功能下能夠達(dá)到5000QPS(50CPU IDLE)，極限也能過(guò)W。

2、 PHP框架本身對(duì)性能影響非常有限。尤其是在有一定業(yè)務(wù)邏輯和數(shù)據(jù)交互的情況下，幾乎可以忽略。

3、一個(gè)標(biāo)準(zhǔn)的PHP模塊，基準(zhǔn)性能能夠達(dá)到2000QPS(80 cpu idle)。

#p#

4 PHP與C性能對(duì)比分析

很多時(shí)候，大家發(fā)現(xiàn)PHP模塊性能不行的時(shí)候，就來(lái)一句“ok，我們采用C重寫吧”。在公司內(nèi)，采用C/C++來(lái)寫業(yè)務(wù)邏輯模塊的現(xiàn)象到處都有，在前幾年甚至幾乎全部都是采用C來(lái)寫。那時(shí)候大家寫的真是一個(gè)痛苦：調(diào)試難、敏捷不要談。

那么，本章節(jié)要談?wù)摰囊粋€(gè)話題就是：C寫的業(yè)務(wù)邏輯和PHP寫的業(yè)務(wù)邏輯模塊進(jìn)行性能對(duì)比，采用真實(shí)的數(shù)據(jù)來(lái)說(shuō)話。

4.1前提

為什么要特別說(shuō)出這個(gè)前提呢?因?yàn)樵诶硐肭闆r下，一個(gè)功能采用PHP實(shí)現(xiàn)，該性能鐵定不可能比理想的C寫出來(lái)好。這個(gè)前提需要特別注意。

但為什么還要對(duì)比呢?因?yàn)樵诂F(xiàn)實(shí)情況下，能寫出非常優(yōu)秀的C程序，并且在頻繁修改的情況下還能做到完全高性能的又有幾個(gè)呢?并且在現(xiàn)實(shí)的應(yīng)用中C實(shí)現(xiàn)的性能是否真的全都都比PHP要好好幾倍呢?這些目前都沒(méi)有確切的數(shù)據(jù)來(lái)論證。

所以，本章節(jié)的對(duì)比是基于現(xiàn)實(shí)中的情況來(lái)進(jìn)行的，并采用真實(shí)數(shù)據(jù)來(lái)說(shuō)話。

4.2 真實(shí)業(yè)務(wù)模塊PHP模塊 VS C模塊

4.2.1業(yè)務(wù)模塊介紹

一個(gè)真實(shí)的案列，該業(yè)務(wù)模塊的流量高達(dá)數(shù)十億。該模塊的架構(gòu)圖如下：

圖4、業(yè)務(wù)模塊架構(gòu)圖

該業(yè)務(wù)模塊功能非常簡(jiǎn)單，上層是web server，下游是各個(gè)數(shù)據(jù)模塊。都是基于socket進(jìn)行數(shù)據(jù)交互。該業(yè)務(wù)模塊的主要工作模型是：響應(yīng)web server的請(qǐng)求，根據(jù)請(qǐng)求從各個(gè)后端數(shù)據(jù)模塊讀取相應(yīng)數(shù)據(jù)，并根據(jù)數(shù)據(jù)產(chǎn)出最終的HTML頁(yè)面返回給web服務(wù)器。

為了方便后續(xù)介紹，定義CUI表示用C實(shí)現(xiàn)的模塊，PHPUI表示用PHP實(shí)現(xiàn)的模塊。

4.2.2C/C++模塊的性能數(shù)據(jù)結(jié)果

09年，該模塊重構(gòu)選擇了一個(gè)新的C/C++框架。當(dāng)時(shí)重構(gòu)的時(shí)候，該模塊連接的后端數(shù)據(jù)模塊規(guī)模在5-7個(gè)。

基于C/C++的模塊，最終測(cè)試數(shù)據(jù)數(shù)據(jù)分成兩個(gè)部分：

一、性能對(duì)比測(cè)試。

基于當(dāng)時(shí)線上壓力，進(jìn)行真實(shí)數(shù)據(jù)的性能測(cè)試。所以當(dāng)時(shí)只測(cè)試一個(gè)壓力數(shù)據(jù)如下：

壓力：210QPS

CPU(IDLE)：84.18

二、極限性能測(cè)試1。

該測(cè)試模型是：CUI只連接一個(gè)核心數(shù)據(jù)模塊，其他數(shù)據(jù)模塊完全關(guān)閉。

三、極限性能測(cè)試2。

該測(cè)試模型是：CUI連接后端一個(gè)核心數(shù)據(jù)模塊，3個(gè)數(shù)據(jù)模塊，其他數(shù)據(jù)模塊不連接。

測(cè)試后性能數(shù)據(jù)如下：

4.2.3 PHP實(shí)現(xiàn)模塊的性能測(cè)試數(shù)據(jù)

到11年，基于09年的CUI基本上達(dá)到了代碼不看維護(hù)的地步。而且這個(gè)時(shí)候，CUI的極限性能已經(jīng)不到600QPS(主要原因是隨著項(xiàng)目的發(fā)展，后端數(shù)據(jù)模塊的數(shù)目增加到14個(gè))。據(jù)此，決定采用PHP方案來(lái)重寫整個(gè)模塊，并產(chǎn)出最終的pbui模塊。

性能測(cè)試結(jié)果分成兩種：

1、PHPUI連接一個(gè)核心模塊。測(cè)試數(shù)據(jù)如下：

圖5、PHPUI性能測(cè)試結(jié)果1

2、PHPUI連接后端所有模塊(14個(gè))。測(cè)試性能數(shù)據(jù)如下：

圖6、PHPUI性能測(cè)試結(jié)果2

4.2.4數(shù)據(jù)對(duì)比結(jié)論

由于PHPUI和CUI的業(yè)務(wù)邏輯和測(cè)試方法都不完全相同，所以抽取了部分大體能對(duì)比的點(diǎn)進(jìn)行整理。具體對(duì)比數(shù)據(jù)如下：

從上面的對(duì)比數(shù)據(jù)來(lái)看，在真實(shí)的業(yè)務(wù)項(xiàng)目中，PHPUI的性能并不會(huì)比CUI差。這個(gè)不是簡(jiǎn)簡(jiǎn)單單一個(gè)模塊來(lái)驗(yàn)證的，在部門里面，我們有不少模塊都是從C/C++遷移到PHP，從遷移的結(jié)果來(lái)看，并沒(méi)有存在質(zhì)的性能下降，大部分模塊遷移后性能指標(biāo)都是非常接近的。

這個(gè)時(shí)候就需要思考為什么會(huì)這樣了?細(xì)分來(lái)說(shuō)有兩個(gè)問(wèn)題：

1、為什么在真實(shí)業(yè)務(wù)項(xiàng)目中，PHPUI的性能并不會(huì)比CUI差太多?

2、為什么基準(zhǔn)的PHP性能這么高，80CPU的情況下2000QPS，但到了真實(shí)的PHP模塊中只能是200QPS?

其實(shí)這兩個(gè)問(wèn)題，也可以歸結(jié)成一種原因：在真實(shí)業(yè)務(wù)項(xiàng)目中，影響性能更多的不是說(shuō)采用了什么語(yǔ)言，而是其業(yè)務(wù)相關(guān)的部分，比如說(shuō)socket交互次數(shù)，比如說(shuō)字符串處理，也比如說(shuō)網(wǎng)絡(luò)交互包大小。

OK。那么接下來(lái)的關(guān)鍵是找出影響性能的關(guān)鍵因素。

4.2.5影響PHP模塊性能的關(guān)鍵因素

從前面分析，我們得出，影響前端PHP模塊性能的關(guān)鍵因素不是語(yǔ)言本身(是否是PHP/JAVA/C都不重要)。那么到底影響PHP業(yè)務(wù)模塊性能的關(guān)鍵因素在哪里呢?CPU耗時(shí)是統(tǒng)計(jì)一個(gè)項(xiàng)目性能的關(guān)鍵點(diǎn)之一，考慮到系統(tǒng)中都打印出了系列日志。通過(guò)分析日志中請(qǐng)求的耗時(shí)分布可以大體上看出關(guān)鍵點(diǎn)。

在我們系統(tǒng)中，CPU耗時(shí)重點(diǎn)打印出以下幾個(gè)方面：

1、請(qǐng)求總時(shí)間。

2、請(qǐng)求關(guān)鍵函數(shù)的性能，其中所有的socket交互都有耗時(shí)計(jì)算。

3、模版渲染也是好事的一個(gè)關(guān)鍵點(diǎn)。

在前面分析中，我們基本上判定socket和字符串處理是一個(gè)關(guān)鍵點(diǎn)之一，通過(guò)數(shù)據(jù)我們來(lái)驗(yàn)證下。抽取一個(gè)模塊指定數(shù)目的日志，進(jìn)行綜合分析得出以下數(shù)據(jù)：

通過(guò)這個(gè)可以看出，在一個(gè)業(yè)務(wù)模塊中，影響***的是socket數(shù)據(jù)交互，其次是大量的字符串處理。具體細(xì)分來(lái)說(shuō)是以下幾個(gè)因素：socket交互次數(shù)、socket交互包大小、socket交互響應(yīng)時(shí)間、字符串處理。

4.2.6結(jié)論

通過(guò)上述分析，可以得出以下結(jié)論：在前端業(yè)務(wù)模塊中，PHP語(yǔ)言本身不會(huì)成為性能瓶頸。因?yàn)橛绊懶阅艿膸讉€(gè)關(guān)鍵因數(shù)是：

● 網(wǎng)絡(luò)交互數(shù)目。

● 網(wǎng)絡(luò)交互數(shù)據(jù)大小，包含數(shù)據(jù)打包解包開銷。

● 網(wǎng)絡(luò)交互響應(yīng)時(shí)間。

● 大量的字符串處理。

5最終結(jié)論

通過(guò)上述三個(gè)章節(jié)的具體分析，可以得出以下結(jié)論：

1、從PHP實(shí)現(xiàn)原理來(lái)看，PHP屬于半編譯型語(yǔ)言，并且在各個(gè)方面都進(jìn)行了大量的優(yōu)化工作，本身不會(huì)存在明顯的性能問(wèn)題。但由于動(dòng)態(tài)語(yǔ)言的特性，決定了PHP需要運(yùn)行在Zend Engine虛擬機(jī)上，并且在變量查找、函數(shù)調(diào)用、作用域切換等各個(gè)方面需要一些額外開銷。

2、從PHP的基準(zhǔn)性能來(lái)看，PHP本身不會(huì)存在明顯的資源消耗，單機(jī)QPS能夠輕松過(guò)W， PHP框架本身也不會(huì)對(duì)業(yè)務(wù)系統(tǒng)的性能帶來(lái)關(guān)鍵性的影響。

3、從真實(shí)的應(yīng)用場(chǎng)景來(lái)看，基于C語(yǔ)言實(shí)現(xiàn)的模塊不見得比基于PHP實(shí)現(xiàn)的模塊性能高效很多。因?yàn)樵谡鎸?shí)的應(yīng)用場(chǎng)景中，更多的性能開銷在于網(wǎng)絡(luò)數(shù)據(jù)交互和字符串處理。語(yǔ)言方面微小的性能差異不會(huì)成為瓶頸。

據(jù)此，可以推出：基于C語(yǔ)言實(shí)現(xiàn)的大部分業(yè)務(wù)系統(tǒng)都可以考慮遷移到PHP上來(lái)，一方面能夠快速開發(fā)，另外一方面性能也不會(huì)存在問(wèn)題。

***，關(guān)于影響PHP性能的關(guān)鍵因素的具體分析和關(guān)于語(yǔ)言函數(shù)級(jí)別PHP與C的基準(zhǔn)性能對(duì)比分析，請(qǐng)關(guān)注下文《深入探討PHP性能問(wèn)題》。

原文：http://stblog.baidu-tech.com/?p=1343

【編輯推薦】