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

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

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

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

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

當(dāng)下主流 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 大致相當(dāng)?shù)慕Y(jié)果。每秒處理請求 291 個，每請求耗時 68.5ms。

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

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

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

第二個是 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)整代碼如下：

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

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

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

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

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

其次，我們將這個求素數(shù)個數(shù)的過程，編寫成了 PHP 擴展，在擴展中實現(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

{

if(i%numbers[j]==0)

{

flag = false;

break;

}

if(numbers[j]>f)

{

break;

}

}

if(flag)

{

numbers[num] = i;

num++;

}

}

free(numbers);

RETURN_LONG(num);

}

第三個性能優(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。
][15]
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 模式中，在每一次腳本運行都需要加載所有的模塊。而在程序運行完成了之后，也要釋放模塊資源。如下圖所示：
][19]
而在 FastCGI 和 mod_php 模式中，則不需要如此。只有 php-fpm 或者 Apache 啟動的時候，需要加載一次所有的模塊，在具體的某次運行過程中，并不需要再次加載和釋放相關(guān)的模塊資源。

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