1. 程式人生 > >效能監控的好工具

效能監控的好工具

https://ruby-china.org/topics/22379

我們蟬遊記伺服器端效能監控一直用 http://newrelic.com/ ,用它的免費版本N長時間,有必要為好工具義務宣傳一下。

首先你需要在網站上註冊一個新帳號,根據伺服器端的應用框架選擇安裝對應的外掛,它提供了很多常見應用框架外掛,以Rails為例子,只需要在Gemfile配置,執行bundle install即可:

gem 'newrelic_rpm'

然後下載對應的newrlic.yml配置檔案,放入到應用目錄,進行一些引數的調整。將應用重新部署以後,等幾分鐘,讓外掛收集到效能相關資料,再去訪問NewRelic網站,就可以看到各種圖表了。

首先需要關注的是請求的響應時間圖表,用這個圖表可以對請求在伺服器端耗時有個整體印象:

B315e203-5433-3aa0-8a28-1ef87c9b70c1
從圖表上可以看到,在這個時間段,請求的平均耗時是52ms,同時可以看到每個請求的Ruby程式碼和資料庫執行時間佔據了絕大部分,還有少量的外部服務呼叫時間(比如第3方Oauth或者API)。由於我們使用OOB GC,所以在圖表上幾乎沒有GC的時間。

另外右上角有一個3.58s的瀏覽器時間,這個是指使用者訪問網頁,從請求發出,到整個頁面完全載入完成(包括圖片,css,js等)。

第二個圖表是Apdex (Application Performance Index),從這裡可以看到大部分使用者是否滿意你的應用響應速度:

2a4f6da4-3dac-3cd4-bd65-f05075428660

從圖表可以看到,99%的使用者非常滿意請求響應時間(在我們的應用裡面,大部分請求是客戶端呼叫api),93%的使用者非常滿意頁面載入完成的時間。我們用的指標是NewRelic預設設定的500ms和7s,你還可以自己進行調整。

第3個圖表是吞吐量

0dc40e73-6f1b-3599-ae73-6ade99623007
可以看出在這半個小時的區間,平均每分鐘有1050個請求。用這個圖表,通過調整時間段(,瞭解整個應用什麼時候是高峰,什麼時候是低谷,方便將一些批處理,備份等任務放在訪問低谷的時間段進行。還有當使用者報告無法訪問的時候,可以通過檢視吞吐量是否有急劇下降,來判斷是個例還是整體故障,來確定解決問題的優先順序。免費版本的NewRelic,只能檢視過去24小時的資料,升級到付費帳號,可以檢視所有的歷史資料。

第4個圖表是根據請求的時間和請求的次數,列出一個最耗時的請求

Ffdf1aba-03e5-3962-aab7-5c807272f1bd
我們可以根據這個排列順序,來考慮對於訪問量大,同時又耗時的請求進行重點效能優化。
點選具體的請求,還可以看到請求耗時的分佈情況:
8c9b5712-5bf8-38b8-9905-df348e632a4d
從圖表上可以看到這個請求,在渲染json資料耗費了比較多的時間,另外在ActiveRecord的查詢上也耗費了一些時間,如果要優化的話,就可以從渲染結果加片段快取,或者查詢優化入手。升級到付費版本,還能檢視到具體的sql語句執行情況,如果有slow query,還能顯示explain的結果。

第5個圖表,是錯誤率

101f9130-11e4-341e-b3df-e3054252fd69
在我們應用中引發錯誤的大部分是一些爬蟲404,還有一些是異常資料沒有處理好導致,這裡就不詳細介紹了。這個圖表對於使用者反饋錯誤定位也是很有幫助的。

第6個圖表,是應用效能分佈到各個伺服器狀態

3a4f6585-e5a6-3a4a-bf1a-56049d3af2d9
對於瞭解伺服器資源和擴容計劃很有幫助。順便說一個實際遇到的事情,發現過某臺主機(我們用的雲主機)的響應時間就是比其他臺要慢50%以上,對比發現這臺的CPU和Disk IO都比其他臺要弱,後來報告給雲主機服務商,通過遷移到了新的物理機解決了。

除了上述的這些效能圖表,NewRelic也提供了很多監控的選項,比如ping,記憶體/儲存警報等,可以將報警傳送到郵件,或者推送到移動客戶端:

48479e62-88b9-3d0b-b98d-0be4d6c6c135

這裡就簡單介紹一下它免費版本的少量功能,更多的功能留待大家去玩吧。最後還要提一下最喜歡的scalability report和database report,可以申請試用付費帳號來體驗,是我見過最讚的報表了。