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

1,395 views

Published on

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

Published in: Technology
1 Comment
2 Likes
Statistics
Notes
  • 真實案例? 在哪??
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
1,395
On SlideShare
0
From Embeds
0
Number of Embeds
43
Actions
Shares
0
Downloads
15
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

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

  1. 1. cyril.hcwang@gmail.com
  2. 2.  前言 網站效能測試架構 安裝測試環境 分析 建議事項 結論
  3. 3.  儘管硬體能力不斷提昇,網站效能的重要 性卻日益增加。原因在於應用與使用量的 成長速度遠快於硬體的發展速度,所以僅 靠硬體的擴充將無法滿足業務擴充之所需。 另一方面,就算事前做了完整的效能規劃, 系統在實際的運作過程當中還是有可能遭 遇到不可預期的效能瓶頸。透過效能的分 析 (profiling),可以讓我們了解網站在運作 時的真實狀況,進而發現問題並解決之。
  4. 4.  在這個投影片中,我將利用 xhprof 這個工 具來分析由 php 所撰寫的網站程式,以期 了解其效能上的瓶頸,並提出改進建議。 此網站為真實運作多年的服務,已擁有不 少忠實的使用者。
  5. 5.  原本由 facebook 所開發,已於 2009 年成 為開放源碼程式。 支援 php 程式語言的運行環境。 提供函式層級的相關資訊 (Wall時間、CPU 時間、記憶體使用量)。 內建基本的 web ui 介面。 為 PECL 下的一個模組。  http://pecl.php.net/package/xhprof
  6. 6.  透過編譯模組的方式運行於 php 的執行環境。 需要修改程式才能運作。  可以透過 php 設定值 auto_prepend_file 自動執行相關 功能,進而避免修改所有程式。 函數層級的資訊雖然很有用,但是由於太過低層, 所以與使用者的實際情境(如網頁完整的下載時間) 之間必須有所對應。 僅提供一層的 traceback,對流程追蹤的能力有較 大的限制。 可以將收集到的資訊用任何方式呈現,但內建的 web ui 僅提供檔案儲存方式的呈現。如要呈現其他 的儲存方式,必須另尋工具或自行開發。
  7. 7. 線上網站服務器群 分析專用網站服務器 (xhprof) 效能數據 數據收集/分析服務器 (xhgui/mongo DB)NFS 服務器 資料庫服務器
  8. 8.  為了數據的精準性,理應收集線上網站服 務器的運行數據。但是因為原本就有持續 監測測試服務器的反應狀態,發現測試服 務器與線上服務器有類似的反應趨勢,所 以先以測試服務器當做收集目標(分析專用 網站服務器)。一方面避免干擾原有的服務, 另外一方面也可以讓收集的數據單純化以 利分析。
  9. 9.  我們將收集到的資料存放到監測主機的 mongo DB 之中,並利用 xhgui 這個 web ui 加以分析。採用 mongo DB 除了可以支 援更多的資料筆數,未來各網站主機所收 集的資訊也可以統一集中管理與分析。 分析專用網站服務器與數據收集/分析服務 器皆安裝 CentOS 6。
  10. 10.  安裝 EPEL  下載合適的版本 http://mirror01.idc.hinet.net/EPEL/6/i386/repov iew/epel-release.html  安裝下載的 rpm
  11. 11.  安裝 php-pecl-xhprof 與 php-pecl-mongo  yum install -y php-pecl-xhprof php-pecl-mongo
  12. 12.  安裝 git  yum install -y git
  13. 13.  安裝 xhgui (以 /var/www/lib 為例)  mkdir /var/www/lib  cd /var/www/lib  git clone https://github.com/preinheimer/xhgui
  14. 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. 15.  修改 Apache 設定  … ServerName www.myserver.tw php_admin_value auto_prepend_file /var/www/lib/xhgui/external/header.php …  上述設定可以加在虛擬主機或是全域設定。 重新啟動 Apache  service httpd restart
  16. 16.  安裝 EPEL  下載合適的版本 http://mirror01.idc.hinet.net/EPEL/6/i386/repov iew/epel-release.html  安裝下載的 rpm
  17. 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. 18.  安裝 php-devel  yum install -y php-devel
  19. 19.  安裝 PHP 專用的 mongo DB 函式  pecl install mongo 請勿安裝 php-pecl-mongo,否則將會因版 本過舊而造成 xhgui 的執行錯誤。
  20. 20.  安裝 git  yum install -y git
  21. 21.  安裝 xhgui (以 /var/www/lib 為例)  mkdir /var/www/lib  cd /var/www/lib  git clone https://github.com/preinheimer/xhgui
  22. 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. 23.  我們選定分析專用網站服務器上的一個特 定網頁,使用瀏覽器對其進行存取。因為 這是測試專用的服務器,所以利用瀏覽器 外掛的方式,每分鐘自動重新載入一次以 便觀察數據的變化。 連結至 http://192.168.0.10/xhgui (其中 192.168.0.1 請取代為數據收集/分析服務 器的 IP 位址)。
  24. 24.  mongo DB 與 xhgui 預設都沒有密碼保護 的機制,請注意小心設定防火牆與 Apache 服務器的相關設定,以避免非授權的使用。
  25. 25.  測試採用每分鐘重新載入一次的方式,除此之 外應該沒有其他的存取行為。我們看到 /api/project/barcode/?pid=b6471082aaa&h=1 03&revision=1&w=412 這個 URL 每分鐘皆連 續出現兩次,表示在每次存取這個特定的網頁 時都會載入上述的 URL 兩次。 上述行為雖然不會產生錯誤,但是會對網站產 生不必要的負載,並影響使用者的使用順暢度。 這種行為在複雜的網頁中,可能因為不同功能 模組之間的不協調而造成。
  26. 26.  進一步分析此 URL 執行數據發現 session_start 占用的 wall 時間比例相當高。 網站 Session 架構在 NFS 上,而 NFS 對 於大量檔案的讀寫容易產生效能的瓶頸。 即使是在網站流量較低的時候, session_start 佔用比例與數值仍相當高。
  27. 27.  session_start 占用高比例 wall 時間的現象 幾乎存在於全部的 URL。即使是有些應該 不會使用到 session data 的 URL 也會呼叫 session_start,並占用過多 wall 時間。
  28. 28.  此網頁載入過多資源,累加的延遲時間將 可能嚴重影響使用者操作的順暢度。
  29. 29. 1. 改用其他機制 (如 redis) 取代 NFS 作為 session data 的儲存機制。2. 檢測程式以避免不必要的 URL 呼叫。3. 關閉 session auto start 的功能,只有必須使 用 session data 的程式才啟用 session。4. 減少非必要資源的載入,或將資源整合以減 少連結的次數。如可以將多張小圖合成一張 大圖(可利用js進行切割),或是將網頁區塊整 合,甚至是利用 client 端的快取。
  30. 30.  前面四項建議,除了第一項之外都必須修改程 式,所以在此我僅對第一項建議做出後續的測 試。 後續測試將 Session data 改用本機硬碟與 redis 的方式分別加以進行。  本機硬碟因為不具備分享功能,所以僅做為比較之 後。  redis 類似 memcache,為一種記憶體快取機制。 與 memcache 比較,redis 支援 master/slave 架構, 而且可以將內容儲存在檔案之中,以避免重新啟動 資料遺失的問題。除此之外,redis 支援自動移除 過期資料的功能,可以減少後續維護的負擔。
  31. 31.  雖然比例有下降的現象,但是比例仍高。 因為分析專用網站服務器的硬碟效能本就 不高,所以此一數據並不意外。 session_start 的 wall 時間並沒有很明顯的 下降,考慮到流量增加後的狀況,顯見不 是一個很好的解決方案。
  32. 32.  在數據上已經完全看不到 session_start 佔 用的 wall 時間。 為了確認結果,我們再找其他比較"單純"的 URL 做比較。
  33. 33.  從前面另一個例子,我們可以看到 session_start 的 wall 時間從 156,166us 降為 1,284us,下降的比例相當明顯。 因為我們目前只有將分析專用網站服務器的 Session 資料改至 redis,所以對 redis 的負載 較小。如果全面導入後,應該持續監測相關數 據,以確保施作達到預期效益。 Redis 會自動清除逾期的 Session data,與使 用檔案時的行為不同。雖然前者才是正確的行 為,但是仍有可能因為之前程式錯誤的引用 Session data 而造成資料無法取得的現象。
  34. 34.  因為此一改進僅分別針對單一 URL,對於 一整個網頁的完整下載時間仍受到其他因 素影響 (如前面提到的現象四),所以仍須 用其他方法持續改進使用者的感受。
  35. 35.  當運用 xhprof 在線上環境時,為了避免產 生過多的數據而影響網站運行,可以採用 取樣的方式。舉例來說,可以每一千個請 求才記錄一次(隨機)。 採樣的頻率除了必須依據網站流量進行適 當的調整外,對於不同的應用時機也必須 隨之改變。例如當日常收集時可以採用較 低的比例,但是如果要追蹤特定的問題時, 就可以暫時提高取樣的頻率,以便"近距離" 觀察。
  36. 36.  Session data 對於現今強調互動與個人化的網 站來說是很重要的一環,但是如果沒有做好良 好的使用準則與儲存規劃,不但可能造成對效 能的負面影響,在網站擴充時更是往往造成莫 大的限制。 透過實際觀察線上環境的效能數據,可以讓我 們發現一些因規劃疏忽或網站成長所造成的效 能瓶頸。 解決效能問題是一連串不斷的改進,解決了一 個,還有下一個更困難的正在等著呢。
  37. 37. 歡迎指教cyril.hcwang@gmail.com

×