通過澤眾
性能測試工具PerformanceRunner（簡稱PR）進行性能測試，驗證APP端500用戶并發平均響應時間5s之內是否通過，測試樣品為某在線看房平臺，各個場景APP端測試執行情況如下：
1.外網測試APP端登錄模塊逐步加壓方式執行情況：
|
并發用戶數
|
執行時間（分鐘）
|
平均響應時間（秒）
|
每秒事務數
|
通過事務數
|
失敗事務數
|
CPU占用率
|
內存使用率
|
網絡流量（上傳與下載）
|
|
113
|
123
|
113
|
123
|
|
20
|
10
|
4.85
|
3.73
|
2254
|
0
|
2%
|
1.3%
|
11%
|
12.5%
|
12Mb/s
|
|
30
|
10
|
7.07
|
3.76
|
2269
|
1
|
2%
|
1.5%
|
12%
|
12.7%
|
12Mb/s
|
|
40
|
10
|
9.69
|
3.77
|
2270
|
1
|
1.9%
|
1.3%
|
10.3%
|
12.3%
|
12Mb/s
|
|
50
|
6
|
12.12
|
3.75
|
1364
|
0
|
2%
|
1.4%
|
10.2%
|
12.4%
|
12Mb/s
|
此次執行是以20并發為起點，逐步加壓每次按10并發遞增，30并發時平均響應時間已超過5s,分別在40并發和50并發做了驗證，平均響應時間皆超過5s，認定500用戶并發平均響應時間5s之內該場景不通過。
舉例40用戶并發執行：
1）響應時間；
2）每秒事務數；
3）CPU占用率；
4）內存使用情況；
5）網絡流量；
6）登錄模塊測試總結：在外網環境下，登錄模塊測試過程中兩臺服務器的平均CPU占用率均未達到3%，說明服務器資源消耗很低；但是40用戶并發時，其響應時間已經非常接近10s，在50用戶并發時，其響應時間已達到12s，超過了10s，其網絡流量（包括上傳與下載）速率均在13000000Bytes/s左右，換算后約為12Mb/s，說明網絡帶寬對系統性能產生了影響。
2.APP端加載首頁模塊逐步加壓方式執行情況：
|
并發用戶數
|
執行時間（分鐘）
|
平均響應時間（秒）
|
每秒事務數
|
通過事務數
|
失敗事務數
|
CPU占用率
|
內存使用率
|
網絡流量（上傳與下載）
|
|
113
|
123
|
113
|
123
|
|
15
|
10
|
4.90
|
2.85
|
1701
|
1
|
51.4%
|
1.4%
|
11.5%
|
12.3%
|
12Mb/s
|
|
20
|
10
|
5.63
|
3.38
|
2028
|
0
|
43.4%
|
2.0%
|
11.1%
|
12.4%
|
12Mb/s
|
加載首頁模塊測試總結：外網環境下，加載首頁模塊兩臺服務器的平均CPU占用率達到了50%，這是由于每個請求都需要加載很多靜態資源（如：圖片）造成的。
3.APP端刷新實時獲取房屋狀態模塊逐步加壓方式執行情況：
|
并發用戶數
|
執行時間（分鐘）
|
平均響應時間（秒）
|
每秒事務數
|
通過事務數
|
失敗事務數
|
CPU占用率
|
內存使用率
|
網絡流量（上傳與下載）
|
|
113
|
123
|
113
|
123
|
|
30
|
4
|
0.097
|
54
|
12905
|
0
|
55.8%
|
30.1%
|
12.0%
|
11.6%
|
12Mb/s
|
|
500
|
10
|
0.78
|
52
|
26081
|
84
|
54.2%
|
27.8%
|
12.3%
|
11.4%
|
12Mb/s
|
刷新獲取房屋狀態測試總結：該模塊的并發用戶數為30時其平均響應時間約為0.1s，遠遠超過了客戶要求的5s，隨后將并發用戶數增加到500，其平均響應時間達到0.78s，但是查看服務器監控數據發現30并發用戶與500并發用戶的CPU占用率相差不大。
4.APP端查看房屋詳情模塊逐步加壓方式執行情況：
|
并發用戶數
|
執行時間（分鐘）
|
平均響應時間（秒）
|
每秒事務數
|
通過事務數
|
失敗事務數
|
CPU占用率
|
內存使用率
|
網絡流量（上傳與下載）
|
|
113
|
123
|
113
|
123
|
|
30
|
3D
|
10
|
3.01
|
0.69
|
423
|
0
|
2.7%
|
2.4%
|
17.0%
|
19.1%
|
12Mb/s
|
|
VR
|
0.704
|
0.72
|
423
|
0
|
|
50
|
3D
|
10
|
4.0
|
0.69
|
433
|
1
|
2.3%
|
2.0%
|
13.0%
|
16.0%
|
12Mb/s
|
|
VR
|
0.97
|
0.70
|
433
|
0
|
|
55
|
3D
|
10
|
5.07
|
0.67
|
436
|
0
|
2.3%
|
1.7%
|
10.2%
|
12.5%
|
12Mb/s
|
|
VR
|
1.17
|
0.68
|
436
|
0
|
|
60
|
3D
|
10
|
5.20
|
0.69
|
425
|
0
|
2.4%
|
1.8%
|
10.3%
|
12.5%
|
12Mb/s
|
查看房屋模塊測試總結：此模塊主要是加載房屋模型（3D模型與VR模型，包含大量圖片），通過以上圖表數據可以得出，并發用戶數為55時其平均響應時間為5.02s，非常接近客戶需求（5s），但其CPU占用率未達到3%，這說明服務器資源消耗低，但此時網絡流量已達到12Mb/s；
所以，性能測試工具PerformanceRunner（簡稱PR）驗證某在線看房平臺APP端500用戶并發平均響應時間是否在5s之內，最終結果是不通過，下面是全盤總結和優化建議。
全盤總結：在本次性能測試過程中，不滿足測試內容要求的性能指標的只有APP中加載首頁一個模塊，其原因可能在于：首頁中需要加載一個VR模型，組成此模型的圖片資源太多，當高并發頻繁請求資源時則會造成等待時間較長，則其響應時間也會比較長。
優化建議：
從測試結果得出，在請求方網絡為聯通80M寬帶，服務器網絡為電信50M寬帶的情況下，滿足客戶需求的各模塊并發用戶數為：登錄（40并發用戶）、加載首頁（15并發用戶）、刷新獲取房屋狀態（500并發用戶）、查看房屋詳情（55并發用戶）。在測試過程中還發現，在服務器的CPU占用率與內存使用率較低（60%以下）的情況下，每一個模塊的測試結果中網絡流量的使用都達到了服務器帶寬的上限，而這也導致了很低的并發用戶數的平均響應時間就達到了客戶需求；所以，當前服務器帶寬嚴重制約了其性能，建議增加帶寬。
在本次測試進行中，也遇到了如下問題：腳本開始執行后，兩臺應用服務器只啟動了一臺，另一臺應用服務器的CPU占用率一直為0%，這說明負載均衡未起作用；原因分析：造成此問題的原因可能是nginx配置存在問題，導致nginx未輪詢分發請求到兩臺應用服務器上；建議修改nginx配置文件，已確認現在nginx能輪詢分發請求到兩臺應用服務器上。
根據本次檢測的結果與測試通過標準的比對，判定本次該樣本性能測試不通過。
相關閱讀：
sales@spasvo.com
