1. 首頁 > 生活百科 > >

怎么獲取Node性能監控指標？獲取方法分享( 三 )

it知識小知識


獲取I/O指標 ， 我們要了解一個linux命令 ， 叫iostat ， 如果沒有安裝 ， 需要安裝一下 ， 我們看一下這個命令為啥能反應I/O指標
iostat -dx

怎么獲取Node性能監控指標？獲取方法分享

文章插圖

屬性說明
rrqm/s: 每秒進行 merge 的讀操作數目 。 即 rmerge/s（每秒對該設備的讀請求被合并次數 ， 文件系統會對讀取同塊(block)的請求進行合并）wrqm/s: 每秒進行 merge 的寫操作數目 。 即 wmerge/s（每秒對該設備的寫請求被合并次數）r/s: 每秒完成的讀 I/O 設備次數 。 即 rio/sw/s: 每秒完成的寫 I/O 設備次數 。 即 wio/srsec/s: 每秒讀扇區數 。 即 rsect/swsec/s: 每秒寫扇區數 。 即 wsect/srkB/s: 每秒讀K字節數 。 是 rsect/s 的一半 ， 因為每扇區大小為512字節 。 wkB/s: 每秒寫K字節數 。 是 wsect/s 的一半 。 avgrq-sz: 平均每次設備I/O操作的數據大小 (扇區) 。 avgqu-sz: 平均I/O隊列長度 。 await: 平均每次設備I/O操作的等待時間 (毫秒) 。 svctm: 平均每次設備I/O操作的處理時間 (毫秒) 。 %util: 一秒中有百分之多少的時間用于 I/O 操作 ， 即被io消耗的cpu百分比我們只監控%util就行
    如果 %util 接近 100% ， 說明產生的I/O請求太多 ， I/O系統已經滿負荷 ， 該磁盤可能存在瓶頸 。
    如果 await 遠大于 svctm ， 說明 I/O 隊列太長 ， 應用得到的響應時間變慢 ， 如果響應時間超過了用戶可以容許的范圍 ， 這時可以考慮更換更快的磁盤 ， 調整內核 elevator 算法 ， 優化應用 ， 或者升級 CPU 。
響應時間RT監控監控Nodejs的頁面響應時間, 方案選自廖雪峰老師的博客文章 。
最近想監控一下Nodejs的性能 。 記錄分析Log太麻煩 ， 最簡單的方式是記錄每個HTTP請求的處理時間 ， 直接在HTTP Response Header中返回 。
記錄HTTP請求的時間很簡單 ， 就是收到請求記一個時間戳 ， 響應請求的時候再記一個時間戳 ， 兩個時間戳之差就是處理時間 。
但是 ， res.send()代碼遍布各個js文件 ， 總不能把每個URL處理函數都改一遍吧 。
正確的思路是用middleware實現 。 但是Nodejs沒有任何攔截res.send()的方法 ， 怎么破？
其實只要稍微轉換一下思路 ， 放棄傳統的OOP方式 ， 以函數對象看待res.send() ， 我們就可以先保存原始的處理函數res.send ， 再用自己的處理函數替換res.send：
app.use(function (req, res, next) { // 記錄start time: var exec_start_at = Date.now(); // 保存原始處理函數: var _send = res.send; // 綁定我們自己的處理函數: res.send = function () { // 發送Header: res.set('X-Execution-Time', String(Date.now() - exec_start_at)); // 調用原始處理函數: return _send.apply(res, arguments); }; next();});只用了幾行代碼 ， 就把時間戳搞定了 。
對于res.render()方法不需要處理 ， 因為res.render()內部調用了res.send() 。
調用apply()函數時 ， 傳入res對象很重要 ， 否則原始的處理函數的this指向undefined直接導致出錯 。
實測首頁響應時間9毫秒
監控吞吐量/每秒查詢率 QPS名詞解釋：
一、QPS ， 每秒查詢QPS：Queries Per Second意思是“每秒查詢率” ， 是一臺服務器每秒能夠響應的查詢次數 ， 是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準 。
互聯網中 ， 作為域名系統服務器的機器的性能經常用每秒查詢率來衡量 。
二、TPS ， 每秒事務TPS：是TransactionsPerSecond的縮寫 ， 也就是事務數/秒 。 它是軟件測試結果的測量單位 。 一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程 。 客戶機在發送請求時開始計時 ， 收到服務器響應后結束計時 ， 以此來計算使用的時間和完成的事務個數 。
QPS vs TPS：QPS基本類似于TPS ， 但是不同的是 ， 對于一個頁面的一次訪問 ， 形成一個TPS；但一次頁面請求 ， 可能產生多次對服務器的請求 ， 服務器對這些請求 ， 就可計入“QPS”之中 。 如 ， 訪問一個頁面會請求服務器2次 ， 一次訪問 ， 產生一個“T” ， 產生2個“Q” 。
三、RT ， 響應時間響應時間：執行一個請求從開始到最后收到響應數據所花費的總體時間,即從客戶端發起請求到收到服務器響應結果的時間 。
響應時間RT(Response-time) ， 是一個系統最重要的指標之一 ， 它的數值大小直接反應了系統的快慢 。
四、并發數并發數是指系統同時能處理的請求數量 ， 這個也是反應了系統的負載能力 。
五、吞吐量系統的吞吐量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯 。 單個request 對CPU消耗越高 ， 外部系統接口、IO速度越慢 ， 系統吞吐能力越低 ， 反之越高 。

推薦閱讀