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

cyril.hcwang@gmail.com

Agent

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

前言

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

故事開始

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

xhprof 簡介

原本由 facebook 所開發，已於 2009 年成為開放源碼程式。

支援 php 程式語言的運行環境。 提供函式層級的相關資訊 (Wall 時

間、 CPU 時間、記憶體使用量 ) 。 內建基本的 web ui 介面。 為 PECL 下的一個模組。

http://pecl.php.net/package/xhprof

xhprof 的特性

透過編譯模組的方式運行於 php 的執行環境。 需要修改程式才能運作。

可以透過 php 設定值 auto_prepend_file 自動執行相關功能，進而避免修改所有程式。

函數層級的資訊雖然很有用，但是由於太過低層，所以與使用者的實際情境 (如網頁完整的下載時間 )之間必須有所對應。

僅提供一層的 traceback，對流程追蹤的能力有較大的限制。

可以將收集到的資訊用任何方式呈現，但內建的 web ui 僅提供檔案儲存方式的呈現。如要呈現其他的儲存方式，必須另尋工具或自行開發。

測試架構線上網站服務器群

NFS 服務器

分析專用網站服務器 (xhprof)

資料庫服務器

數據收集 / 分析服務器 (xhgui/mongo DB)

效能數據

測試環境說明

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

測試環境說明 ( 續 )

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

分析專用網站服務器與數據收集 / 分析服務器皆安裝 CentOS 6 。

分析專用網站服務器 (1)

安裝 EPEL 下載合適的版本 http://mirror01.idc.hinet.net/EPEL/6/i386/repoview/epel-release.html

安裝下載的 rpm

分析專用網站服務器 (2)

安裝 php-pecl-xhprof 與 php-pecl-mongo yum install -y php-pecl-xhprof php-pecl-mongo

分析專用網站服務器 (3)

安裝 git yum install -y git

分析專用網站服務器 (4)

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

分析專用網站服務器 (5)

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

分析專用網站服務器 (6)

修改 Apache 設定 …ServerName www.myserver.twphp_admin_value auto_prepend_file /var/www/lib/xhgui/external/header.php…

上述設定可以加在虛擬主機或是全域設定。 重新啟動 Apache

service httpd restart

數據收集 / 分析服務器 (1)

安裝 EPEL 下載合適的版本http://mirror01.idc.hinet.net/EPEL/6/i386/repoview/epel-release.html

安裝下載的 rpm

數據收集 / 分析服務器 (2)

安裝 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

數據收集 / 分析服務器 (3)

安裝 php-devel yum install -y php-devel

數據收集 / 分析服務器 (4)

安裝 PHP 專用的 mongo DB 函式 pecl install mongo

請勿安裝 php-pecl-mongo ，否則將會因版本過舊而造成 xhgui 的執行錯誤。

數據收集 / 分析服務器 (5)

安裝 git yum install -y git

數據收集 / 分析服務器 (6)

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

數據收集 / 分析服務器 (7)

修改 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

開始測試

我們選定分析專用網站服務器上的一個特定網頁，使用瀏覽器對其進行存取。因為這是測試專用的服務器，所以利用瀏覽器外掛的方式，每分鐘自動重新載入一次以便觀察數據的變化。

連結至 http://192.168.0.10/xhgui ( 其中 192.168.0.1 請取代為數據收集/ 分析服務器的 IP 位址 ) 。

xhgui

注意事項

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

現象一

現象一 ( 續 )

測試採用每分鐘重新載入一次的方式，除此之外應該沒有其他的存取行為。我們看到 /api/project/barcode/?pid=b6471082aaa&h=103&revision=1&w=412 這個 URL 每分鐘皆連續出現兩次，表示在每次存取這個特定的網頁時都會載入上述的 URL 兩次。

上述行為雖然不會產生錯誤，但是會對網站產生不必要的負載，並影響使用者的使用順暢度。

這種行為在複雜的網頁中，可能因為不同功能模組之間的不協調而造成。

現象二

現象二 ( 續 )

進一步分析此 URL 執行數據發現 session_start 占用的 wall 時間比例相當高。

網站 Session 架構在 NFS 上，而 NFS 對於大量檔案的讀寫容易產生效能的瓶頸。

即使是在網站流量較低的時候， session_start 佔用比例與數值仍相當高。

現象三

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

現象四

現象四 ( 續 )

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

建議事項

1. 改用其他機制 ( 如 redis) 取代 NFS 作為 session data 的儲存機制。

2. 檢測程式以避免不必要的 URL 呼叫。3. 關閉 session auto start 的功能，只

有必須使用 session data 的程式才啟用 session 。

4. 減少非必要資源的載入，或將資源整合以減少連結的次數。如可以將多張小圖合成一張大圖 ( 可利用 js 進行切割 ) ，或是將網頁區塊整合，甚至是利用 client 端的快取。

Session Storage Revised

前面四項建議，除了第一項之外都必須修改程式，所以在此我僅對第一項建議做出後續的測試。

後續測試將 Session data 改用本機硬碟與 redis 的方式分別加以進行。 本機硬碟因為不具備分享功能，所以僅做為比較之後。 redis 類似 memcache ，為一種記憶體快取機制。

與 memcache 比較， redis 支援 master/slave 架構，而且可以將內容儲存在檔案之中，以避免重新啟動資料遺失的問題。除此之外，redis 支援自動移除過期資料的功能，可以減少後續維護的負擔。

Session 在本機硬碟

Session 在本機硬碟 ( 續 )

雖然比例有下降的現象，但是比例仍高。因為分析專用網站服務器的硬碟效能本就不高，所以此一數據並不意外。

session_start 的 wall 時間並沒有很明顯的下降，考慮到流量增加後的狀況，顯見不是一個很好的解決方案。

Session on Redis

Session on Redis ( 續 )

在數據上已經完全看不到 session_start 佔用的 wall 時間。

為了確認結果，我們再找其他比較 " 單純 " 的 URL 做比較。

Session on NFS, Again

Session on Redis, Again

從前面另一個例子，我們可以看到 session_start 的 wall 時間從 156,166us 降為 1,284us，下降的比例相當明顯。

因為我們目前只有將分析專用網站服務器的 Session 資料改至 redis，所以對 redis 的負載較小。如果全面導入後，應該持續監測相關數據，以確保施作達到預期效益。

Redis 會自動清除逾期的 Session data，與使用檔案時的行為不同。雖然前者才是正確的行為，但是仍有可能因為之前程式錯誤的引用 Session data 而造成資料無法取得的現象。

尚未結束

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

Final Thoughts

當運用 xhprof 在線上環境時，為了避免產生過多的數據而影響網站運行，可以採用取樣的方式。舉例來說，可以每一千個請求才記錄一次 (隨機 ) 。

採樣的頻率除了必須依據網站流量進行適當的調整外，對於不同的應用時機也必須隨之改變。例如當日常收集時可以採用較低的比例，但是如果要追蹤特定的問題時，就可以暫時提高取樣的頻率，以便 "近距離 "觀察。

結論

Session data 對於現今強調互動與個人化的網站來說是很重要的一環，但是如果沒有做好良好的使用準則與儲存規劃，不但可能造成對效能的負面影響，在網站擴充時更是往往造成莫大的限制。

透過實際觀察線上環境的效能數據，可以讓我們發現一些因規劃疏忽或網站成長所造成的效能瓶頸。

解決效能問題是一連串不斷的改進，解決了一個，還有下一個更困難的正在等著呢。

歡迎指教cyril.hcwang@gmail.c

om