705      魔獸

某移動APP性能優化__最佳實踐_性能測試-阿裏雲

訪問性能測試控製台

  移動APP項目實施案例分析及調優

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

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頻繁，這屬於架構問題，不能進行修改。

  核心業務2：

• 第二輪測試
    按照核心業務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曲線基本穩定。

  核心業務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 風險及建議

  經過多次分析、調優及測試，基本能滿足各業務場景的目標要求，但係統處理能力不能再繼續上升的瓶頸主要體現在係統架構上，因此隨著未來業務量勐增，超過係統處理能力的時候，將會產生處理能力急需下降、客戶體現差甚至宕機的風險，建議針對係統架構進行修改，並進行架構類性能測試，滿足日益增長的業務需要。

訪問性能測試控製台

最後更新：2016-05-06 10:44:38

  上一篇： 大規模分布式壓測__最佳實踐_性能測試-阿裏雲

  下一篇： 錄製工具使用指南__腳本錄製調試指南_性能測試-阿裏雲