性能压测模板整理
1 測試指標
根據服務實際情況選擇需要評估指標進行衡量
1.1 CPU性能
1.1.1 CPU 使用率
| 用戶CPU使用率 | 系統CPU使用率 | iowait CPU使用率 | 軟中斷和硬中斷的 CPU 使用率 |
用戶 CPU 使用率,包括用戶態 CPU 使用率(user)和低優先級用戶態 CPU 使用率(nice),表示 CPU 在用戶態運行的時間百分比。用戶 CPU 使用率高,通常說明有應用程序比較繁忙。
系統 CPU 使用率,表示 CPU 在內核態運行的時間百分比(不包括中斷)。系統 CPU 使用率高,說明內核比較繁忙。
等待 I/O 的 CPU 使用率,通常也稱為 iowait,表示等待 I/O 的時間百分比。iowait 高,通常說明系統與硬件設備的 I/O 交互時間比較長。
軟中斷和硬中斷的 CPU 使用率,分別表示內核調用軟中斷處理程序、硬中斷處理程序的時間百分比。它們的使用率高,通常說明系統發生了大量的中斷。
統計數據的方式
$top
用戶CPU使用率 = us + ni
系統CPU使用率 = sy
iowait CPU使用率 = wa
軟中斷和硬中斷的 CPU 使用率 = si + hi
1.1.2 平均負載
指單位時間內,系統處于可運行狀態和不可中斷狀態的平均進程數,也就是平均活躍進程數
| 1min | 5min | 15min |
衡量負載的標準
需要根據當前的cpu數來進行比較,需要先計算出當前服務所在服務器上的cpu數來衡量
$grep 'model name' /proc/cpuinfo | wc -l
例:假設我們在一個單 CPU 系統上看到平均負載為 1.73,0.60,7.98,那么說明在過去 1 分鐘內,系統有 73% 的超載,而在 15 分鐘內,有 698% 的超載,從整體趨勢來看,系統的負載在降低(超載量=平均負載- CPU數量)
如果 1 分鐘、5 分鐘、15 分鐘的三個值基本相同,或者相差不大,那就說明系統負載很平穩。
如果 1 分鐘的值遠小于 15 分鐘的值,就說明系統最近 1 分鐘的負載在減少,而過去 15 分鐘內卻有很大的負載。
如果 1 分鐘的值遠大于 15 分鐘的值,就說明最近 1 分鐘的負載在增加,這種增加有可能只是臨時性的,也有可能還會持續增加下去,所以就需要持續觀察。一旦 1 分鐘的平均負載接近或超過了 CPU 的個數,就意味著系統正在發生過載的問題,這時就得分析調查是哪里導致的問題,并要想辦法優化了
統計數據的方式
uptime //或者top
后面三個數字,依次則是過去 1 分鐘、5 分鐘、15 分鐘的平均負載
1.2 內存性能
1.2.1 系統內存性能
| total | used | free | shared | buff/cache | available |
total 是總內存大小
used 是已使用內存的大小,包含了共享內存
free 是未使用內存的大小?
shared 是共享內存的大小
buff/cache 是緩存和緩沖區的大小
available 是新進程可用內存的大小。
統計數據的方式
free -h
1.2.2 程序內存性能
| VIRT | RES | SHR | %MEM |
VIRT 是進程虛擬內存的大小,只要是進程申請過的內存,即便還沒有真正分配物理內存,也會計算在內。
RES 是常駐內存的大小,也就是進程實際使用的物理內存大小,但不包括 Swap 和共享內存。
SHR 是共享內存的大小,比如與其他進程共同使用的共享內存、加載的動態鏈接庫以及程序的代碼段等。共享內存 SHR 并不一定是共享的,比方說,程序的代碼段、非共享的動態鏈接庫,也都算在 SHR 里。當然,SHR 也包括了進程間真正共享的內存。所以在計算多個進程的內存使用時,不要把所有進程的 SHR 直接相加得出結果
%MEM 是進程使用物理內存占系統總內存的百分比。
統計數據的方式
top
1.3 網絡性能
1.3.1 網絡層和數據鏈路層轉發性能?
在這兩個網絡協議層中,每秒可處理的網絡包數 PPS,就是最重要的性能指標。特別是 64B 小包的處理能力,需要特別測試。
測試工具推薦 pktgen
| 所用時間 | 網絡包數量 | PPS | 吞吐量 | 錯誤數 |
1.3.2 傳輸層TCP/UDP 性能
測試工具推薦 iperf 或者 netperf
iPerf - iPerf3 and iPerf2 user documentation
Care and Feeding of Netperf 2.7.X
壓測一段時間記錄pps和吞吐率
# 數字1表示每隔1秒輸出一組數據
sar -n DEV 1
Linux 4.15.0-1035 (ubuntu) 01/06/19 _x86_64_ (2 CPU)
13:21:40 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
13:21:41 eth0 18.00 20.00 5.79 4.25 0.00 0.00 0.00 0.00
13:21:41 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
| 吞吐量 | PPS |
rxpck/s 和 txpck/s 分別是接收和發送的 PPS,單位為包 / 秒。
rxkB/s 和 txkB/s 分別是接收和發送的吞吐量,單位是 KB/ 秒。
rxcmp/s 和 txcmp/s 分別是接收和發送的壓縮數據包數,單位是包 / 秒。
%ifutil 是網絡接口的使用率,即半雙工模式下為 (rxkB/s+txkB/s)/Bandwidth,而全雙工模式下為 max(rxkB/s, txkB/s)/Bandwidth
1.3.3 應用層HTTP/HTTPS 性能
測試工具推薦 wrk
相對ab和iperf這類工具來說,wrk可以嵌入lua腳本,給請求增加payload,更接近實際應用場景,測出服務的真實性能。
# -c表示并發連接數1000,-t表示線程數為2,-d表示測試持續時間單位s
?wrk -c 1000 -t 2 -d 300s --latency http://192.168.1.1/
wrk 安裝方式
https://github.com/wg/wrk
cd wrk
apt-get install build-essential -y
make
sudo cp wrk /usr/local/bin/
| QPS | 吞吐率 | 請求總數 | 請求失敗總數 | 請求成功率 |
請求延遲的分布
| 50% | 75% | 90% | 99% |
附上延時分布條形圖
8 threads and 200 connections (共8個測試線程,200個連接)
Thread Stats? Avg? ? ? Stdev? ? Max? +/- Stdev(平均值) (標準差)(最大值)(正負一個標準差所占比例)Latency? ? 46.67ms? 215.38ms? 1.67s? ? 95.59%(延遲)Req/Sec? ? 7.91k? ? 1.15k? 10.26k? ? 70.77%(處理中的請求數)Latency Distribution (延遲分布)50%? ? 2.93ms75%? ? 3.78ms90%? ? 4.73ms99%? ? 1.35s (99分位的延遲:%99的請求在1.35s以內)1790465 requests in 30.01s, 684.08MB read (30.01秒內共處理完成了1790465個請求,讀取了684.08MB數據)Requests/sec:? 59658.29 (平均每秒處理完成59658.29個請求)Transfer/sec:? ? 22.79MB (平均每秒讀取數據22.79MB)
?
- 先使用單線程不斷增加連接數,直到QPS保持穩定或響應時間超過業務要求限制。在當期數值取得單線程最優連接數。 ?
- 單個連接線程數保持不變,不斷增加線程數(建議到CPU核心數為止即可),直到整體出現QPS水平。
- 如果QPS沒有出現隨著線程數增長則是目標服務器性能已經達到瓶頸,wrk單線程即可壓測出目標機器最優QPS。
- 如果QPS一直沒有出現水平趨勢,則說明wrk壓測機性能出現了瓶頸,需要擴大wrk壓測機性能或者增加壓測機器集群。
- 運行 wrk 的機器必須有足夠數量的可用臨時端口,并且應該快速回收關閉的套接字。 為了處理初始連接突增,服務器的 listen(2) backlog 應該大于正在測試的并發連接數。
測試短鏈接并發連接數
Releases · link1st/go-stress-testing · GitHub
-c?表示并發數
-n?每個并發執行請求的次數,總請求的次數 = 并發數?*?每個并發執行請求的次數
-u?需要壓測的地址
# 運行 以mac為示例
./go-stress-testing-mac -c 1 -n 100 -u https://www.baidu.com/
模板如下:
性能測試 模板
1、概況
1.1 測試背景
簡要描述與測試項目相關的一些背景資料,如項目上線計劃、測試需求等。
1.2 測試目的
在大用戶量、數據量的超負荷下,獲得服務器運行時的相關數據,從而進行分析,查看xx服務是否符合需求。
1.3 測試范圍
本次測試主要是對xx 服務的性能測試。
2. 測試工具及環境
2.1 測試環境
描述測試環境的物理架構,可以用物理架構圖來展示。
2.2 基本配置
描述如何部署測試環境基于測試前需要配置的一些參數等。
測試環境
| 操作系統 | 網絡 | 內存 |
被測服務的環境
| 操作系統 | 網絡 | 內存 | 被測對象commit號/版本號 |
2.3 測試工具
a.壓測工具:go-stress和wrk
b.監控工具:graph
3、測試內容
3.1 增加并發連接數(短鏈接)
# -c 表示并發數 -n 表示每個并發執行請求的次數
./go-stress-testing-mac -c 1000 -n 1000 -u https://www.baidu.com/
./go-stress-testing-mac -c 10000 -n 1000 -u https://www.baidu.com/
./go-stress-testing-mac -c 20000 -n 1000 -u https://www.baidu.com/
./go-stress-testing-mac -c 50000 -n 1000 -u https://www.baidu.com/
| 并發連接數 | CPU | ||||
| 系統 | 進程 | ||||
| 用戶CPU使用率 | 系統CPU使用率 | iowait CPU使用率 | 軟中斷和硬中斷的 CPU 使用率 | 進程CPU使用率 | |
| 1000 | |||||
| 10000 | |||||
| 20000 | |||||
| 50000 | |||||
| 并發連接數 | 內存 | |
| 系統使用內存 | 進程使用內存 | |
| 1000 | ||
| 10000 | ||
| 20000 | ||
| 50000 | ||
| 并發連接數 | 網絡 | |||||
| QPS | 吞吐率 | 請求失敗率 | 請求分布延時 | |||
| p75 | p90 | p99 | ||||
| 1000 | ||||||
| 10000 | ||||||
| 20000 | ||||||
| 50000 | ||||||
將以上表格中的CPU、內存、網絡(除請求延時繪制成條形圖外)繪制成折線圖。
3.2 增加連接數(長連接)
測試工具 wrk
# -c表示并發連接數1000,-t表示線程數為2,-d表示測試持續時間單位s
?wrk -c 1000 -t 10 -d 600s --latency http://192.168.1.1/
?wrk -c 10000 -t 100 -d 600s --latency http://192.168.1.1/
?wrk -c 20000 -t 200 -d 600s --latency http://192.168.1.1/
?wrk -c 50000 -t 500 -d 600s --latency http://192.168.1.1/
| 并發連接數 | CPU | ||||
| 系統 | 進程 | ||||
| 用戶CPU使用率 | 系統CPU使用率 | iowait CPU使用率 | 軟中斷和硬中斷的 CPU 使用率 | 進程CPU使用率 | |
| 1000 | |||||
| 10000 | |||||
| 20000 | |||||
| 50000 | |||||
| 并發連接數 | 內存 | |
| 系統使用內存 | 進程使用內存 | |
| 1000 | ||
| 10000 | ||
| 20000 | ||
| 50000 | ||
| 并發連接數 | 網絡 | |||||
| QPS | 吞吐率 | 請求失敗率 | 請求分布延時 | |||
| p75 | p90 | p99 | ||||
| 1000 | ||||||
| 10000 | ||||||
| 20000 | ||||||
| 50000 | ||||||
3.3 增加機器數,壓出直至服務所在服務器上的CPU能達到95%以上
| 壓測機器數 | 網絡 | 內存 |
| 1 | 153.165 | |
| 2 | ||
| ... |
測試工具 wrk
# -c表示并發連接數1000,-t表示線程數為2,-d表示測試持續時間單位s
?wrk -c 50000 -t 500 -d 600s --latency http://192.168.1.1/ //server-1
?wrk -c 50000 -t 500 -d 600s --latency http://192.168.1.1/ //server-2
?wrk -c 50000 -t 500 -d 600s --latency http://192.168.1.1/ //server-3
...
| 并發連接數 | CPU | ||||
| 系統 | 進程 | ||||
| 用戶CPU使用率 | 系統CPU使用率 | iowait CPU使用率 | 軟中斷和硬中斷的 CPU 使用率 | 進程CPU使用率 | |
| 50000 | |||||
| 并發連接數 | 內存 | |
| 系統使用內存 | 進程使用內存 | |
| 50000 | ||
| 并發連接數 | 網絡 | |||||
| QPS | 吞吐率 | 請求失敗率 | 請求分布延時 | |||
| p75 | p90 | p99 | ||||
| 50000 | ||||||
3.4 使用大文件傳輸,測試出吞吐率
測試工具 wrk
# -c表示并發連接數1000,-t表示線程數為2,-d表示測試持續時間單位s
?wrk -c 1000 -t 100 -d 600s --latency http://192.168.1.1/
| 并發連接數 | CPU | ||||
| 系統 | 進程 | ||||
| 用戶CPU使用率 | 系統CPU使用率 | iowait CPU使用率 | 軟中斷和硬中斷的 CPU 使用率 | 進程CPU使用率 | |
| 1000 | |||||
| 并發連接數 | 內存 | |
| 系統使用內存 | 進程使用內存 | |
| 1000 | ||
| 并發連接數 | 網絡 | |||||
| QPS | 吞吐率 | 請求失敗率 | 請求分布延時 | |||
| p75 | p90 | p99 | ||||
| 1000 | ||||||
3.5 持續壓測72小時,保持服務所在的服務器CPU達到百分之70,測試穩定性
| 壓測時間 | 服務是否正常 |
4、測試結果與分析
結論:
? ? ? ? ? ? 1.當并發連接數達到最大值xx ,CPU的占用為xx%,內存占用xxM,平均延時為xxms, 請求失敗率為xx%.
? ? ? ? ? ? 2.當長連接數達到最大值xx,CPU的占用為xx%,內存占用xxM,p90為xxms, 請求失敗率為xx%,QPS為xx,吞吐率為xx.
? ? ? ? ? ? 3.xxx性能在CPU方面占用過多,過多的系統調用導致CPU飆升,內存占用過多,需要相應的優化.
? ? ? ? ? ? 4.給出運行服務所需要的配置參數列表
總結
- 上一篇: Scheme 语言 第一次的感触!
- 下一篇: JAVA UUID 获取方法