1 背景
隨著客戶業務發展，目前系統架構已不能滿足業務發展需要，因此急需將服務器託管到阿里雲上，並進行擴容；遷移到阿里雲上以後，系統資源消耗是否比目前線上環境結果要好。因此在上線前需要進行性能測試，測試是否滿足各項性能指標。
2 測試目標
本次測試目標如下：
· 容量測試：核心業務(核心業務1+核心業務2)+非核心業務基線（非核心業務1+非核心業務2+非核心業務3+非核心業務4+非核心業務5+非核心業務6）混合交易容量
· 穩定性測試：混合交易穩定性
· 突變測試：非核心業務突變3倍，對核心業務的影響
· 對比測試：和線上同等壓力下，線上和線下資源消耗和響應時間對比。
· 恢復性測試：模擬網絡攻擊
3 架構
系統架構主要有如下服務器：
· HTTP服務器：核心業務1和核心業務2業務
· TCP服務器：核心業務使用人員終端心跳業務
· MongoDB服務器：非結構化數據庫存儲
· Redis服務器：信息推送
· MySQL服務器：結構化數據庫存儲
4 測試指標
· 容量測試：核心業務1 TPS>=600筆/秒,核心業務2 TPS>=1200筆/秒
· 穩定性測試：至少在核心業務1 TPS等於300筆/秒和核心業務2 TPS等於600筆/秒能穩定運行8小時
· 突變測試：非核心業務突變3倍，基本對核心業務無影響
· 線上線下資源消耗對比測試：在跟線上核心業務1 TPS等於150筆/秒和核心業務2 TPS等於120筆/秒同等壓力下，測試環境的MonogoDB和Redis CPU Load小於0.5%,磁盤利用率小於0.1%
· 線上線下存儲訪問時間對比測試：在核心業務1 TPS等於200筆/秒和核心業務2 TPS等於400筆/秒的情況下，應用觀察到的存儲訪問平均耗時不超過4ms，最大耗時不超過100ms。
· 恢復性測試：系統能恢復，TPS無變化
5 業務模型
5.1 分析
通過生產上高峰業務量分析得出，核心業務1和核心業務2除了雙12外，比例佔比1：1.5左右，通過系統整個趨勢觀察，發現核心業務2業務量有明顯增長趨勢，因此核心業務1和核心業務2的佔比為1：2。高峰時候核心業務總的TPS只有50~200筆／秒。
核心業務量：
非核心業務量：
非核心業務1+非核心業務2+非核心業務3+非核心業務4+非核心業務5+非核心業務6
編號
業務
TPS
佔比
1
非核心業務1
400
16.4%
2
非核心業務2
500
20.5%
3
非核心業務3
833
34.2%
4
非核心業務4
210
8.6%
5
非核心業務5
300
12.3%
6
非核心業務6
190
8%
合計
2433
100%
5.2 模型
5.2.1 模型1
此模型用於容量測試、穩定性測試和恢復性測試。
5.2.2 模型2
此模型用於突變測試。
5.2.3 模型3
此模型用於線上線下資源消耗對比測試。
5.2.4 模型4
此模型用於線上線下存儲訪問時間對比測試
6 腳本設計
經過調研，發送後臺的業務均是URL+自定義Body方式，因此在性能測試裡面，新增一個腳本，上傳參數化文件，定義事務，設置連接和Body就行了，注意儘可能多的進行參數化。
7 測試結果
7.1 容量測試
7.1.1 測試場景
按照模型１，設置用戶數比例和步調時間(保持業務佔比，不偏模型)，運行20分鐘，進行負載測試。
7.1.2 測試
· 第一輪測試
按照核心業務1 1000筆/秒和核心業務2 2000筆/秒目標發起壓力，發現不能達到目標，TPS曲線不穩定，運行到１分鐘的時候，下降非常厲害，抖動也非常厲害，通過監控，發現FULL GC非常頻繁，達到１秒１次，經過與架構師溝通，這是由於實現機制導致的，核心業務1的機制是將內容放到隊列裡面，隊列長度是2147483647,後臺只有64個線程（不能修改）在消化，消費者（消化）處理速度的比生產者（核心業務1）慢，導致隊列長度越來越大，內存很快被消化完了，導致FULL GC頻繁，這屬於架構問題，不能進行修改。
進行修改。
· 第二輪測試
按照核心業務1 600筆/秒和核心業務2 1200筆/秒發起壓力，運行20分鐘，TPS基本保持穩定，通過監控發現，order應用連接MongoDB連接數報已滿的異常錯誤、logserver IO過高、MongoDB locked DB值高於75%。 按照核心業務1 800筆/秒和核心業務2 1600筆/秒目標發起壓力，不能達到此目標，TPS曲線非常不
· 第三輪測試
mongoDB 只有表鎖沒有行鎖，導致locked值非常高，這個是產品問題，沒辦法進行調優。
將order應用MongoDB連接數從250調到1000;logserver 磁盤換成效率更高SSD磁盤；重新按照核心業務1 800筆/秒和核心業務2 1600筆/秒目標發起壓力，運行20分鐘，TPS曲線基本穩定。
20分鐘，TPS曲線基本穩定。
核心業務1：
核心業務2：
7.1.3 測試結論
系統的容量為核心業務1 800筆/秒和核心業務2 1600筆/秒，滿足核心業務1 600筆/秒和核心業務2 1200筆/秒目標要求。
7.2 線上線下資源消耗對比測試
7.2.1 測試場景
按照模型3發起壓力，在核心業務1 150TPS和核心業務2 120TPS壓力情況下，運行20分鐘，資源消耗對比。
7.2.2 測試結果及分析
MongoDB 和 Redis CPU Load均小於0.5, CPU 利用率均小於10%,磁盤利用率均小於0.1%, 這些指標結果比線上資源消耗結果略好。
7.2.3 測試結論
在跟線上同等壓力的情況下，阿里雲環境各項指標結果略好於目前線上環境資源消耗。
7.3 線上線下存儲訪問時間對比測試
7.3.1 測試場景
按照模型４發起壓力，在核心業務1 200筆/秒和核心業務2 400筆/秒的壓力下，運行20分鐘，觀察存儲訪問的時間。
7.3.2 測試結果及分析
在xflush上面觀察到的存儲耗時值小於3ms，最大值不超過100ms
7.3.3 測試結論
滿足目標平均耗時不超過4ms，最大耗時不超過100ms的需求。
7.4 突變測試
7.4.1 測試場景
按照模型２，在核心業務1 TPS 400筆/秒和核心業務2 TPS 800筆/秒的情況下，平穩運行５分鐘後，將非核心業務按照基線的３倍進行突變，運行５分鐘，觀察核心業務TPS曲線的變化，然後將非核心業務恢復到基線，觀察核心業務TPS曲線的變化。
7.4.2 測試結果及分析
核心業務1：
核心業務2：
從圖中可以看出，當非核心業務突變3倍以後，對核心業務1和核心業務2有輕微的影響（核心業務1和核心業務2 TPS下降），但馬上能恢復，突變的整個過程對核心業務基本無影響。
7.4.3 測試結論
非核心業務突變３倍對核心業務基本無影響，滿足目標要求。
7.5 恢復性測試
7.5.1 測試場景
按照模型１，在核心業務1 800筆/秒和核心業務2 1600筆/秒的壓力下，平穩運行５分鐘後，斷開所有mysql服務網絡5秒，觀察核心業務TPS曲線變化，然後恢復mysql網絡，觀察核心業務TPS曲線變化，接著斷開所有MongoDB服務網絡5秒，觀察核心業務TPS曲線變化，然後恢復所有MongoDB服務網絡，觀察核心業務TPS曲線變化。
7.5.2 測試結果及分析
核心業務1：
核心業務2：
從圖中可以看出，斷開MySQL和MongoDB網絡5秒的瞬間，核心業務1和核心業務2的TPS有輕微的下降，隨後能恢復到正常水平，因此對核心業務基本沒有影響。
7.5.3 測試結論
模擬網絡攻擊，對核心業務基本沒有影響，滿足目標要求。
7.6 穩定性測試
7.6.1 測試場景
按照模型1和最大容量的80%左右發起壓力(核心業務1:600筆/秒和核心業務2：1200筆/秒)，運行8小時，觀察系統是否能穩定運行。
7.6.2 測試結果及分析
核心業務1：
核心業務2：
運行到35分鐘後，核心業務1和核心業務2 TPS開始有輕微大幅度波動，運行到45分鐘後，核心業務1和核心業務2 TPS開始大幅度波動，比較頻繁，並且不能恢復到初始水平（過一段時間，TPS逐漸在下降），經過分析發現是FULL GC導致，詳見7.1.2測試結果及分析。 因此將壓力降為一半（核心業務1：300筆/秒，核心業務2：600筆/秒），重新運行穩定性測試。
核心業務1：
核心業務2：
系統在核心業務1 300筆/秒和核心業務2 600筆/秒的壓力下，基本能穩定運行8小時，但隨著時間推移，Full GC次數越來越多，長時間運行下去將會導致系統處理能力大幅度下降（詳見7.1.2測試結果及分析）
7.6.3 測試結論
在核心業務1 300筆/秒和核心業務2 600筆/秒的壓力下，系統基本能穩定運行8小時，滿足目標要求。
8 風險及建議
經過多次分析、調優及測試，基本能滿足各業務場景的目標要求，但系統處理能力不能再繼續上升的瓶頸主要體現在系統架構上，因此隨著未來業務量猛增，超過系統處理能力的時候，將會產生處理能力急需下降、客戶體現差甚至宕機的風險，建議針對系統架構進行修改，並進行架構類性能測試，滿足日益增長的業務需要。
閱讀更多 肥西金 的文章
