xDebug + webgrind 對 php 程序進行性能分析

環境

macOs Sierra

php 7.0.8

MAMP Pro 集成環境

---

背景

最近有一個須要在微信朋友圈上線的 h5，本人作了一個抽獎的接口，也沒多想，直接上 php ci（CodeIgniter）框架。

按照騰訊方的要求，須要 ab 測試，在總請求數 15000，併發 500 下平均響應時間小於 200ms。

誰知道等開發完畢，ab 跑完，響應時間直飈近 400ms。

因此接下來藉助 php 強大的 xDebug 擴展和 webgrind 來查看代碼調用耗時狀況。

---

一、添加 php 的 xDebug 擴展

由於 MAMP Pro 自帶 xDebug 擴展，因此直接開啓就好：

二、php.ini 配置中開啓 Profiler（性能跟蹤器）

Profiler工做方式相似於函數追蹤，是在腳本程序運行時自動將性能記錄文件保存下來。

[php.ini]

xdebug.profiler_enable = 1

xdebug.profiler_enable_trigger = 1

三、下載 webgrind

由於 xDebug 的 Profiler 生成的性能記錄文件的格式，不是給人看的：

因此須要下載圖形界面的分析工具，Linux KDE 能夠用 KChaceGrind，windows 下能夠用 winChaceGrind ，Mac 上沒有發現合適的桌面端軟件，因此用 Web 版的 webgrind 是最好的選擇。

Github 地址：https://github.com/jokkedk/webgrind

下載後直接放在本地服務器根目錄直接訪問就行：

http://localhost/webgrind

四、使用方法

把須要分析的 url 後面接上 ?XDEBUG_PROFILE，例如：

http://localhost/XXX/index.php/PriceApply/getPrice?XDEBUG_PROFILE

而後刷新 webgrind 網頁，新的數據會出現：

下面介紹下 webgrind 的一些參數含義：

第一個選項：webgrind 把全部被調用函數/方法首先作一個排序，由高到低顯示。而後取出前 N 個，使他們耗時比率之和在 90-100% 之間。

要注意的是，最好不要選擇100%，這樣將會顯示全部被調用的函數/方法，若是是一個代碼複雜的頁面，那麼webgrind偶爾會被卡死。而且一般咱們只要關注耗時前幾 > 名的函數便可。

第二個選項：選擇 profile 文件。默認是分析最新一次的 xdebug 記錄。若是以前設置好路徑和記錄機制那麼咱們就會發現下拉列表裏有不少選項。

第三個選項：顯示百分比/毫秒/微秒。

彩色進度條：藍表明 php 內置函數，灰表明 require/include，綠表明類方法，橙黃表明過程函數 (用戶自定義函數)

invocation count - 表示整個 php 頁面從載入到執行完畢呈現，各類函數被調用的總次數
total self cost - 表示函數自身消耗
total inclusive cost - 表示此函數從開始到執行完畢所用消耗 ，包括自身消耗和調用其餘函數消耗

點擊一個父函數名後出現展開：

Calls - 此函數中調用並執行的全部函數/方法名、次數及耗時
Total Call Cost - 被此父函數調用時，執行的總耗時
Count - 被此父函數調用時，執行的次數

五、分析數據

如上圖，最耗時的並非我認爲的抽獎模塊，而是 ci 框架自己 + 數據庫

讓我再進一步瞧瞧：

如上圖，在 load_class 項目裏，最耗時的涉及 ci 框架重要模塊的加載，包括URL、Hooks、Config、Router、Output模塊，這些都是 ci 框架易用性的保障，除了Hooks 能夠在 config 文件裏禁用，絕大多數應該不能關閉。

再來看 DB 項，最耗時的是數據庫的初始化

最後一項，是 ci 的系統核心層，最耗時的是 model 的構造過程，還是初始化

---

結論

借用《主流 PHP 框架性能評測》（https://gold.xitu.io/entry/578ef4d6d342d30058e17d98） 文中的數據分析圖（柱狀圖越高性能越好）

框架有利有弊，利是方便開發，易用穩定，弊端可能就是無論你的實際需求，初始化加載不少用不到的功能。

因此：

在涉及微小型的接口開發，建議採用原生 php 。

在涉及複雜型接口時，採用框架的同時，適當開啓 php 緩存，好比 APC 和 OPcache，均可以讓性能獲得一些提高，彌補使用框架的不足。