除了RPS和錯誤率，性能測試還須要關注這些指標

背景

最近發現交給外包作的性能測試，外包人員除了看RPS、錯誤率，其餘指標徹底不看。

我陷入了思考，如今不少公司爲了下降性能測試的門檻，內部會針對一些開源框架進行二次開發，以用戶很是友好的WEB頁面呈現出來。所以，在不少測試人員看來，所謂的性能測試不就是調一下併發，看看頁面顯示的RPS，哪裏報錯，就找開發定位。這麼簡單，哪有什麼神祕感？真的是這樣嗎？若是是這樣，爲何性能測試專家這麼吃香？爲何有一些人能夠在性能測試領域深耕多年甚至超過十年？換一個思路，當你進行性能摸底，發現某個節點，RPS就上不去了，你很差奇爲何嗎？爲何不懂得去看看系統指標，肯定哪裏是瓶頸？

反正我以爲性能測試最有意思的就是測試過程的問題定位、排查，性能測試結束以後的瓶頸分析、結論分析。因此，寫了這篇文章，想告訴你們除了RPS和錯誤率，你還能夠關注什麼。

施壓端

• RPS：即吞吐量，每秒鐘系統能夠處理的請求數、任務數。
• 請求響應時間
  • 服務處理一個請求或者任務的耗時，包括網絡鏈路耗時。
  • 分類：平均值、99分位數、中位數、最大值最小值
• 錯誤率：一批請求中結果出錯的請求所佔比例。

被測服務

• CPU
• 內網
• IO wait
• 網絡帶寬
• Load：負載
  • TOP：1min、5min、15min

Linux系統的CPU統計維度

• us：用戶態使用的cpu時間百分比
• sy：系統胎使用的cpu時間百分比
  • sy太高意味着被測服務在用戶態和系統態之間切換比較頻繁，此時系統總體性能會有必定降低
  • 在使用多核CPU的服務器上，CPU0負責CPU各核之間的調度，CPU0的使用率太高會致使其餘CPU核心之間的調度效率變低。
• ni：用作nice加權的進程分配的用戶態cpu時間百分比
  • 通常來講，被測服務和服務器總體的ni值不會很高，若是測試過程當中nic的值比較高，須要從服務器Linux系統配置、被測服務運行參數查找緣由。
• id：空閒的cpu時間百分比
  • 線上服務運行過程，須要保留必定的idle冗餘來應對突發的流量激增。
  • 性能測試過程當中，若是id一直很低，吞吐量上不去，須要檢查被測服務線程/進程配置、服務器系統配置等。
• wa：cpu等待io完成時間百分比
  • 磁盤、網絡等IO操做會致使CPU的wa指標增高。一般狀況下，網絡IO佔用的wa資源不會很高，而頻繁的磁盤讀寫會致使wa激增。
  • 影響IO的因素：日誌量、數據載入頻率等。
• hi：硬中斷消耗時間百分比
  • 硬中斷：外設對CPU的中斷
• si：軟中段消耗時間百分比
  • 軟中斷：軟件自己發給操做系統內核的中斷信號。
  • IO密集型的服務，si的CPU佔用率會高一些。

內存統計維度

• VIRT：進程所使用的虛擬內存的總數。它包括全部的代碼、數據和共享庫，加上已經SWAP的頁面，全部已申請的總內存空間。
• RES：進程正在使用的沒有交換的物理內存（堆、棧）
• SHR：進程使用共享內存的總數。該數值只是反映可能與其餘進程共享的內存，不表明這段內存當前正被其餘進程使用。
• SWAP：進程使用的虛擬內存中被換出的大小，交換的是已經申請，但沒有使用的空間，包括堆、棧、共享內存
• DATA：進程可執行代碼之外的物理內存總量，即進程棧、堆申請的總空間。

load

• load：指運行隊列的平均長度，也就是等待CPU的平均進程數。
• 服務器運行最理想的狀態是全部CPU核心的運行隊列都爲1，即全部活動進程都在運行，沒有等待。
• 按照經驗值，服務器的負載應位於閾值的70%～80%，這樣既能服務器大部分性能，又留有必定的性能冗餘應對流量增加。
• 查看系統負載的命令：top、uptime, 輸出系統最近1分鐘、5分鐘、15分鐘的負載均值。
• 性能測試：併發測試時系統的負載最高不能超過閾值的80%；穩定性測試，系統負載應在閾值的50%左右。

網絡相關指標

性能測試中網絡監控主要包括網絡流量、網絡鏈接狀態的監控。

• 網絡流量監控：能夠好似喲功能nethogs
• 網絡鏈接狀態監控：主要監控網絡鏈接狀態的變化和異常。
  • TCP協議的服務，須要監控服務已創建鏈接的變化狀況（即ESTABLISH狀態的TCP鏈接）。
  • HTTP協議的服務，須要監控被測服務對應進程的網絡緩衝區的狀態，TIME_WAIT狀態的鏈接數等。
  • 經常使用命令：netstat、ss
    • 監控指定進程：netstat -nalp | grep pid

磁盤IO關注數據

• 經常使用命令：iostat iostat -x -d 2 6
• tps：設備每秒的傳輸次數。一次傳輸指一次I/O請求。
• kB_read/s：每秒從設備讀取的數據量，單位爲 kb
• kB_wrtn/s：每秒向設備寫入的數據量，單位爲Kb
• kB_read：讀取的總數據量，單位爲Kb
• Kb_wrtn：寫入的總數據量，單位爲Kb
• rrqm/s：每秒這個設備相關的讀取請求有多少被Merge了。
  • Merge：當系統調用須要讀取數據的時候，VFS將請求發到各個FS，若是FS發現不一樣的讀取請求讀取的是相同block的數據，FS會將這個請求合併Merge
• wrqm/s：每秒這個設備相關的寫入請求有多少被merge了
• await：每個IO請求的處理的平均時間，單位是毫秒
• %util：在統計內全部處理IO時間，除以總共統計時間。該參數表示設備的繁忙程度。

常見性能瓶頸

• 吞吐量到上線時系統負載未到閾值：可能緣由
  1. 被測服務分配的系統資源過少
• CPU的us和sy不高，但wa很高：可能緣由
  1. 被測服務是IO密集型服務
  2. 服務對磁盤讀寫的業務邏輯有問題，讀寫頻率太高，寫入數據量過大
  3. 服務器內存不足，服務在swap分區不停的換入換出
• 同一請求的響應時間忽大忽小，可能緣由：
  1. 服務對資源的加鎖邏輯有問題，致使某些請求過程當中花了大量的時間等待資源解鎖
  2. Linux自己分配給服務器的資源有限，某些請求須要等待其餘請求釋放自由後才能繼續運行
• 內存持續上漲：多是被測服務存在內存泄漏，須要使用valgrind等內存檢測工具進行定位。

附錄：nice值

top命令中ni指：用戶進程空間內改變過優先級的進程佔用CPU百分比。

• nice：指進程可被執行的優先級的修正數值。
• nice取值： -20～19，用戶能夠設置的最大值爲19.
• 能夠經過修改進程優先級來加速進程運行
  • renice -10 -p pid
• PRI：進程的優先級，值越小進程的優先級越高
  • PRI（new）=PRI（old）+nice
  • PR是根據nice排序的，規則是nice越小優先級變高，進程越快被執行。若是nice相同進程uid是root的優先級更高。

思考時間：指用戶進行操做時每一個請求之間的時間間隔。

參考：http://www.javashuo.com/article/p-tfxrkylx-ed.html