性能測試報告
Performance Test Report
| 項目 |
XXX項目二期 |
| 版本 |
V1.00 |
| 作者 |
dayu |
| 日期 |
2019.9.31 |
1. 測試概述
1.1 測試目標
描述本次測試的意義和目標
本次測試的目的在於探查XXX項目二期重構環境的系統業務處理性能，以及在高負載情況下的系統表現。
1.2 指標和術語
描述本次測試中涉及到的性能指標術語
| 術語 |
釋義 |
| 並發數 |
測試時同時系統發出事務請求的數量，並發線程數用以模擬同時與系統建立連接的用戶。 |
| TPS（每秒事務數） |
在每秒時間內系統可處理完畢的事務數。TPS很大程度體現系統性能能力。 |
| 錯誤率 |
經系統處理的事務出現錯誤的概率，對應着實際用戶使用系統功能失敗的情況。理想情況下錯誤率應保持極低水平。 |
| 資源占用率 |
服務器端各關鍵資源的使用比例，用於衡量系統硬件能力 |
2. 環境、工具
列出本次測試所涉服務器、客戶機和測試工具
2.1 測試環境
服務器：
| 應用 |
機器 |
CPU、內存配置 |
| API |
ip地址 |
16核CPU、內存16G |
| MYSQL |
ip地址 |
16核CPU、內存16G |
客戶機：
| 操作系統 |
CPU |
內存 |
| Windows10 專業版 |
I3- 4170 3.70GHZ |
8G |
2.2 測試工具
| 核心工具 |
版本 |
備注 |
| Jmeter |
3.3 |
提供並發請求能力 |
| PerfMon Metrics Collector |
2.1 |
Jmeter插件，用於收集服務器資源使用信息 |
| ServerAgent |
2.2.1 |
以伺服形式發送服務器資源使用信息 |
| nMon |
16h v2 |
實時收集服務器資源信息 |
3. 測試方案
3.1 測試類型
不同的性能測試場景可能使用不同的測試類型，需要明確
本次性能測試將主要采用以下幾種測試類型：
l 基准測試：
在小並發條件下，探測系統各性能指標表現，作為后續比對基礎。
l 壓力測試：
由於無法准確預估用戶訪問量，因此考慮使用壓力測試方法。壓力測試旨在通過不斷 增加系統並發處理事務數，增加系統負載，直到系統到達性能瓶頸。以此推算出系統 可承載用戶和事務請求數。
l 穩定性測試：
將系統置於較長時間高負載場景下，探測系統是否出現穩定性缺陷。
3.2 業務模型
針對系統接口，究竟哪些需要被納入壓測范疇？不同事務應該以何種比例被調用，這是需要建模設計的，也是性能測試的難點之一。
通過對於項目架構和業務場景分析，設計以下業務模型進行模擬和測試：
場景1：簡單業務場景
| 業務名稱 |
接口地址 |
請求類型 |
並發比例 |
| 登錄 |
/login |
post |
1 |
| 查詢用戶信息 |
/queryMemberInfo |
get |
1 |
場景2：混合業務場景
| 業務名稱 |
接口地址 |
請求類型 |
並發比例 |
| 登錄 |
/login |
post |
1 |
| 查詢用戶信息 |
/queryMemberInfo |
get |
1 |
| 交易查詢 |
/listOrderPage |
get |
1 |
| 訂單創建 |
/createOrder |
post |
1 |
3.3 加密驗簽處理
由於系統對於所有事務請求都進行了加密驗簽處理，因此在本次性能測試中，需要對請求報文進行一致的加密和簽名。處理邏輯如下：
l 使用APP同樣的加密簽名代碼，導出jar包做為加密工具類
l 使用jmeter前置處理器-beanshell處理器調用上述jar包方法實現請求參數加密
l 將加密簽名后的請求參數存儲為變量，后續接口調用時使用
3.4 壓力梯度
對於3.2所述場景，分別進行梯度加壓，從100並發開始，每次遞增100並發數，直至到達系統瓶頸。
4. 測試結果
4.1 聚合報告
| 標簽 |
樣本數 |
平均（響應時間ms） |
最小 |
最大 |
錯誤率 |
吞吐量（/s） |
| 登錄 |
50 |
28 |
20 |
38 |
0.00% |
4.5977 |
| 查詢member信息 |
50 |
1602 |
1292 |
2042 |
0.00% |
4.07133 |
| 查看交易 |
50 |
705 |
512 |
920 |
0.00% |
4.37828 |
| 創建訂單 |
50 |
86 |
60 |
119 |
0.00% |
4.55083 |
| 總體 |
200 |
605 |
20 |
2042 |
0.00% |
15.11716 |
場景1-10並發-循環5次
| 標簽 |
樣本數 |
平均（響應時間ms） |
最小 |
最小 |
錯誤率 |
吞吐量（/s） |
| 登錄 |
500 |
7612 |
40 |
26725 |
0.00% |
15.84987 |
| 查詢用戶信息 |
500 |
30871 |
2369 |
49719 |
0.00% |
6.96233 |
| 總體 |
1000 |
19241 |
40 |
49719 |
0.00% |
13.91517 |
場景1-500並發-循環1次
| 標簽 |
樣本數 |
平均（響應時間ms） |
最小 |
最大 |
錯誤率 |
吞吐量（/s） |
| 登錄 |
550 |
8326 |
33 |
22360 |
0.00% |
20.34851 |
| 查詢用戶信息 |
550 |
36071 |
4362 |
58485 |
0.36% |
6.7585 |
| 總體 |
1100 |
22199 |
33 |
58485 |
0.18% |
13.51069 |
場景1-550並發-循環1次
| 標簽 |
樣本數 |
平均（響應時間ms） |
最小 |
最大 |
錯誤率 |
吞吐量（/s） |
| 登錄 |
4500 |
12408 |
87 |
46269 |
0.00% |
4.68807 |
| 查詢用戶信息 |
4500 |
35383 |
3792 |
65036 |
0.00% |
4.63027 |
| 查看交易 |
4500 |
22832 |
711 |
46812 |
0.02% |
4.64518 |
| 創建訂單 |
4500 |
24973 |
81 |
58698 |
0.13% |
4.67591 |
| 總體 |
18000 |
23899 |
81 |
65036 |
0.04% |
18.50308 |
場景2-450並發-循環10次
4.2 系統吞吐量
場景1-550並發-循環1次
場景2-450並發-循環10次
4.3 資源占用率
最優負載條件下：
CPU使用率
內存占用率
磁盤使用率
5. 分析和建議
結合收集到的數據，給出對於系統性能關鍵點的分析
5.1 測試結論分析
經過多次測試和數據報表分析，可以得出如下結論：
1) 當總體並發用戶數為450-500時，系統具有最優性能表現；當事務並發數超過500時，事務失敗率整體上升，系統到達性能拐點。
2) 多事務混合條件下，系統巔峰TPS在90左右，平均吞吐量在13-18/s。
3) 在小壓力條件下（10並發），最大事務響應時間為查詢用戶信息事務的2042毫秒，平均在600毫秒左右系統。整體事務微觀響應速度較優。
4) 滿負載條件下，登錄具有最佳的性能表現，平均響應時間為7000-12000毫秒；查詢用戶信息事務性能較差，平均響應時間在30000-40000區間。滿負載條件下系統整體微觀響應時間較差。查詢用戶接口由於其使用極為頻繁，建議進行SQL效率調優
5) 系統資源方面，內存占用率始終處於高位水平（90%以上），磁盤空間由於日志寫入而不斷被占用。
5.2 問題
測試過程中發現了如下顯著問題：
1) 加密驗簽功能並未生效-現階段任何簽名均可通過驗簽。屬於功能性問題，不影響性能表現。
2) 日志文件由於不斷寫入導致磁盤占滿，建議調低系統日志級別，並做好定期日志備份。
3) 內存占用處於高位水平，需要進一步探查原因。