Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,627 views

Published on

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

Published in: Technology
  • Be the first to comment

如何使用 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

×