1.背景
在電商及互聯網應用時代，用戶和流量已成爲應用核心競爭力，而隨着數字化營銷逐漸走進各個領域，線上的秒殺搶購、熱點營銷等活動也成爲企業的必備營銷手段，營銷帶來的大規模流量浪涌對系統來講是個巨大的考驗，如何應對用戶和流量激增的同時又能保障應用的穩定運行已成爲各廠家必須解決的問題。本文將分享如何測試和分析電商類網站的性能瓶頸html
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%用戶的體驗時延