電商網站全鍊路壓測實戰

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.結果測試分析

1. 統計次元：報告的TPS，時延、并發等統計次元均為事務，如事務中有請求多個封包，隻有在多個請求封包均正常傳回會認為成功，時延也是多個請求封包的求和值
2. 響應逾時：出現該情況下是在設定的響應逾時時間内（預設5S），對應的TCP連接配接中沒有響應資料傳回，會将本次事務請求統計為響應逾時，出現原因一般是被測伺服器繁忙、崩潰、網絡帶寬被占滿等
3. 比對失敗：從伺服器傳回的響應封包不符合預期（針對HTTP/HTTPS預設的預期響應碼為200），比如伺服器傳回404,502等。出現原因一般為高并發情況下被測服務無法正常處理導緻的，如果分布式系統中資料庫出現瓶頸、後端應用傳回錯誤等
4. 解析失敗：響應封包已全部接收完成，但是部分封包丢失導緻整個事務響應不完整，這種情況一般需要考慮網絡丢包
5. 帶寬統計：報告統計的是性能測試服務執行端的業務資料包帶寬，上行表示從性能測試服務發出的流量，下線表示接受到的流量。如果是外網壓測場景，您需要關注執行機的EIP帶寬是否可以滿足上行帶寬的要求。而下行帶寬需要關注單台執行機是否超過1GB
6. TPS與并發使用者及時延的關系：TPS是指雲性能測試服務在統計周期内每秒從被測伺服器擷取到的響應事務實時統計，TPS=并發使用者/平均響應時延。是以在測試過程中往往會發現并發使用者增加了但是TPS沒有增加，其原因是由于時延上升了
7. 如何判斷被測應用優劣：根據應用本身定義的服務品質定義，最佳狀态是沒有任何響應失敗、比對失敗的情況，如果有，需要在服務品質定義範圍之内，通常情況下不超過1%，同時響應時延越低越好（2S内體驗較好，5S内可以接受，超過5S則需要考慮優化），TP90，TP99名額可以客觀反映出90%，99%使用者的體驗時延