深度探討 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的動態運行特色，好比說代碼：

<?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腳本。

<?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框架實現了相似的功能。代碼以下

<?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來寫。那時候你們寫的真是一個痛苦：調試難、敏捷不要談。

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