【編者按】此前，閱讀過了很多關(guān)于 PHP 性能分析的文章，不過寫的都是一條一條的規(guī)則，而且，這些規(guī)則并沒有上下文，也沒有明確的實(shí)驗(yàn)來體現(xiàn)出這些規(guī)則的優(yōu)勢，同時討論的也側(cè)重于一些語法要點(diǎn)。本文就改變 PHP 性能分析的角度，并通過實(shí)例來分析出 PHP 的性能方面需要注意和改進(jìn)的點(diǎn)。

對 PHP 性能的分析，我們從兩個層面著手，把這篇文章也分成了兩個部分，一個是宏觀層面，所謂宏觀層面，就是 PHP 語言本身和環(huán)境層面，一個是應(yīng)用層面，就是語法和使用規(guī)則的層面，不過不僅探討規(guī)則，更輔助以示例的分析。

宏觀層面，也就是對 PHP 語言本身的性能分析又分為三個方面：

1. PHP 作為解釋性語言性能有其天然的缺陷

2. PHP 作為動態(tài)類型語言在性能上也有提升的空間

3. 當(dāng)下主流 PHP 版本本身語言引擎性能

一、PHP 作為解釋性語言的性能分析與提升

PHP 作為一門腳本語言，也是解釋性語言，是其天然性能受限的原因，因?yàn)橥幾g型語言在運(yùn)行之前編譯成二進(jìn)制代碼不同，解釋性語言在每一次運(yùn)行都面對原始腳本的輸入、解析、編譯，然后執(zhí)行。如下是 PHP 作為解釋性語言的執(zhí)行過程。

如上所示，從上圖可以看到，每一次運(yùn)行，都需要經(jīng)歷三個解析、編譯、運(yùn)行三個過程。

那優(yōu)化的點(diǎn)在哪里呢？可以想見，只要代碼文件確定，解析到編譯這一步都是確定的，因?yàn)槲募巡辉僮兓鴪?zhí)行，則由于輸入?yún)?shù)的不同而不同。在性能 優(yōu)化的世界里，至上絕招就是在獲得同樣結(jié)果的情況下，減少操作，這就是大名鼎鼎的緩存。緩存無處不在，緩存也是性能優(yōu)化的殺手锏。于是乎 OpCode 緩存這一招就出現(xiàn)了，只有***次需要解析和編譯，而在后面的執(zhí)行中，直接由腳本到 Opcode，從而實(shí)現(xiàn)了性能提速。執(zhí)行流程如下圖所示：

相對每一次解析、編譯，讀到腳本之后，直接從緩存讀取字節(jié)碼的效率會有大幅度的提升，提升幅度到底有多大呢？

我們來做一個沒有 Opcode 緩存的實(shí)驗(yàn)。20 個并發(fā)，總共 10000 次請求沒有經(jīng)過 opcode 緩存的請求，，得到如下結(jié)果：

其次，我們在服務(wù)器上打開 Opcode 緩存。要想實(shí)現(xiàn) opcode 緩存，只需要安裝 APC、Zend OPCache、eAccelerator 擴(kuò)展即可，即使安裝了多個，也只啟用其中一個。注意的是，修改了 php.ini 配置之后，需要重新加載 php-fpm 的配置。

這里分別啟用 APC 和 Zend OPCache 做實(shí)驗(yàn)。啟用 APC 的版本。

可以看到，速度有了較大幅度的提升，原來每個請求 110ms，每秒處理請求 182 個，啟用了 APC 之后 68ms，每秒處理請求 294 個，提升速度將近 40%。

在啟用了 Zend Opcache 的版本中，得到同 APC 大致相當(dāng)?shù)慕Y(jié)果。每秒處理請求 291 個，每請求耗時 68.5ms。

從上面的這個實(shí)驗(yàn)可以看到，所用的測試頁面，有 40ms 以上的時間花在了語法解析和編譯這兩項上。通過將這兩個操作緩存，可以將這個處理過程的速度大大提升。

這里附加補(bǔ)充一下，OpCode 到底是什么東東，OpCode 編譯之后的字節(jié)碼，我們可以使用bytekit 這樣的工具，或者使用 vld PHP 擴(kuò)展來實(shí)現(xiàn)對 PHP 的代碼編譯。如下是 vld 插件解析代碼的運(yùn)行結(jié)果。

可以看到每一行代碼被編譯成相應(yīng)的 OpCode 的輸出。

#p#

二、PHP 作為動態(tài)類型語言的性能分析與改進(jìn)

第二個是 PHP 語言是動態(tài)類型的語言，動態(tài)類型的語言本身由于涉及到在內(nèi)存中的類型推斷，比如在 PHP 中，兩個整數(shù)相加，我們能得到整數(shù)值，一個整數(shù)和一個字符串相加，甚至兩個字符串相加，都變成整數(shù)相加。而字符串和任何類型連接操作都成了字符串。

<?php
$a = 10.11;
$b = "30";
var_dump($a+$b);
var_dump("10"+$b);
var_dump(10+"20");
var_dump("10"+"20");


運(yùn)行結(jié)果如下：

float(40.11)
int(40)
int(30)
int(30)


語言的動態(tài)類型為開發(fā)者提供了方便，語言本身則會因?yàn)閯討B(tài)類型而降低效率。在 Swift 中，有一個特性叫類型推斷，我們可以看看類型推斷會帶來多大的一個效率上的差別呢？對于需要類型推斷與不需要類型推斷兩段 Swift 代碼，我們嘗試編譯一下看看效果如何。 ***段代碼如下：

這是一段 Swift 代碼，字典只有 14 個鍵值對，這段代碼的編譯，9 分鐘了還沒有編譯完成（5G 內(nèi)存，2.4GHz CPU），編譯環(huán)境為 Swift 1.2，Xcode 6.4。

但是如果調(diào)整代碼如下：

也就是加上了類型限定，避免了 planeLocation 的類型推斷。編譯過程花了 2S 。

可見，作為動態(tài)類型附加的類型推斷操作極大地降低了程序的編譯速度。 當(dāng)然，這個例子有點(diǎn)極端，用 Swift 來類比 PHP 也不一定合適，因?yàn)?Swift 語言本身也還在不斷的進(jìn)化過程中。本例子只是表明在編程語言中，如果是動態(tài)類型語言，就涉及到對動態(tài)類型的處理，從編譯的角度講是會受影響的。

那么作為動態(tài)類型的 PHP 的效率如何提升呢？從 PHP 語言本身這個層面是沒有辦法解決的，因?yàn)槟阍趺磳懸彩莿討B(tài)類型的代碼。解決辦法就是將PHP轉(zhuǎn)化為靜態(tài)類型的表示，也就是做成擴(kuò)展，可以看到，鳥哥的很多 項目，比如 Yaf 框架，都是做成了擴(kuò)展的，當(dāng)然這也是由于鳥哥是 C 高手。擴(kuò)展由于是 C 或者 C++ 而寫，所以不再是動態(tài)類型，又加之是編譯好的，而 C 語言本身的效率也會提升很多。所以效率會大幅度提高。

下面我們來看一段代碼，這段代碼，只是實(shí)現(xiàn)了簡單的素數(shù)運(yùn)算，能計算指定值以內(nèi)的素數(shù)個數(shù)，用的是普通的篩選法。現(xiàn)在看看擴(kuò)展實(shí)現(xiàn)，跟 PHP 原生實(shí)現(xiàn)的效率差別，這個差別當(dāng)然，不僅僅是動態(tài)類型和編譯類型的差別，還有語言效率的差別。

首先是用純 PHP 寫成的算法，計算 1000 萬以內(nèi)的素數(shù)個數(shù)，耗時在 33s 上下，實(shí)驗(yàn)了三次，得到的結(jié)果基本相同。

其次，我們將這個求素數(shù)個數(shù)的過程，編寫成了 PHP 擴(kuò)展，在擴(kuò)展中實(shí)現(xiàn)了 getprimenumbers 函數(shù)，輸入一個整數(shù)，返回小于該整數(shù)的素數(shù)。得到的結(jié)果如下，這個效率的提升是非常驚人的，在 1.4s 上下即返回。速度提升 20 倍以上。

可以想見，靜態(tài)和編譯類型的語言，其效率得到了驚人的提升。本程序的 C 語言代碼如下：


PHP_FUNCTION(get_prime_numbers) {     long value;     if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l", &value) == FAILURE) {             return;     }      int *numbers = (int *)malloc(sizeof(int)*128*10000);      memset(numbers, 0x0, 128*10000);     int num = 2;         numbers[0] = 2;         numbers[1] = 3;         bool flag = true;         double f = 0;         int i = 0;         int j = 0;         for(i=5; i<=value; i+=2)         {             flag = true;             f = sqrt(i);             for(j=0; j<num;j++)             {                 if(i%numbers[j]==0)                 {                     flag = false;                     break;                 }                 if(numbers[j]>f)                 {                     break;                 }             }             if(flag)             {                 numbers[num] = i;                 num++;             }         }         free(numbers);         RETURN_LONG(num); } 

#p#

三、PHP 語言本身底層性能引擎提升

第三個性能優(yōu)化層面是語言本身的性能提升，這個就不是我們普通開發(fā)者所能做的了。在 PHP 7以前，寄希望于小版本的改進(jìn)，但是改進(jìn)幅度不是非常的顯著，比如 PHP 5.3 、PHP 5.4、PHP 5.5、PHP 5.5 對同一段代碼的性能比較，有一定程度的進(jìn)步。

PHP 5.3 的版本在上面的例子中已講過，需要 33s 左右的時間，我們現(xiàn)在來看別的PHP版本。分別運(yùn)行如下：

PHP 5.4 版，相較 5.3 版已經(jīng)有一定程度的提升。快 6 秒左右。

PHP 5.5 版在 PHP 5.4的基礎(chǔ)上又進(jìn)了一步，快了 6S。

PHP5.6 反而有些退步。

PHP 7 果真是效率提升驚人，是 PHP5.3 的 3 倍以上。

以上是求素數(shù)腳本在各個 PHP 版本之間的運(yùn)行速度區(qū)別，盡管只測試了這一個程序，也不是特別的嚴(yán)謹(jǐn)，但是這是在同一臺機(jī)器上，而且編譯 configure 參數(shù)也基本一樣，還是有一定可比性的。

在宏觀層面，除了上面的這些之外，在實(shí)際的部署過程中，對 PHP 性能的優(yōu)化，還體現(xiàn)為要減少在運(yùn)行中所消耗的資源。所以 FastCGI 模式和 mod_php 的模式比傳統(tǒng)的 CGI 模式也更為受歡迎。因?yàn)樵趥鹘y(tǒng)的 CGI 模式中，在每一次腳本運(yùn)行都需要加載所有的模塊。而在程序運(yùn)行完成了之后，也要釋放模塊資源。如下圖所示：

而在 FastCGI 和 mod_php 模式中，則不需要如此。只有 php-fpm 或者 Apache 啟動的時候，需要加載一次所有的模塊，在具體的某次運(yùn)行過程中，并不需要再次加載和釋放相關(guān)的模塊資源。

這樣程序性能的效率得到了提升。以上就是有關(guān) PHP 宏觀層面的性能優(yōu)化的分析，在本文的第二部分我們將探討應(yīng)用方面的 PHP 優(yōu)化準(zhǔn)則。敬請期待！

本文系 OneAPM 工程師編譯整理。OneAPM 是應(yīng)用性能管理領(lǐng)域的新興領(lǐng)軍企業(yè)，能幫助企業(yè)用戶和開發(fā)者輕松實(shí)現(xiàn)：緩慢的程序代碼和 SQL 語句的實(shí)時抓取。想閱讀更多技術(shù)文章，請訪問 OneAPM 官方博客。