【總結】對異步處理的http接口進行性能測試

之前對接口作性能測試，接口都是同步處理的，請求以後等待響應結果就知道處理結果了，這樣只要看這個接口是否異常，若是無異常無報錯記錄這個接口的響應時間、TPS等性能指標進行分析就能夠了，最近在工做中遇到了異步處理的接口，邏輯是隻要你請求參數所有合法，即返回成功。

通俗理解一下同步和異步的差異，舉個小例子：

同步就是你媽喊你吃飯，你說等一下，而後你媽媽就一直在旁邊等着你，專門等着你，等你作完了，一塊兒去吃飯；

異步就是你媽喊你吃飯，你說等一下我忙完了就過去，你媽就走了，該幹啥幹啥去了，你忙完了，直接過去吃飯。

那麼問題來了，這種接口，若是還像之前同樣單純的看接口的響應時間，就沒有任何意義了，那麼如何判斷接口的性能呢？

先來描述一下被測系統：

這是一個專門負責發送消息的平臺，包括短信消息和設備消息，大概架構以下：整個系統分爲前端和後端，前端負責接收客戶端的傳參，把數據寫入數據庫並插入消息隊列MQ；後端負責發送消息，隊列MQ的消費，並更新數據庫記錄隊列消息的消費時間及發送狀態；接口所有爲異步處理機制，下面以發送接口爲例，簡述整個測試過程：

一、制定測試方案

開始性能測試了，說明系統功能已經穩定，無遺留嚴重bug，此時須要對系統的需求作個調研分析，肯定被測系統的性能測試方案，這裏能夠從需求出發，初步肯定性能測試方案。肯定測試場景爲單接口場景，選取三個調用頻率最高的接口來測試，和開發及運維等相關人員肯定壓測環境、服務器配置等數據，經過壓力測試工具jmeter關注響應時間、每秒TPS及錯誤率，同時使用阿里雲監控平臺監控服務器內存和CPU使用狀況。採用按部就班增長線程數的方式獲得接口的最大處理能力。

二、肯定測試數據

爲了儘可能模擬真實場景，需準備不小於併發數百分之20的數據做爲壓測數據。

壓測數據寫在excel中

ps：這裏有個坑，由於消息系統是給用戶發送短信及消息，一不當心可能致使消息發送到真實用戶了。此處有兩個解決方案：a、讓開發處理手機號校驗的代碼，把代碼註釋，手機號使用不存在的數字組合便可

b、開發作擋板，屏蔽調用第三方發送接口

三、根據測試場景編寫測試腳本

共三個接口，https協議post請求

調用接口無需token，所以只須要把入參拼接排序加密簽名便可，入參處理方法能夠用java寫好打包放到jmeter的lib目錄，在beanshell中import進來直接調用便可

四、執行測試

 測試腳本調試經過，就能夠執行測試了。

按照常規接口的測試方式：就是從1個線程數開始，每次壓測5分鐘左右，壓測過程當中監控服務器cpu及內存佔用狀況，記錄tps及響應時間，不斷增長併發數，找到tps隨併發數增大的拐點，即得出接口最大處理能力。

可是以上方式並不適用於這種異步的接口，那麼如何處理呢？

此處經過查詢數據庫。當全部請求所有完畢了，查詢數據庫的發送信息表，檢查請求時間字段和發送時間字段，請求時間字記錄該請求的調用時間，發送時間字段是後端發送消息後回寫到數據庫的發送時間，故請求時間字段和發送時間字段的差就是這一個請求的完整的響應時間，能夠算出全部請求的平均時間、90%時間，第一條開始請求的時間到最後一條發送成功的時間之差就爲持續壓測時間，進而經過請求數可以計算出TPS，達到測試目的。

五、測試結果分析及調優

 這部分和普通接口的壓力測試是相同的，這裏很少敘述。