摘要：本文就改變性能分析的角度，并通過實例來分析出的性能方面需要注意和改進的點。如下是作為解釋性語言的執(zhí)行過程。這里分別啟用和做實驗。

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

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

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

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

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

當下主流 PHP 版本本身語言引擎性能

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

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

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

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

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

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

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

這里分別啟用 APC 和 Zend OPCache 做實驗。啟用 APC 的版本。

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

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

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

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

可以看到每一行代碼被編譯成相應(yīng)的 OpCode 的輸出。
二、PHP 作為動態(tài)類型語言的性能分析與改進

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

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

運行結(jié)果如下：

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

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

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

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

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

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

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

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

其次，我們將這個求素數(shù)個數(shù)的過程，編寫成了 PHP 擴展，在擴展中實現(xiàn)了 get_prime_numbers 函數(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; jf)
            {
                break;
            }
        }
        if(flag)
        { 
            numbers[num] = i;
            num++;
        }
    }
    free(numbers);
    RETURN_LONG(num);

}

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

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

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

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

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

PHP5.6 反而有些退步。

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

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

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

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

這樣程序性能的效率得到了提升。