1.背景
在電商及互聯網應用時代，用戶和流量已成爲應用核心競爭力，而隨着數字化營銷逐漸走進各個領域，線上的秒殺搶購、熱點營銷等活動也成爲企業的必備營銷手段，營銷帶來的大規模流量浪涌對系統來說是個巨大的考驗，如何應對用戶和流量激增的同時又能保障應用的穩定運行已成爲各廠家必須解決的問題。本文將分享如何測試和分析電商類網站的性能瓶頸
2.測試工具選型
本次選擇測試工具是華爲雲的雲性能測試服務
不採用開源和傳統測試工具的原因是：
- 測試周期：壓測環境搭建維護複雜，耗費的時間長。
- 使用門檻：Jmeter的學習成本還比較高，當企業出現人員交接的時候需要無法快速找到替代人員。
- 經濟成本：專業性能測試工具license採購成本在上百萬人民幣，而當前華爲雲性能測試服務還屬於免費階段。
- 彈性按需：根據服務器吞吐量，資源按需擴容，提升資源利用率。
3.瞭解監控指標
- 併發用戶數：在性能測試工具中，併發用戶數一般被稱爲虛擬用戶數。
- TPS：每秒成功完成的業務請求數量，是衡量系統性能的一個非常重要的指標，反映系統處理能力，越大越好。
- 不同行業不同業務可接受的TPS也是不一樣的。一般互聯網電子商務爲10000TPS-100000TPS；互聯網小型網站50TPS-100TPS；互聯網中型網站100TPS-1000TPS。
- 平均響應時間：用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回的響應結束，整個過程所耗費的時間，反映系統處理能力。不同行業不同業務可接受的響應時間是不同的。一般情況下，互聯網企業在500毫秒以下；金融企業1秒以下爲佳；保險企業3秒以下爲佳。
- CPU：查看性能測試的過程中CPU資源的佔用率，反映系統處理能力以及應用是否穩定。
- I/O： 磁盤的使用情況，度量磁盤讀寫性能
- 內存：查看內存使用情況
4.前提條件
壓測資源需提前準備好：已在雲容器引擎服務中創建兩臺節點，一臺2核4G，一臺4核8G，這兩臺節點需要綁定彈性IP，以確保和被壓測的應用網絡互通。
5.測試目的
本次性能測試主要檢測服務端處理能力，通過測試，將達到以下目的：
- 爲上線提供指標參考:驗證在現有軟硬件環境情況下，獲取網站性能指標，爲系統上線提供指標參考。
- 系統的最大處理能力:在現有的軟硬件環境情況下，網站能夠支撐的最大處理能力。
6.測試建模
根據顧客的使用電商應用的行爲數據分析，爲找出現有網站能夠支撐的最大處理能力。構建出3種測試模型，分別是單場景基準測試模型、單場景容量測試模型和混合場景容量測試模型。
單場景基準測試模型：測試環境確認之後，對測試模型中涉及的每個功能做基準測試。目的是檢查網站本身是否存在功能缺陷。
單場景容量測試模型：針對本次網站性能測試涉及到的網站內容和用戶行爲軌跡，利用一定量的併發進行測試，獲取其性能表現，並驗證是否存在併發性問題。
混合場景容量測試模型：針對本次平臺性能測試涉及到的“內容/行爲軌跡/搜索”利用一定量的併發遞增進行測試，驗證實際可能的高壓力場景，較全面的檢測系統的性能表現。獲取其最大併發數、平均響應時間、系統資源作爲衡量指標
單場景基準測試模型：
單場景容量測試模型：
根據現網的監控數據，按照訪問量的比例，構建混合場景容量測試模型：
性能標準參考：
7.測試執行
步驟一：創建資源組和測試工程
工程名稱：自定義名稱，例如Web-test。
描述：應用測試Demo。
步驟二：添加事務信息
根據上面的測試模型進行事務的定義，搶購活動的實際情況來看，用戶搶購到商品，大概需要經歷一下幾個階段：登陸>首頁訪問 > 搜索 > 商品瀏覽>加入購物車>下單>付款。期間還有網站對應的活動頁面。
因此需要定義7個事務：登陸>首頁訪問 > 搜索 > 商品瀏覽>加入購物車>下單>付款。
也可以根據需要構建串聯場景，驗證用戶操作鏈的性能
步驟三：創建測試任務
華爲雲性能測試服務測試針對測試任務關聯多個事務，併爲事務分配不同的壓力比例，以我當前測試的電商網站爲例，單場景測試採用階梯式壓測模型（可以是遞增的，也可以無規律的）快速找到壓力瓶頸點：
而對於混合測試模型，則在混合測試任務下關聯所有事務，並分配不同的比例：
步驟四：查看實時報告
任務啓動後查看實時報告
首頁訪問，100併發用戶數持續時間100s，可以看到在100併發時，都是正常返回。
當300併發用戶數持續時間100s，已經出現了部分響應超時的現象。說明網站當前還無法支持300個併發訪問用戶的正常請求。當用戶數達到500併發用戶數持續時間100s，響應超時的數量高於正常返回的數量，出現異常。
查看對應的資源佔用情況，CPU使用率，在性能測試的過程中，CPU的使用率長期超過90%，與業界標準比較，CPU的使用率超過了85%。內存使用率在12%以下，比較穩定。查看後端其中一個數據庫節點的資源，資源的使用率較低，相較於前端，可得出性能瓶頸主要在前端的業務代碼中。
然後根據定位情況進行優化後反覆測試調優就行了。
步驟五：查看離線報告
也可以在無人值守的情況下完成測試後查看離線報告，內容與實時報告一致。
8.結果測試分析
- 統計維度：報告的TPS，時延、併發等統計維度均爲事務，如事務中有請求多個報文，只有在多個請求報文均正常返回會認爲成功，時延也是多個請求報文的求和值
- 響應超時：出現該情況下是在設置的響應超時時間內（默認5S），對應的TCP連接中沒有響應數據返回，會將本次事務請求統計爲響應超時，出現原因一般是被測服務器繁忙、崩潰、網絡帶寬被佔滿等
- 比對失敗：從服務器返回的響應報文不符合預期（針對HTTP/HTTPS默認的預期響應碼爲200），比如服務器返回404,502等。出現原因一般爲高併發情況下被測服務無法正常處理導致的，如果分佈式系統中數據庫出現瓶頸、後端應用返回錯誤等
- 解析失敗：響應報文已全部接收完成，但是部分報文丟失導致整個事務響應不完整，這種情況一般需要考慮網絡丟包
- 帶寬統計：報告統計的是性能測試服務執行端的業務數據包帶寬，上行表示從性能測試服務發出的流量，下線表示接受到的流量。如果是外網壓測場景，您需要關注執行機的EIP帶寬是否可以滿足上行帶寬的要求。而下行帶寬需要關注單臺執行機是否超過1GB
- TPS與併發用戶及時延的關係：TPS是指雲性能測試服務在統計週期內每秒從被測服務器獲取到的響應事務實時統計，TPS=併發用戶/平均響應時延。因此在測試過程中往往會發現併發用戶增加了但是TPS沒有增加，其原因是由於時延上升了
- 如何判斷被測應用優劣：根據應用本身定義的服務質量定義，最佳狀態是沒有任何響應失敗、比對失敗的情況，如果有，需要在服務質量定義範圍之內，通常情況下不超過1%，同時響應時延越低越好（2S內體驗較好，5S內可以接受，超過5S則需要考慮優化），TP90，TP99指標可以客觀反映出90%，99%用戶的體驗時延