1. 程式人生 > >【總結】對異步處理的http接口進行性能測試

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

調研 內存 雲監控 後端 調優 系統 錯誤 手機 服務器

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

通俗理解一下同步和異步的差別,舉個小例子:

同步就是你媽喊你吃飯,你說等一下,然後你媽媽就一直在旁邊等著你,專門等著你,等你做完了,一起去吃飯;

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

那麽問題來了,這種接口,如果還像以前一樣單純的看接口的響應時間,就沒有任何意義了,那麽如何判斷接口的性能呢?

先來描述一下被測系統:

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

1、制定測試方案

開始性能測試了,說明系統功能已經穩定,無遺留嚴重bug,此時需要對系統的需求做個調研分析,確定被測系統的性能測試方案,這裏可以從需求出發,初步確定性能測試方案。確定測試場景為單接口場景,選取三個調用頻率最高的接口來測試,和開發及運維等相關人員確定壓測環境、服務器配置等數據,通過壓力測試工具jmeter關註響應時間、每秒TPS及錯誤率,同時使用阿裏雲監控平臺監控服務器內存和CPU使用情況。采用循序漸進增加線程數的方式得到接口的最大處理能力。

2、確定測試數據

為了盡量模擬真實場景,需準備不小於並發數百分之20的數據作為壓測數據。

壓測數據寫在excel中

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

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

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

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

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

4、執行測試

測試腳本調試通過,就可以執行測試了。

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

但是以上方式並不適用於這種異步的接口,那麽如何處理呢?

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

5、測試結果分析及調優

這部分和普通接口的壓力測試是相同的,這裏不多敘述。

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