大話PHP之效能

1緣起

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

2從原理分析PHP效能

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

2.1記憶體管理

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

 

2.2變數

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

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/13560621S-0.jpg" />

圖一、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指令碼的運行機制如所示：

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/13560CH9-1.jpg" />

圖二、PHP運行機制

PHP的運行階段也分成三個階段：
●Parse。文法分析階段。
● Compile。編譯產出opcode中間碼。
● Execute。運行，動態運行進行輸出。

通過也可以看出，其實在PHP內部本身也是存在編譯的過程。事實上，在標準的生產環境中，也都基本上利用了這個特點，比如說opcode cache工具apc、eacc、xcache等等。基於opcode cache，能到做到“PHP指令碼編譯一次，多次運行”的效果。從這點上，PHP就和JAVA的半編譯機制非常類似。

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

2.5動態運行

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

但為什麼還有很多人感覺PHP慢呢？尤其是一些計算量的效能對比上，總發現PHP處理的效能相對比較低效http://shootout.alioth.debian.org/u32/php.php）。這個時候就不得不談PHP動態語言的特性所帶來的效能問題了，由於PHP是動態運行時，所以所有的變數、函數、對象調用、範圍實現等等都是在執行階段中才確定的。這個從根本上決定了PHP效能中很難改變的一些東西：在C/C++等能夠在靜態編譯階段確定的變數、函數，在PHP中需要在動態運行中確定，也就決定了PHP中間碼不能直接運行而需要運行在Zend Engine上。

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

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

 

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

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

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/13560A2S-2.jpg" />

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

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

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

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/13560AU4-3.jpg" />

圖3、PHP運行執行個體

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

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

但所有的這種編譯最佳化方案，都基本上是犧牲了PHP動態啟動並執行特性。當然可以在具體的編譯最佳化中去對動態特性做一些折中，但很難做到完完全全的相容。

2.6網路模型

目前採用PHP的方式，比較理想和通用的模式是採用fastcgiPHP-FPM）。Php-fpm在網路模型上比較類似nginx，採用了多進程Master+多worker的模式。Php-fpm本身是基於libevent中的epoll模型。從網路模型來看，該方式也不會和其他網路模型存在效能差異。

2.7結論

從上面分析來看，在基礎的記憶體管理、變數、函數、運行機制、網路模型方面，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架構。

其他說明：

目標機器的部署方式：

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/1356061941-4.jpg" />

指令碼。

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

3.2裸PHP效能

最簡單的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!’;  
  
 
  
}  
  
 
  
}  
  
 
  
?> 
  
 
 

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

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/1356062557-5.jpg" />

3.3裸PHP架構效能

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

 

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

壓力測試結果如下：

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/13560B423-6.jpg" />

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

3.4標準PHP模組的基準效能

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

●路由分發。

●自動載入。

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

●錯誤處理。

●時間校正。

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

●編碼識別&編碼轉化。

●標準設定檔的解析和調用

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

測試結果如下：

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/13560AW0-7.jpg" />

3.5結論

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

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

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

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

3、    一個標準的PHP模組，基準效能能夠達到2000QPS80 cpu idle）。

4PHP與C效能對比分析

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

那麼，本章節要談論的一個話題就是：C寫的商務邏輯和PHP寫的商務邏輯模組進行效能對比，採用真實的資料來說話。

4.1前提

為什麼要特別說出這個前提呢？因為在理想情況下，一個功能採用PHP實現，該效能鐵定不可能比理想的C寫出來好。這個前提需要特別注意。

但為什麼還要對比呢？因為在現實情況下，能寫出非常優秀的C程式，並且在頻繁修改的情況下還能做到完全高效能的又有幾個呢？並且在現實的應用中C實現的效能是否真的全都都比PHP要好好幾倍呢？這些目前都沒有確切的資料來論證。

所以，本章節的對比是基於現實中的情況來進行的，並採用真實資料來說話。

4.2 真實業務模組PHP模組 VS C模組4.2.1業務模組介紹

一個真實的案列，該業務模組的流量高達數十億。該模組的架構圖如下：

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/1356064363-8.jpg" />

圖4、業務模組架構圖

該業務模組功能非常簡單，上層是web server，下遊是各個資料模組。都是基於socket進行資料互動。該業務模組的主要工作模型是：響應web server的請求，根據請求從各個後端資料模組讀取相應資料，並根據資料產出最終的HTML頁面返回給web伺服器。

為了方便後續介紹，定義CUI表示用C實現的模組，PHPUI表示用PHP實現的模組。

4.2.2C/C++模組的效能資料結果

09年，該模組重構選擇了一個新的C/C++架構。當時重構的時候，該模組串連的後端資料模組規模在5-7個。

基於C/C++的模組，最終測試資料資料分成兩個部分：

一、效能對比測試。

基於當時線上壓力，進行真實資料的效能測試。所以當時只測試一個壓力資料如下：

壓力：210QPS

CPUIDLE）：84.18

二、極限效能測試1。

該測試模型是：CUI只串連一個核心資料模組，其他資料模組完全關閉。

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/13560B154-9.jpg" />

三、極限效能測試2。

該測試模型是：CUI串連後端一個核心資料模組，3個資料模組，其他資料模組不串連。

測試後效能資料如下：

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/13560B2O-10.jpg" />

4.2.3 PHP實現模組的效能測試資料

到11年，基於09年的CUI基本上達到了代碼不看維護的地步。而且這個時候，CUI的極限效能已經不到600QPS主要原因是隨著項目的發展，後端資料模組的數目增加到14個）。據此，決定採用PHP方案來重寫整個模組，併產出最終的pbui模組。

效能測試結果分成兩種：

1、PHPUI串連一個核心模組。測試資料如下：

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/1356063132-11.jpg" />

圖5、PHPUI效能測試結果1

2、PHPUI串連後端所有模組14個）。測試效能資料如下：

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/1356063324-12.jpg" />

圖6、PHPUI效能測試結果2

4.2.4資料對比結論

由於PHPUI和CUI的商務邏輯和測試方法都不完全相同，所以抽取了部分大體能對比的點進行整理。具體對比資料如下：

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/1356064b1-13.jpg" />

從上面的對比資料來看，在真實的商務專案中，PHPUI的效能並不會比CUI差。這個不是簡簡單單一個模組來驗證的，在部門裡面，我們有不少模組都是從C/C++遷移到PHP，從遷移的結果來看，並沒有存在質的效能下降，大部分模組遷移後效能指標都是非常接近的。

這個時候就需要思考為什麼會這樣了？細分來說有兩個問題：

1、   為什麼在真實商務專案中，PHPUI的效能並不會比CUI差太多？

2、  為什麼基準的PHP效能這麼高，80CPU的情況下2000QPS，但到了真實的PHP模組中只能是200QPS？

其實這兩個問題，也可以歸結成一種原因：在真實商務專案中，影響效能更多的不是說採用了什麼語言，而是其業務相關的部分，比如說socket互動次數，比如說字串處理，也比如說網路互動包大小。

OK。那麼接下來的關鍵是找出影響效能的關鍵因素。

4.2.5影響PHP模組效能的關鍵因素

從前面分析，我們得出，影響前端PHP模組效能的關鍵因素不是語言本身是否是PHP/JAVA/C都不重要）。那麼到底影響PHP業務模組效能的關鍵因素在哪裡呢？CPU耗時是統計一個項目效能的關鍵點之一，考慮到系統中都列印出了系列日誌。通過分析日誌中請求的耗時分布可以大體上看出關鍵點。

在我們系統中，CPU耗時重點列印出以下幾個方面：

1、  請求總時間。

2、  請求關鍵函數的效能，其中所有的socket互動都有耗時計算。

3、  模版渲染也是好事的一個關鍵點。

在前面分析中，我們基本上判定socket和字串處理是一個關鍵點之一，通過資料我們來驗證下。抽取一個模組指定數目的日誌，進行綜合分析得出以下資料：

 

650) this.width=650;" border="0" alt="" src="http://www.bkjia.com/uploads/allimg/131228/13560615X-14.jpg" />

通過這個可以看出，在一個業務模組中，影響最大的是socket資料互動，其次是大量的字串處理。具體細分來說是以下幾個因素：socket互動次數、socket互動包大小、socket互動回應時間、字串處理。

4.2.6結論

通過上述分析，可以得出以下結論：在前端業務模組中，PHP語言本身不會成為效能瓶頸。因為影響效能的幾個關鍵因數是：

● 網路互動數目。

●  網路互動資料大小，包含資料打包解包開銷。

● 網路互動回應時間。

●  大量的字串處理。

5最終結論

通過上述三個章節的具體分析，可以得出以下結論：

1、從PHP實現原理來看，PHP屬於半編譯型語言，並且在各個方面都進行了大量的最佳化工作，本身不會存在明顯的效能問題。但由於動態語言的特性，決定了PHP需要運行在Zend Engine虛擬機器上，並且在變數尋找、函數調用、範圍切換等各個方面需要一些額外開銷。

2、從PHP的基準效能來看，PHP本身不會存在明顯的資源消耗，單機QPS能夠輕鬆過W， PHP架構本身也不會對業務系統的效能帶來關鍵性的影響。

3、從真實的應用情境來看，基於C語言實現的模組不見得比基於PHP實現的模組效能高效很多。因為在真實的應用情境中，更多的效能開銷在於網路資料互動和字串處理。語言方面微小的效能差異不會成為瓶頸。

據此，可以推出：基於C語言實現的大部分業務系統都可以考慮遷移到PHP上來，一方面能夠快速開發，另外一方面效能也不會存在問題。

最後，關於影響PHP效能的關鍵因素的具體分析和關於語言函數層級PHP與C的基準效能對比分析，請關注下文《深入探討PHP效能問題》。

6參考文檔

http://yanbin.org/

https://wiki.php.net/internals/zend_mm

http://blog.xiuwz.com/2011/11/09/php-using-internal-zval/

http://developers.facebook.com/blog/post/358/

https://github.com/facebook/hiphop-php

by xuliqiang

 

本文首發於：搜尋研發部官方部落格】http://stblog.baidu-tech.com/?p=1343關注百度技術沙龍】

本文出自 “百度技術部落格” 部落格，請務必保留此出處http://baidutech.blog.51cto.com/4114344/742971