如何使用 Xhprof 分析網站效能 (真實案例)

1. cyril.hcwang@gmail.com

2.  前言
 網站效能測試架構
 安裝測試環境
 分析
 建議事項
 結論

3.  儘管硬體能力不斷提昇，網站效能的重要
性卻日益增加。原因在於應用與使用量的
成長速度遠快於硬體的發展速度，所以僅
靠硬體的擴充將無法滿足業務擴充之所需。
另一方面，就算事前做了完整的效能規劃，
系統在實際的運作過程當中還是有可能遭
遇到不可預期的效能瓶頸。透過效能的分
析 (profiling)，可以讓我們了解網站在運作
時的真實狀況，進而發現問題並解決之。

4.  在這個投影片中，我將利用 xhprof 這個工
具來分析由 php 所撰寫的網站程式，以期
了解其效能上的瓶頸，並提出改進建議。
此網站為真實運作多年的服務，已擁有不
少忠實的使用者。

5.  原本由 facebook 所開發，已於 2009 年成
為開放源碼程式。
 支援 php 程式語言的運行環境。
 提供函式層級的相關資訊 (Wall時間、CPU
時間、記憶體使用量)。
 內建基本的 web ui 介面。
 為 PECL 下的一個模組。
 http://pecl.php.net/package/xhprof

6.  透過編譯模組的方式運行於 php 的執行環境。
 需要修改程式才能運作。
 可以透過 php 設定值 auto_prepend_file 自動執行相關
功能，進而避免修改所有程式。
 函數層級的資訊雖然很有用，但是由於太過低層，
所以與使用者的實際情境(如網頁完整的下載時間)
之間必須有所對應。
 僅提供一層的 traceback，對流程追蹤的能力有較
大的限制。
 可以將收集到的資訊用任何方式呈現，但內建的
web ui 僅提供檔案儲存方式的呈現。如要呈現其他
的儲存方式，必須另尋工具或自行開發。

7. 線上網站服務器群 分析專用網站服務器 (xhprof)
效能數據
數據收集/分析服務器
(xhgui/mongo DB)
NFS 服務器 資料庫服務器

8.  為了數據的精準性，理應收集線上網站服
務器的運行數據。但是因為原本就有持續
監測測試服務器的反應狀態，發現測試服
務器與線上服務器有類似的反應趨勢，所
以先以測試服務器當做收集目標(分析專用
網站服務器)。一方面避免干擾原有的服務，
另外一方面也可以讓收集的數據單純化以
利分析。

9.  我們將收集到的資料存放到監測主機的
mongo DB 之中，並利用 xhgui 這個 web
ui 加以分析。採用 mongo DB 除了可以支
援更多的資料筆數，未來各網站主機所收
集的資訊也可以統一集中管理與分析。
 分析專用網站服務器與數據收集/分析服務
器皆安裝 CentOS 6。

10.  安裝 EPEL
 下載合適的版本
http://mirror01.idc.hinet.net/EPEL/6/i386/repov
iew/epel-release.html
 安裝下載的 rpm

11.  安裝 php-pecl-xhprof 與 php-pecl-mongo
 yum install -y php-pecl-xhprof php-pecl-mongo

12.  安裝 git
 yum install -y git

13.  安裝 xhgui (以 /var/www/lib 為例)
 mkdir /var/www/lib
 cd /var/www/lib
 git clone https://github.com/preinheimer/xhgui

14.  修改 /var/www/lib/xhgui/web/config.php
 將 db.host 由 mongodb://localhost:27017 改為
mongodb://192.168.0.10:27017。(其中
192.168.0.10 請取代為數據收集/分析服務器的
IP 位址)。

15.  修改 Apache 設定
 …
ServerName www.myserver.tw
php_admin_value auto_prepend_file
/var/www/lib/xhgui/external/header.php
…
 上述設定可以加在虛擬主機或是全域設定。
 重新啟動 Apache
 service httpd restart

16.  安裝 EPEL
 下載合適的版本
http://mirror01.idc.hinet.net/EPEL/6/i386/repov
iew/epel-release.html
 安裝下載的 rpm

17.  安裝 mongo DB
 yum install mongodb-server
 將 /etc/mongo.conf 內的 bind_ip 由 127.0.0.1
改成 127.0.0.1, 192.168.0.10 (其中
192.168.0.10 請取代為數據收集/分析服務器
的 IP 位址)。
 修改 iptables 的設定，允許分析專用網站服務
器連結至 TCP 埠號 27017。
 重新啟動 iptables 與 mongodb 服務。
 service iptables restart
 service mongod restart

18.  安裝 php-devel
 yum install -y php-devel

19.  安裝 PHP 專用的 mongo DB 函式
 pecl install mongo
 請勿安裝 php-pecl-mongo，否則將會因版
本過舊而造成 xhgui 的執行錯誤。

20.  安裝 git
 yum install -y git

21.  安裝 xhgui (以 /var/www/lib 為例)
 mkdir /var/www/lib
 cd /var/www/lib
 git clone https://github.com/preinheimer/xhgui

22.  修改 Apache 的設定
 Alias /xhgui /var/www/lib/xhgui/web/webroot
<Directory /var/www/lib/xhgui/web/webroot>
Order Deny,Allow
Deny from All
Allow from 127.0.0.1
Allow from ::1
</IfModule>
</Directory>
 上述範例僅提供本機 (127.0.0.1) 連結 xhgui，請根
據實際情況加上合適的 IP 位址。
 重新啟動 Apache
 service httpd restart

23.  我們選定分析專用網站服務器上的一個特
定網頁，使用瀏覽器對其進行存取。因為
這是測試專用的服務器，所以利用瀏覽器
外掛的方式，每分鐘自動重新載入一次以
便觀察數據的變化。
 連結至 http://192.168.0.10/xhgui (其中
192.168.0.1 請取代為數據收集/分析服務
器的 IP 位址)。

25.  mongo DB 與 xhgui 預設都沒有密碼保護
的機制，請注意小心設定防火牆與 Apache
服務器的相關設定，以避免非授權的使用。

27.  測試採用每分鐘重新載入一次的方式，除此之
外應該沒有其他的存取行為。我們看到
/api/project/barcode/?pid=b6471082aaa&h=1
03&revision=1&w=412 這個 URL 每分鐘皆連
續出現兩次，表示在每次存取這個特定的網頁
時都會載入上述的 URL 兩次。
 上述行為雖然不會產生錯誤，但是會對網站產
生不必要的負載，並影響使用者的使用順暢度。
 這種行為在複雜的網頁中，可能因為不同功能
模組之間的不協調而造成。

29.  進一步分析此 URL 執行數據發現
session_start 占用的 wall 時間比例相當高。
 網站 Session 架構在 NFS 上，而 NFS 對
於大量檔案的讀寫容易產生效能的瓶頸。
 即使是在網站流量較低的時候，
session_start 佔用比例與數值仍相當高。

30.  session_start 占用高比例 wall 時間的現象
幾乎存在於全部的 URL。即使是有些應該
不會使用到 session data 的 URL 也會呼叫
session_start，並占用過多 wall 時間。

32.  此網頁載入過多資源，累加的延遲時間將
可能嚴重影響使用者操作的順暢度。

33. 1. 改用其他機制 (如 redis) 取代 NFS 作為
session data 的儲存機制。
2. 檢測程式以避免不必要的 URL 呼叫。
3. 關閉 session auto start 的功能，只有必須使
用 session data 的程式才啟用 session。
4. 減少非必要資源的載入，或將資源整合以減
少連結的次數。如可以將多張小圖合成一張
大圖(可利用js進行切割)，或是將網頁區塊整
合，甚至是利用 client 端的快取。

34.  前面四項建議，除了第一項之外都必須修改程
式，所以在此我僅對第一項建議做出後續的測
試。
 後續測試將 Session data 改用本機硬碟與
redis 的方式分別加以進行。
 本機硬碟因為不具備分享功能，所以僅做為比較之
後。
 redis 類似 memcache，為一種記憶體快取機制。
與 memcache 比較，redis 支援 master/slave 架構，
而且可以將內容儲存在檔案之中，以避免重新啟動
資料遺失的問題。除此之外，redis 支援自動移除
過期資料的功能，可以減少後續維護的負擔。

36.  雖然比例有下降的現象，但是比例仍高。
因為分析專用網站服務器的硬碟效能本就
不高，所以此一數據並不意外。
 session_start 的 wall 時間並沒有很明顯的
下降，考慮到流量增加後的狀況，顯見不
是一個很好的解決方案。

38.  在數據上已經完全看不到 session_start 佔
用的 wall 時間。
 為了確認結果，我們再找其他比較"單純"的
URL 做比較。

41.  從前面另一個例子，我們可以看到
session_start 的 wall 時間從 156,166us 降為
1,284us，下降的比例相當明顯。
 因為我們目前只有將分析專用網站服務器的
Session 資料改至 redis，所以對 redis 的負載
較小。如果全面導入後，應該持續監測相關數
據，以確保施作達到預期效益。
 Redis 會自動清除逾期的 Session data，與使
用檔案時的行為不同。雖然前者才是正確的行
為，但是仍有可能因為之前程式錯誤的引用
Session data 而造成資料無法取得的現象。

42.  因為此一改進僅分別針對單一 URL，對於
一整個網頁的完整下載時間仍受到其他因
素影響 (如前面提到的現象四)，所以仍須
用其他方法持續改進使用者的感受。

43.  當運用 xhprof 在線上環境時，為了避免產
生過多的數據而影響網站運行，可以採用
取樣的方式。舉例來說，可以每一千個請
求才記錄一次(隨機)。
 採樣的頻率除了必須依據網站流量進行適
當的調整外，對於不同的應用時機也必須
隨之改變。例如當日常收集時可以採用較
低的比例，但是如果要追蹤特定的問題時，
就可以暫時提高取樣的頻率，以便"近距離"
觀察。

44.  Session data 對於現今強調互動與個人化的網
站來說是很重要的一環，但是如果沒有做好良
好的使用準則與儲存規劃，不但可能造成對效
能的負面影響，在網站擴充時更是往往造成莫
大的限制。
 透過實際觀察線上環境的效能數據，可以讓我
們發現一些因規劃疏忽或網站成長所造成的效
能瓶頸。
 解決效能問題是一連串不斷的改進，解決了一
個，還有下一個更困難的正在等著呢。

45. 歡迎指教
cyril.hcwang@gmail.com