如何作雲端壓力測試和業務容量的測試與規劃

高速增加的互聯網業務要求產品開發、迭代和交付週期愈來愈短，而IT基礎設施的普遍雲化和第三方API接口的大量使用，使傳統的基於內部環境搭建的壓力測試方法和測試工具愈來愈難以知足應用功能可用和容量規劃預估的需求。

企業該如何爲頻繁的市場活動和產品快速迭代進行有效而準確的壓力測試呢？但願經過雲端壓力測試專家，雲智慧壓測寶產品總監陸興海分享的兩個客戶案例，爲企業的雲端壓力測試和業務容量規劃帶來一些有價值的參考。

壓測寶雲壓測客戶案例1：壓測寶如何作業務容量的測試與規劃？

雲智慧有個作旅遊和攝影服務平臺的客戶要舉辦一次活動，爲本次活動製做了專門的活動頁面，在活動頁面用戶能夠報名。那麼在短期內系統到底能撐得住多大的用戶併發？

 

這是活動運營和技術部門必須提早考慮的問題，由於在去年舉辦相似活動時就出現了用戶大量涌入致使服務不可用的情況，因此首先要幫助用戶整理容量測試和規劃的工做思路。

具體該如何實施壓測呢，這裏劃分了幾個環節：

［1］場景肯定與壓測腳本準備

用戶在註冊時須要提交用戶的姓名、手機號和手機驗證碼，以後提交申請便可，因此實際上用戶申請註冊只調用了一個API接口來完成，這是一個比較簡單的場景。

一、 由於涉及到手機驗證場景，在不提供對應API的狀況下，建議用戶使用萬能的驗證碼或者暫時取消驗證碼；

二、 是否容許多個手機號同時註冊，若是容許咱們可用使用固定參數傳遞，若是不容許，咱們可準備對應手機號的測試數據來應對；

三、 短期內發起大量併發，用戶自己是否有安全擋板，若是有，須要把施壓節點的IP加入白名單；

［2］施壓模式

既然是容量探測，因此總體的施壓過程是一個梯度漸進的過程，通常不會上來就是一條直線。這是一直和用戶強調的問題，壓測的目的絕對不是把系統壓垮，壓測的目的是經過不斷增長的併發來客觀評估系統在不一樣的壓力條件下的性能情況；基於此咱們定製了施壓的梯度壓力模式，如圖所示：

 

 

［3］壓測點分佈

傳統壓力測試工具主要在內網產生壓力，壓力的規模受限於物理機器及License數量，形成準備週期長及成本高等問題。而云壓測提供可靠的分佈式壓測服務器（壓測點），充分利用雲端的計算資源，從而突破了這個限制。

目前雲智慧的壓測點來自雲服務的雲主機（AWS、Ucloud和阿里雲等）以及雲智慧部署在全國各大IDC核心機房的服務器，目前主要提供的區域以下圖所示：

 

 

 

［4］壓測時間設定

根據系統訪問狀況，通常會建議用戶在凌晨進行壓測，此時可以保證對用戶的影響最小，也能保證正經常使用戶訪問對壓測結果的干擾最小。但這個壓測時間設定不是絕對的，須要與具體用戶的業務場景結合判斷。

［5］壓測數據分析

在基本的參數肯定以後，就可用根據預約的時間來執行壓測任務了，雲壓測可以進行秒級的數據採集和實時統計分析，可以隨時調整壓力。隨着壓力的逐步上升，可以動態呈現系統的性能數據。在逐步加壓的過程當中，若是性能急劇降低或大量出錯，就沒有必要繼續執行壓測任務，此時能夠終止任務，也能夠下調壓力，確保對整個壓測過程的把控。

針對這個用戶，按照上述步驟實施壓力測試以後，經過相關測試結果的數據分析和評估，獲得了壓測結論以下：

被壓測的註冊接口在360併發用戶如下時表現相對良好，在併發用戶達到360至500時性能欠佳，說的更直接一點就是：該系統可以支撐360的併發，具體論證以下：

一、 併發達到360以後失敗明顯增多而且持續到任務結束；

二、 併發達到420以後，響應時間超出3000ms標準值且持續到最後；

三、 每秒鐘事務數（TPS）穩定在130左右，表現比較良好；

本次壓測的概要數據以下圖所示：

 

壓力測試綜合報表以下圖所示，當併發用戶數達到360時，系統開始出現了大面積失敗（280時出現了1次錯誤），而且失敗問題持續到壓測結束都沒有改善，不過整個測試過程當中並無出現斷言不匹配的狀況，即正確性保持良好。

 

事務響應時間趨勢：隨着應用訪問用戶量增長，在併發用戶達到420的時候，系統事務處理的時間也顯著上升（大於參考標準3000ms），且響應時間在之後一直沒有降低。

 

事務處理性能趨勢：當壓力穩步上升後，應用事務處理能力保持平穩，基本維持在每秒鐘處理130個左右事務，該數值基本能保障併發用戶註冊的需求。

 

壓測寶雲壓測客戶案例2：基於壓測的後端性能問題分析與定位

下面介紹另一個用戶的真實需求場景，這裏着重分析用戶在壓測時遇到的性能問題，主要從失敗和響應時間緩慢兩個角度，首先是失敗狀況，以下圖所示，失敗的類型及其佔比。

 

在整個測試過程系統從5:05分開始出現逐漸增長的不一樣類型服務器處理錯誤，致使事務處理失敗，具體錯誤信息以下：

502：錯誤網關（從5:43～5:46共出現112次502錯誤）；

600：connection鏈接異常，從5:05～5:50共出現264次600錯誤）；

601：Socket異常（5:31和5:47出現2次601錯誤）；

603：拒接服務錯誤（從5:21至5:49共出現48次603錯誤）；

實際上是響應時間分析，以下圖所示某個事務及其對應的請求狀況。

 

從上圖能夠看出「好友動態」的平均事務請求響應時間爲10,862ms，是其餘應用請求的平均響應時間的7倍（其餘請求平均響應時間爲1,400ms）。

 

上圖爲從壓測寶系統獲取的一次好友動態事務請求響應日誌，能夠看出響應時間爲12232ms，其中鏈接時間爲3136ms，請求返回的內容很是大（51764Bytes）。和其餘應用相比好友動態應用耗時很是長，用戶體驗不好。

在本次壓測的全程，基於雲智慧的應用性能管理產品透視寶來進一步分析後端性能狀況，經過後端應用請求分析能夠查看一段時間內Web應用處理事務請求的響應時間、請求數及詳細的請求信息及變化趨勢。在併發用戶超過200時響應時間明顯變慢，但總體系統響應時間表現正常（處理時間小於500ms佔比74.13%）；

 

接着咱們利用透視寶的代碼級堆棧定位分析功能來進一步分析數據庫SQL狀況，以下圖所示。

 

經過後端關鍵事務快照能夠看出單次請求處理的數據庫鏈接耗時1400.92ms，佔比95.23%（總響應時間1471.02ms），是主要的數據庫耗時來源；

 

 

能夠看出數據庫查詢操做耗時佔比3.71%，是數據庫第二耗時來源；並且多個數據庫查詢SQL語句大部分查詢條件相同，在高併發量用戶查詢時有較大的性能優化空間。

基於以上的分析，建議用戶從以下方面進行優化：

1） 若是應用處理入口有前置負載均衡服務器，建議對負載均衡服務器相關參數進行優化，提高用戶請求入口處理能力；同時建議對負載均衡服務器進行性能監控，及時發現系統瓶頸；

2） 事務請求處理過程當中數據庫鏈接耗時較長，建議採用數據庫鏈接池組件進行性能優化；

3） 建議在系統架構中增長數據庫緩存，同時對相似的SQL操做進行處理優化，以減小後端數據庫的鏈接次數，提升數據庫查詢效率和性能；

基於請求的深刻分析，在壓測寶中提供問題請求的詳細快照，包括請求的響應時間分解、請求頭和返回結果，以下圖所示。

 

 

另外如上面所示，在壓測寶的單次請求追蹤部分集成了性能管理產品透視寶，可以經過單次請求直接查看後端的代碼問題，以下圖所示：

 

經過對失敗、緩慢與錯誤的事務與請求進行細化分析，包括對錯誤類型分析、請求快照查看以及後端深刻定位。

以上是兩個真實應用場景的雲端壓力測試分析案例，經過性能壓力測試（壓測寶）咱們能夠清楚的知曉業務容量規劃，並發現系統中影響業務的性能問題（請求緩慢、失敗）。經過與應用性能管理（透視寶）集成來定位和診斷根源問題，深刻分析後端的性能瓶頸來提高業務質量，從而實現應用的快速優化和上線。