原文轉自:http://blog.csdn.net/yukon12345/article/details/11408617
webgrind是一個網頁版的性能分析工具,它的主要作用就是分析xdebug生成的cachegrind文件,以一種界面友好詳盡的方式來展示性能數據。試用了一下感覺還是很不錯的,鑑於網上並沒有一個系統介紹,特寫一篇文章:
webgrind官方定義翻譯版:https://github.com/jokkedk/webgrind
==================================================================================
是性能分析工具xdebug的php web版。它實現了 kcachegrind 的部分功能,但安裝簡便,適用所有平臺,性能優化。
另外它是 Google Summer of Code(Google編程之夏)2008的建議計劃之一。
特點:
- 跨平臺,簡便
- 可以記錄函數自身耗時self cost或者綜合耗時inclusive cost(指的是函數自身耗時+調用其他函數耗時)
- 可以查看php函數耗時以及用戶自定義函數耗時
- 可以查看任何函數在哪裏以及被哪個調用
- 通過gprof2dot.py 生成了種調用圖表 :https://github-camo.global.ssl.fastly.net/a264619233ac41fb21c34ff6bf728d3d0daab20c/687474703a2f2f77696b692e6a72666f6e736563612e676f6f676c65636f64652e636f6d2f6769742f6770726f6632646f745f736d616c6c2e706e67
安裝:
1.解壓,放入網站文件夾,然後進入相關路徑即可。比如http://localhost/webgrind.
2.xdebug是後臺程序,所以首先要安裝xdebug http://www.xdebug.org/docs/install
3在php.ini中做好設置:
只需要修改配置文件php.ini來啓用該庫,打開php.ini文件,並查找修改以下配置信息:
zend_extension = "c:\xampp\php\ext\php_xdebug.dll"
配置php_xdebug.dll的地址,去掉前面的;號
xdebug.default_enable = On
去掉;號,啓用該功能
xdebug.profiler_append = 0
分析結果文件是否重寫配置項,0爲不重寫,新的分析結果會追加到上一次結果分析之後 1爲重寫,生成新的結果文件,去掉;號
xdebug.profiler_enable = 0
性能分析配置項,如果值爲1,該功能自動生成結果分析文件,去掉;號
xdebug.profiler_enable_trigger = 1
需要觸發的性能分析配置項,值設爲1,需要在訪問地址後面加XDEBUG_PROFILE纔會生成結果文件
xdebug.profiler_output_dir = "tmp/xdebug"
結果文件生成路徑,默認是tmp文件夾,如果修改了配置,xdebug文件夾需要我們手動建立
配置信息修改完成,保存php.ini,然後重啓apache服務。
如果是通過wamp自帶安裝的那麼在php.ini中會有這些簡單的設置選項,如果是手工安裝那麼安裝好xdebug後只要在php.ini裏增加下面的2,3項即可。
[xdebug]
xdebug.remote_enable = off
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1
xdebug.profiler_output_name = cachegrind.out.%t.%p
xdebug.profiler_output_dir = "d:/wamp/tmp"
其中第1項是開啓遠程調試,這裏先不講,2,3項前面的譯文已經解釋。第4項是分析出的信息文件命名格式,%t代表時間,%p代表pid。
xdebug相關設置可以通過phpinfo() 開快查看。
使用:
設置好後就可以重啓wamp來看看效果:
我們使用XDEBUG_PROFILE作爲url的一個參數寫在某個頁面上後,轉入頁面,然後到xdebug.profiler_output_dir所定的路徑下,就會發現生成了一個cachegrind.out.開頭的文件,這就是webgrind需要分析的文件
進入webgrind主頁面:頁面很簡單,右上角有一排下拉列表
第一項參數參數其實我也糾結了一下,怎麼才容易想清楚和說明白:
webgrind把所有被調用函數/方法首先做一個排序,由高到低顯示。然後取出前N個,使他們耗時比率之和在90-100%之間。
要注意的是,最好不要選擇100%,這樣將會顯示所有被調用的函數/方法,如果是一個代碼複雜的頁面,那麼webgrind偶爾會被卡死。並且通常我們只要關注耗時前幾名的函數即可。
第二個就是選擇profile文件。默認是分析最新一次的xdebug記錄。如果之前設置好路徑和記錄機制那麼我們就會發現下拉列表裏有很多選項。
第三個選項是顯示百分比/毫秒/微秒。
下面的彩色進度條一樣的東東是耗時量比較條。藍代表php內置函數,灰色(這裏佔用很小看不出)代表requir/onclude,綠代表類方法,橙黃代表類其他過程函數 (用戶自定義函數)
結果查看
然後下面的分析列表的樣子:(選了毫秒作爲顯示單位)
對於其中一些參數,我在結合我的官網翻譯以及stackoverflow看到的解釋是這樣的:
Invocation Count
被調用執行的次數
Total Self Cost - 函數自身開銷耗時 毫秒/ 微秒 /百分比(並不包含調用其他函數)
Total Inclusive Cost - 綜合耗時。包括自身耗時和調用所有的其他函數的耗時
細節分析
我經過試驗,才明確瞭解了幾個數據的區別:
測試代碼:
- <?php
- //僅使用內置函數
- function t1(){
- time();
- }
- //自定義函數外再執行一次
- time();
- sleep(1);
- t1();
- //t2調用自定義函數
- function t2(){
- t1();
- }
- t2();
- //增加內置函數耗時
- function t3(){
- sleep(1);
- }
- t3();
- //t4增加調用自定義函數t3一次。
- function t4(){
- t3();
- sleep(1);
- }
- t4();
- //t5增加非調用函數式內耗 for循環10萬次,並調用t4
- function t5()
- { $u=0;
- for($i=0;$i<100000;$i++)
- { $u+=$i; }
- t4();
- }
- t5();
- ?>
因此我們可以得出最終結論:
- invocation count 表示的是整個php頁面從載入到執行完畢呈現,各種函數被調用的總次數(如sleep不管被哪個函數調用,總共頁面期執行了6次,t3被t4直接調用、t5間接調用一次,自身執行一次)
- total self cost 表示的是函數自身消耗(就如t5中10萬次循環消耗了31毫秒,sleep執行了2000毫秒,但自身消耗並不把其他任何函數調用算在其中)
- total inclusive cost 表示的是此函數從開始到執行完畢所用消耗 ,包括自身消耗和調用其他函數消耗
- Calls - 此函數中調用並執行的所有函數/方法名 次數 及耗時
- Total Call Cost - 被此父函數調用時,執行的總耗時 (the total time executing this function, when called from the parent function)
- Count - 被此父函數調用時,執行的次數。number of times the parent calls the child