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

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

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

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

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

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 中，兩個整數相加，我們能得到整數值，一個整數和一個字符串相加，甚至兩個字符串相加，都變成整數相加。而字符串和任何類型連接操作都成了字符串。

運行結果如下：
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 擴展，在擴展中實現了 get_prime_numbers 函數，輸入一個整數，返回小于該整數的素數。得到的結果如下，這個效率的提升是非常驚人的，在 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; jf)
                {
                    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 優化準則。敬請期待！
本文系 OneAPM 工程師編譯整理。想閱讀更多技術文章，請訪問 OneAPM 官方博客。