PHP 效能分析與實驗：效能的巨集觀分析

【編者按】此前，閱讀過了很多關於 PHP 效能分析的文章，不過寫的都是一條一條的規則，而且，這些規則並沒有上下文，也沒有明確的實驗來體現出這些規則的優勢，同時討論的也側重於一些語法要點。本文就改變 PHP 效能分析的角度，並通過例項來分析出 PHP 的效能方面需要注意和改進的點。

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

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

1. PHP 作為解釋性語言效能有其天然的缺陷
2. PHP 作為動態型別語言在效能上也有提升的空間
3. 當下主流 PHP 版本本身語言引擎效能

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

PHP 作為一門指令碼語言，也是解釋性語言，是其天然效能受限的原因，因為同編譯型語言在執行之前編譯成二進位制程式碼不同，解釋性語言在每一次執行都面對原始指令碼的輸入、解析、編譯，然後執行。如下是 PHP 作為解釋性語言的執行過程。

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

那優化的點在哪裡呢？可以想見，只要程式碼檔案確定，解析到編譯這一步都是確定的，因為檔案已不再變化，而執行，則由於輸入引數的不同而不同。在效能優化的世界裡，至上絕招就是在獲得同樣結果的情況下，減少操作，這就是大名鼎鼎的快取。快取無處不在，快取也是效能優化的殺手鐗。於是乎 OpCode 快取這一招就出現了，只有第一次需要解析和編譯，而在後面的執行中，直接由指令碼到 Opcode，從而實現了效能提速。執行流程如下圖所示：

相對每一次解析、編譯，讀到指令碼之後，直接從快取讀取位元組碼的效率會有大幅度的提升，提升幅度到底有多大呢？

我們來做一個沒有 Opcode 快取的實驗。20 個併發，總共 10000 次請求沒有經過 opcode 快取的請求，，得到如下結果：

其次，我們在伺服器上開啟 Opcode 快取。要想實現 opcode 快取，只需要安裝 APC、Zend OPCache、eAccelerator 擴充套件即可，即使安裝了多個，也只啟用其中一個。注意的是，修改了 php.ini 配置之後，需要重新載入 php-fpm 的配置。

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

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

在啟用了 Zend Opcache 的版本中，得到同 APC 大致相當的結果。每秒處理請求 291 個，每請求耗時 68.5ms。

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

這裡附加補充一下，OpCode 到底是什麼東東，OpCode 編譯之後的位元組碼，我們可以使用bytekit 這樣的工具，或者使用 vld PHP 擴充套件來實現對 PHP 的程式碼編譯。如下是 vld 外掛解析程式碼的執行結果。

可以看到每一行程式碼被編譯成相應的 OpCode 的輸出。

二、PHP 作為動態型別語言的效能分析與改進

第二個是 PHP 語言是動態型別的語言，動態型別的語言本身由於涉及到在記憶體中的型別推斷，比如在 PHP 中，兩個整數相加，我們能得到整數值，一個整數和一個字串相加，甚至兩個字串相加，都變成整數相加。而字串和任何型別連線操作都成了字串。

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

執行結果如下：

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

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

這是一段 Swift 程式碼，字典只有 14 個鍵值對，這段程式碼的編譯，9 分鐘了還沒有編譯完成（5G 記憶體，2.4GHz CPU），編譯環境為 Swift 1.2，Xcode 6.4。

但是如果調整程式碼如下：

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

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

那麼作為動態型別的 PHP 的效率如何提升呢？從 PHP 語言本身這個層面是沒有辦法解決的，因為你怎麼寫也是動態型別的程式碼。解決辦法就是將PHP轉化為靜態型別的表示，也就是做成擴充套件，可以看到，鳥哥的很多專案，比如 Yaf 框架，都是做成了擴充套件的，當然這也是由於鳥哥是 C 高手。擴充套件由於是 C 或者 C++ 而寫，所以不再是動態型別，又加之是編譯好的，而 C 語言本身的效率也會提升很多。所以效率會大幅度提高。

下面我們來看一段程式碼，這段程式碼，只是實現了簡單的素數運算，能計算指定值以內的素數個數，用的是普通的篩選法。現在看看擴充套件實現，跟 PHP 原生實現的效率差別，這個差別當然，不僅僅是動態型別和編譯型別的差別，還有語言效率的差別。

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

其次，我們將這個求素數個數的過程，編寫成了 PHP 擴充套件，在擴充套件中實現了 getprimenumbers 函式，輸入一個整數，返回小於該整數的素數。得到的結果如下，這個效率的提升是非常驚人的，在 1.4s 上下即返回。速度提升 20 倍以上。

可以想見，靜態和編譯型別的語言，其效率得到了驚人的提升。本程式的 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);
}

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

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

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

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

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

PHP5.6 反而有些退步。

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

以上是求素數指令碼在各個 PHP 版本之間的執行速度區別，儘管只測試了這一個程式，也不是特別的嚴謹，但是這是在同一臺機器上，而且編譯 configure 引數也基本一樣，還是有一定可比性的。

在巨集觀層面，除了上面的這些之外，在實際的部署過程中，對 PHP 效能的優化，還體現為要減少在執行中所消耗的資源。所以 FastCGI 模式和 mod_php 的模式比傳統的 CGI 模式也更為受歡迎。因為在傳統的 CGI 模式中，在每一次指令碼執行都需要載入所有的模組。而在程式執行完成了之後，也要釋放模組資源。如下圖所示：

而在 FastCGI 和 mod_php 模式中，則不需要如此。只有 php-fpm 或者 Apache 啟動的時候，需要載入一次所有的模組，在具體的某次執行過程中，並不需要再次載入和釋放相關的模組資源。

這樣程式效能的效率得到了提升。以上就是有關 PHP 巨集觀層面的效能優化的分析，在本文的第二部分我們將探討應用方面的 PHP 優化準則。敬請期待！