性能測試報告
1 概述
1.1性能測試概念
性能測試是通過自動化的測試工具模擬多種正常峰值及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試確定在各種工作負載下系統的性能，目標是當負載逐漸增加時，測試系統的各項性能指標的變化情況。壓力測試是通過一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。
1.2性能測試目的
性能測試的目的是驗證軟件系統是否能夠達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，以優化軟件，最后起到優化系統的目的。
1.3性能測試目標
從安全，可靠，穩定的角度出發，找出性能缺陷，並且找出系統最佳承受並發用戶數，以及並發用戶數下長時間運行的負載情況，如並發100用戶，如何對系統進行調優
性能測試主要包括一下幾個方面：
（1）評估系統的能力：測試中得到的負荷和響應時長數據可以被用於驗證所計划的模型的能力，並幫助做出決策。
（2）識別體系中的弱點：受控的負荷可以被增加到一個極端的水平並突破它，從而修復體系的瓶頸或薄弱的地方。
（3）系統調優：重復運行測試，驗證調整系統的活動是否得到了預期的結果，從而改進性能。
（4）檢測軟件中的問題：長時間的測試執行可導致程序發生由於內存泄漏引起的失敗，揭示程序中隱含的問題或沖突。
（5）驗證穩定性、可靠性：在一個生產負荷下執行測試一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法。
1.4性能測試的常見分類
（1）負載測試：負載測試是指通過測試系統在資源超負荷情況下的表現，來發現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作條件下的性能行為，以及持續正常運行的能力。負載測試的目的是確定並確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，如響應時長、事務處理速率和其他與時間相關的性能指標。
（2）壓力測試：在軟件工程中，壓力測試是對系統不斷施加壓力的測試，是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。例如測試一個web站點在大量的負荷下，何時系統的響應會退化或失敗。
（3）容量測試：容量測試確定系統可處理同時在線的最大用戶數。
2 系統簡介
2.1參考資料
性能相關的測試資料
2.2要做的測試
壓力測試
基准測試
2.3測試環境
（1）硬件環境
（2）軟件環境
3 測試指標
測試時間：2018年10月10日～10月11日
測試范圍：客戶端請求信息時，服務器各項性能指標的性能測試
3.1 Jmeter指標
(由於Apache旗下性能測試工具jmeter收集的性能指標偏少，下面的數據選取代表性指標)
（1）Averge/ms:服務器處理事務平均響應時間（表示客戶端請求到服務器處理信息且反饋客戶端的時間）
響應時間=呈現時間+網絡傳輸時間+服務器端響應時間+應用延時時間
在互聯網上對於用戶響應時間，有一個普遍的標准。2/5/10秒原則。
也就是說，在2秒之內給客戶響應被用戶認為是“非常有吸引力”的用戶體驗。在5秒之內響應客戶被認為“比較不錯”的用戶體驗，在10秒內給用戶響應被認為“糟糕”的用戶體驗。如果超過10秒還沒有得到響應，那么大多用戶會認為這次請求是失敗的。
（2）Throughput/s:服務器每秒處理請求數（表示服務器每秒處理客戶端請求數（單位：個/秒））
（3）Error%：采樣發生錯誤的比率
（4）KB/s：服務器每秒接收到的數據流量（表示服務器每秒接收到客戶端請求的數據量KB表示）
3.2 硬件指標
（1）%Processor time：CPU使用率（平均低於75%，低於50%更佳）
（2）System：Processor Queue Length：CPU隊列中的線程數（每個處理器平均低於2）
（3）Mermory:Page/sec：內存錯誤頁數（平均低於20，低於15更佳）
（4）Physical Disk-%Disk time：磁盤使用率（平均低於50%）
4 測試工具和測試策略
測試工具：Apache-jmeter
測試策略: 根據公司內部實際情況，以及業務分布設置數據庫訪問量即並發用戶數
測試數據: 注冊用戶、店鋪數據、商品數據
數據說明：選取數據均為代表性數據
測試場景：1）、訪問機場東大廳、西大廳店鋪、以及店鋪商品
2）、業務全鏈路測試：注冊、登錄、添加信用卡，提交訂單、支付
3）、訂單查詢
5 測試結果數據以及截圖
前提條件：假定用戶數為50個用戶數時，並發訪問后台
5.1 Jmeter 性能指標
5.1.1 店鋪訪問測試結果及分析
總體測試情況：
| 指標 |
測試值 |
| 壓測時長 |
20分10秒 |
| 並發數 |
100個線程（等價100個虛擬用戶） |
| 平均響應時間 |
10556毫秒 |
| 最大響應時間 |
41595毫秒 |
| 吞吐量 |
7.3/sec |
| 容錯率 |
0.01% |
各項測試詳情：
1.Average/ms
數據分析：
本圖表示服務器處理請求的平均相應時間
最佳性能是隨着並發用戶數的增加，平均事務相應時間比較平緩
本圖清晰的可以看到，隨着並發用戶數的增加事務響應也隨着上升
2.Throughput/s
數據分析：本圖表示服務器每秒處理請求個數
最佳性能服務器處理請求數是隨着用戶的增加而增加
本圖可以直觀看到服務器處理請求數的個數並未隨着用戶的增加而增加
3.請求總數與用戶圖數
數據分析:
平均響應時間超出預期，當並發超過60個用戶時，達到用戶體驗糟糕的情況
5.1.2 提交訂單和支付測試結果及分析
總體測試情況：
| 指標 |
測試值 |
| 壓測時長 |
19分17秒 |
| 並發數 |
30個線程（等價30個虛擬用戶，實際訂單和支付的並發只有20） |
| 平均響應時間 |
15673毫秒（invoice+pay） |
| 最大響應時間 |
27040毫秒（invoice+pay） |
| 吞吐量 |
2.2/sec（invoice+pay） |
| 容錯率 |
1.62%（invoice+pay） |
各項測試詳情：
1.Average/ms
數據分析：
本圖表示服務器處理請求的平均相應時間
最佳性能是隨着並發用戶數的增加，平均事務相應時間比較平緩
本圖清晰的可以看到，隨着並發用戶數的增加事務響應也隨着上升
2.Throughput/s
數據分析：本圖表示服務器每秒處理請求個數
最佳性能服務器處理請求數是隨着用戶的增加而增加
本圖可以直觀看到服務器處理請求數的個數隨着用戶的增加而增加
3.請求總數與用戶圖數
pay接口錯誤返回：{"code":"102","message":"Reject by processor: Error 1062: Duplicate entry '1000-153924520194' for key 'acq'"}
5.1.3 查看訂單測試結果及分析
總體測試情況：
| 指標 |
測試值 |
| 壓測時長 |
15分19秒 |
| 並發數 |
50個線程 |
| 平均響應時間 |
9467毫秒 |
| 最大響應時間 |
30073毫秒 |
| 吞吐量 |
3.9/sec |
| 容錯率 |
0.03% |
各項測試詳情：
1.Average/ms
數據分析：
本圖表示服務器處理請求的平均相應時間
最佳性能是隨着並發用戶數的增加，平均事務相應時間比較平緩
本圖清晰的可以看到，隨着並發用戶數的增加事務響應也隨着上升
2.Throughput/s
數據分析：本圖表示服務器每秒處理請求個數
最佳性能服務器處理請求數是隨着用戶的增加而增加
本圖可以直觀看到服務器處理請求數的個數並未隨着用戶的增加而增加
3.請求總數與用戶圖數
5.2 硬件指標
觀測后台兩台主要的服務器，CPU使用率大部分時候介於50%～65%，高峰時達到70%到85%，最高峰是達到92.2%。
6 測試結論
6.1 Jmeter性能指標分析
由Jmeter性能指標最直觀的可以看出網絡性能的不足，客觀的反映出服務器處理能力存在優化空間
1、店鋪訪問測試，主要是模擬用戶未登錄情況訪問機場店鋪的場景。模擬100個用戶同一時間不間斷查詢店鋪信息，在負載測試情況下，響應時間過長。
2、訂單提交和支付測試，主要是模擬20個用戶並發同時下單場景，吞吐量均為1.1/sec，相對於后台的invoice和pay這兩個接口都是1秒只能處理一個請求。需要評估是否有優化的空間
3、查詢訂單接口測試，主要模擬客戶端2秒請求一次訂單接口的場景。響應時間也過長，這樣會在訂單狀態變化中，如果不停請求，可能會出現新舊狀態不停切換的情況，所以響應時間會跟不上2秒請求一次的時間間隔，頻率是否可做調整。
優化建議：待定
6.2 服務器硬件信息監控數據分析
結合Jmeter性能指標和多個硬件監控圖
優化建議：無