PHP 開發(fā)中的外圍資源性能分析（一）

anquan 發(fā)布于2019-06-27 11:35 / 2813人閱讀

摘要：而是說，程序的外部資源，往往是影響性能的重要因素，尤其是當(dāng)外部資源的連接和數(shù)據(jù)獲取本身速度達(dá)不到理想的結(jié)果時(shí)。

暫且不討論「PHP 是不是最好的編程語(yǔ)言」，本文我們將分別分析一下在 PHP 程序的后端外圍資源和前端外圍資源，它們對(duì)整個(gè) PHP Web 應(yīng)用體驗(yàn)的影響，這往往比語(yǔ)言本身大得多。

首先，后端外圍資源，是指跟 PHP 運(yùn)行過程中與語(yǔ)言本身無關(guān)的網(wǎng)絡(luò)與 IO 操作、存儲(chǔ)服務(wù)、中間件代理、緩存和數(shù)據(jù)庫(kù)訪問等，在本文中，我們先分析 IO 操作和中間件服務(wù)。

為什么外圍資源的性能分析，要以以上三者分析為主？我們可以看如下國(guó)內(nèi)專業(yè)的性能監(jiān)控工具 OneAPM 的 PHP Web 應(yīng)用后臺(tái)截取下來的總覽圖，通過這個(gè)圖可以看到，數(shù)據(jù)庫(kù)所花費(fèi)的時(shí)間在總 PHP 響應(yīng)時(shí)間中，占據(jù)著 60% 甚至更大的比重，而 Memcached 緩存服務(wù)，在這張圖里所占的響應(yīng)時(shí)間，幾乎看不見。

下面正式開始。

一、IO 操作

PHP 語(yǔ)言本身盡管有性能的差異，但是從對(duì) PHP 的性能微觀分析也可以看出，如果只執(zhí)行單次操作，實(shí)際中這種差別是非常小的，前面的實(shí)驗(yàn)中，十萬次以上操作，才有百 ms 級(jí)的差別，因?yàn)?PHP 語(yǔ)言本身操作的是內(nèi)存，一次內(nèi)存訪問，大約在 50ns 左右。而 IO 操作，則是磁盤訪問，一次磁盤訪問所費(fèi)時(shí)間在 5ms 以上。僅從這個(gè)數(shù)量級(jí)看是 10 萬倍的差距，實(shí)際上，根據(jù)實(shí)驗(yàn)，也有百倍級(jí)的差距（順序訪問和隨機(jī)訪問差距巨大，實(shí)際中兩者同時(shí)進(jìn)行，還會(huì)有磁盤緩存等）。

所以對(duì)比語(yǔ)言本身，IO 成為瓶頸的可能性更大。首先看一下，IO 操作帶來的性能差別。

一個(gè) PHP 腳本，通過 PHP 命令方式運(yùn)行，正常時(shí)，消耗時(shí)間如下：

當(dāng)使用如下命令清空磁盤緩存后：

 echo 3 | sudo tee /proc/sys/vm/drop_caches

得到的第一次運(yùn)行時(shí)間下如下圖所示：

代碼一模一樣，但是運(yùn)行時(shí)間卻是正常運(yùn)行時(shí)間的 6 倍。當(dāng)然這個(gè)時(shí)間的慢，并不僅僅是由于程序本身的 IO 操作導(dǎo)致，而更大的慢的因素是在 CGI 模式下，PHP 腳本的每一次運(yùn)行都需要加載所有模塊，這個(gè)加載，也伴隨著大量的 IO 操作。

再做一個(gè)實(shí)驗(yàn)，完全同樣功能的兩個(gè)頁(yè)面，一個(gè)采用了 MVC 的方式，把頭部，尾部拆開成獨(dú)立的模板（并未使用模板引擎），中間邏輯也使用獨(dú)立的 Model 類來處理。另一個(gè)只 require 了宏定義和數(shù)據(jù)庫(kù)操作兩個(gè)文件。

使用命令ab -c 40 -n 1000 http://xxxxx/0929/zuche/carlist.php
進(jìn)行壓力測(cè)試, 這兩個(gè)頁(yè)面運(yùn)行穩(wěn)定后壓測(cè)結(jié)果數(shù)據(jù)如圖所示。

在這個(gè)頁(yè)面中，MVC 版本所費(fèi)時(shí)間要多 6-8ms 左右。雖然只是多增加了幾個(gè)文件包含，但是明顯增加了請(qǐng)求延時(shí)，如果文件操作本身更加復(fù)雜，比如文件上傳、檢測(cè)、轉(zhuǎn)換，則延時(shí)會(huì)增加一個(gè)數(shù)量級(jí)以上。在實(shí)際的生產(chǎn)使用中，也不是說有了文件操作，就一定會(huì)產(chǎn)生大的延時(shí)，因?yàn)榫拖癖纠?require 而言，由于磁盤緩存等的存在，延時(shí)的影響已降低很多。

二、中間件代理

在正式使用中間件之前，我們先對(duì)比一下，使用數(shù)據(jù)庫(kù)與不使用數(shù)據(jù)庫(kù)的差別，同樣是上面的這個(gè)例子，我們把數(shù)據(jù)結(jié)果集，從數(shù)據(jù)庫(kù)獲取轉(zhuǎn)換成為直接的結(jié)果數(shù)組設(shè)置，為了結(jié)構(gòu)化清楚，采用 MVC 這一版。同時(shí)為了更顯著對(duì)比上一輪測(cè)試結(jié)果，同時(shí)也消除語(yǔ)言本身的一些慢的因素，在本輪實(shí)驗(yàn)中，我們采用 PHP7，得到結(jié)果是令人吃驚的。
如下圖是帶有數(shù)據(jù)庫(kù)連接和數(shù)據(jù)讀取的版本，PHP 擴(kuò)展使用的是 mysqli。

由于本頁(yè)面，只有一次數(shù)據(jù)庫(kù)操作，頁(yè)面結(jié)構(gòu)也比較簡(jiǎn)單，語(yǔ)言本身的影響因素非常大，PHP7 下速度有兩倍以上提升，原來平均響應(yīng)時(shí)長(zhǎng)為 37-40ms，現(xiàn)在則為 14ms。

即使如此，不讀取數(shù)據(jù)庫(kù)時(shí)，有 4ms 的差距，盡管數(shù)目上不大，但是對(duì)于一個(gè)總響應(yīng)時(shí)長(zhǎng)只有 14ms 的應(yīng)用，這 4ms 已經(jīng)很顯著了，而這只是一個(gè)數(shù)據(jù)庫(kù)查詢操作。

接下來看一下，當(dāng)增加一層數(shù)據(jù)庫(kù)中間件時(shí)，效率又有怎么樣的變化呢？由于筆者所使用的中間件，目前并不支持 PHP7，所以我們還在老版 PHP 的基礎(chǔ)上來比對(duì)。在同樣的服務(wù)器壓力下，使用了中間件的版本慢了一倍以上。如下圖所示。

從這個(gè)例子可以看出來，原本 PHP 直接連數(shù)據(jù)庫(kù)，取得數(shù)據(jù)的操作，增加了中間件之后，變了先到中間件，中間件再到數(shù)據(jù)庫(kù)，返回亦如是，導(dǎo)致了速度的大幅度下降（這里已經(jīng)剔除了中間件本身占用資源的因素，在原來直連的版本是 37-40ms 左右）。

這里也請(qǐng)讀者不要誤解，演示中間件使用速度下降的例子，并不是說為了說明中間件不好，在分布式環(huán)境下，使用中間件是非常必要的。而是說，程序的外部資源，往往是影響性能的重要因素，尤其是當(dāng)外部資源的連接和數(shù)據(jù)獲取本身速度達(dá)不到理想的結(jié)果時(shí)。

對(duì)于 IO 操作和中間件服務(wù)的分析就到這里，下篇將分析數(shù)據(jù)庫(kù)給整個(gè)應(yīng)用性能帶來的影響。

OneAPM for PHP 能夠深入到所有 PHP 應(yīng)用內(nèi)部完成應(yīng)用性能管理和監(jiān)控，包括代碼級(jí)別性能問題的可見性、性能瓶頸的快速識(shí)別與追溯、真實(shí)用戶體驗(yàn)監(jiān)控、服務(wù)器監(jiān)控和端到端的應(yīng)用性能管理。