《xxxxxx》監測服務壓力測試報告
文檔修訂記錄
| 版本號 |
日期 |
修改人 |
摘要 |
| V1.0 |
2019年8月14日 |
xxx |
初稿 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
內容目錄
一、測試內容-------------------------------------------------------------4
二、測試方法-------------------------------------------------------------4
三、測試目標 -------------------------------------------------------------4
四、測試環境------------------------------------------------------------- 5
1.系統環境配置 -------------------------------------------------------5
2.測試客戶端配置 ----------------------------------------------------5
3網絡環境 ---------------------------------------------------------------5
4.測試時間-------------------------------------------------------------- 5
五、系統部署 ---------------------------------------------------------------5
六、測試說明------------------------------------------------------------------- 5
七、測試統計及分析------------------------------------------------------------- 6
八、結果------------------------------------------------------------------------- 10
九、結論及建議 ----------------------------------------------------------------10
1.結論：------------------------------------------------------------------ 10
2.建議：------------------------------------------------------------------ 10
一、測試內容
本次測試是針對《xxxx數字化營銷》系統內的監測服務進行的壓力測試,本次壓測主要提取廣告監測代碼進行壓測:廣告監測服務。
二、測試方法
1.本次采用apache的開源測試工具jmeter，采用jmeter代理服務器錄制腳本生成http請求腳本,並通過http協議get方式發送訪問請求,收集服務器響應速度,服務器資源耗用情況。
2、安裝啟動JMeter,分別對以上頁面進行壓力測試分別測試50、100、500、1000個線程，即模擬這些數目的用戶並發; Ramp-up period(inseconds)的值設為1(即1s啟動50、100、500、1000並發訪問),並發持續運行為10分鍾。
3、測試指標提取:
| 測試項 |
並發數 |
線程組增量 |
持續運行時間 |
響應時間 |
成功率 |
CPU使用率 |
內存使用率 |
|
廣告監測服務 |
50 |
每秒增加10個 |
10分鍾 |
≤5分鍾 |
99% |
75%
|
70%
|
| 100 |
每秒增加100個 |
10分鍾 |
≤5分鍾 |
99% |
|||
| 200 |
每秒增加200個 |
10分鍾 |
≤5分鍾 |
99% |
|||
| 500 |
每秒增加500個 |
10分鍾 |
≤5分鍾 |
99% |
|||
| 1000 |
每秒增加1000個 |
10分鍾 |
≤5分鍾 |
99% |
三、測試目標
一台廣告監測服務器極限值
四、測試環境
1.系統環境配置
| 主機用途 |
機型/OS |
台數 |
CPU/台 |
內存容量/台 |
對應IP |
| 應用服務器 |
|
1 |
2 CPU |
4GB |
公網：xxx 內網：xxx |
| 數據庫服務器 |
同上 |
同上 |
同上 |
同上 |
同上 |
2.測試客戶端配置
| 主機用途 |
機型/OS |
台數 |
CPU/台 |
內存容量/台 |
對應IP |
| 壓力負載生成器 |
xxx |
1 |
2 |
8G |
xxx |
3網絡環境
本次測試是在公網中進行的測試,更能模擬用戶操作環境，可以會對壓測造成影響。
4.測試時間
| 壓測環境 |
測試人 |
測試時間 |
| 2CPU 4GB內存 |
xxxxx |
2019年8月14 |
五、系統部署
系統已經經過開發人員部署在xxxxxx這台機子上,無需另外再次進行系統部署。
訪問網址：XXXXX
六、測試說明
名詞定義(時間的單位均為ms):
Samples – 本次場景中一共完成了多少個線程
Average – 平均響應時間
Median----50%請求的響應時間
90%Line----90%請求響應時間
95%Line----95%請求響應時間
99%Line----99%請求的響應時間
Min----最小的響應時間
Max----最大的響應時間
Error%----錯誤率=錯誤的請求的數量/請求的總數
Throughput----吞吐量即表示每秒完成的請求數
Received KB/sec----每秒從服務器端接收到的數據量
Sent KB/sec----每秒從客戶端發送的請求的數量
七、測試統計及分析
壓測場景：
1.輸入URL：xxxxxxx
2.2CPU 4GB內存壓力統計
1)50個線程組並發
聚合報告
並發50個用戶,持續運行10分鍾,完成1426013次訪問請求,最小響應速度為0.004秒,最大為3.688秒,平均響應速度為0.02秒,與預期的快近4秒多,訪問成功率100%,符合預期的需求。
系統資源耗用
從13：22開始壓測,持續運行10分鍾13：32結束，CPU使用率主要維持在45%—85%之間,整體趨勢圖來看與預期的小於75%略顯偏高;內存(Memory)使用率75%左右,與預期小於70%,總體不符合需求。
2)100個線程組並發
聚合報告
並發100個用戶,持續運行10分鍾,完成1418887次訪問請求,最小響應速度為0.004秒,最大為27.009秒,平均響應速度為0.042秒,與預期的快了近4秒多,訪問成功率100%,符合預期的需求。
系統資源耗用
從13：37開始壓測,持續運行10分鍾13：47結束，CPU使用率主要維持在40%—85%之間,整體趨勢圖來看與預期的小於75%略顯偏高;內存(Memory)使用率75%左右,與預期等於70%,總體不符合需求。
3)200個線程組並發
聚合報告
並發200個用戶,持續運行10分鍾,完成1452045次訪問請求,最小響應速度為0.004秒,最大為367.546秒,平均響應速度為0.082秒,與預期的快4秒多,訪問成功率100%,符合預期的需求。
系統資源耗用
從14：32開始壓測,持續運行10分鍾14：42結束，CPU使用率主要維持在65%—85%之間,整體趨勢圖來看與預期的小於75%略顯偏高;內存(Memory)使用率75%左右,與預期70%略顯偏高,總體不符合需求。
4)500個線程組並發
聚合報告
並發500個用戶,持續運行10分鍾,完成1334830次訪問請求,最小響應速度為0.004秒,最大為417.365秒,平均響應速度為0.224秒,與預期的還快4秒,訪問成功率99.99999%,符合預期的需求。
系統資源耗用
從14：48開始壓測,持續運行10分鍾14：58結束，CPU使用率主要維持在63%—87%之間,整體趨勢圖來看與預期的小於75%略顯偏高;內存(Memory)使用率75%左右,與預期70%略顯偏高,總體不符合需求。
5)1000個線程組並發
聚合報告
並發1000個用戶,持續運行10分鍾,完成1289467次訪問請求,最小響應速度為0.004秒,最大為597.21秒,平均響應速度為0.464秒,與預期的還快4秒,訪問成功率99.99998%,符合預期的需求。
系統資源耗用
從15：08開始壓測,持續運行10分鍾15：18結束，CPU使用率主要維持在45%—85%之間,整體趨勢圖來看與預期的小於75%略顯偏高;內存(Memory)使用率75%左右,與預期70%略顯偏高,總體不符合需求。
針對廣告監測動態統計
| 並發線程數 |
#Samples |
Average |
90%Line |
Min |
Max |
Error% |
Throughput |
| 50 |
1426013 |
20 |
11 |
4 |
3688 |
0.00% |
2374.7/sec |
| 100 |
1418887 |
42 |
22 |
4 |
27009 |
0.00% |
2359.4/sec |
| 200 |
1452045 |
82 |
212 |
4 |
367546 |
0.00% |
2416.9/sec |
| 500 |
1334830 |
224 |
625 |
4 |
417365 |
0.01% |
2222.5/sec |
| 1000 |
1289467 |
464 |
1039 |
4 |
597210 |
0.02% |
2144.2/sec |
八、結果
2cpu 4GB內存壓測:
| 測試項 |
並發數 |
線程組增量 |
持續運行時間 |
響應時間(ms) |
成功率 |
CPU使用率 |
內存使用率 |
|
|
50 |
每秒增加50個 |
10分鍾 |
20 |
100% |
45%—85%之 |
75% |
| 100 |
每秒增加100個 |
10分鍾 |
42 |
100% |
40%—85% |
75% |
|
| 200 |
每秒增加200個 |
10分鍾 |
82 |
100% |
65%—85% |
75% |
|
| 500 |
每秒增加500個 |
10分鍾 |
224 |
99.9999% |
63%—87% |
75% |
|
| 1000 |
每秒增加1000個 |
10分鍾 |
464 |
99.9998% |
45%—85% |
75% |
九、結論及建議
1.結論：
2cpu 4GB內存壓測:當壓測開始發現硬件CPU及內存存在不足,並發數增加到了500個,服務器的平均響應速度變得慢,並且開始有數據請求失敗cpu及內存是個瓶頸。
PS：該服務器還有一些其他服務運行這占有一定的CPU及內存對數據結果是存在一定的影響的。所以此數據只能作為參考值來看。
2.建議：
依照目前服務情況達到500將是極限，建議增加CPU及內存或作負載均衡，方可維護服務的穩定，目前硬件配置為2CPU ，4GB內存。