除了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的優先級更高。

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

參考：https://blog.csdn.net/hahavslinb/article/details/78673267