作者：極光高級測試工程師——王素花&楊莞武
-
需求背景
通過介紹locust分佈式負載測試工具的使用方法，讓大家能快速掌握性能測試的基本方法，提高工作效率 -
術語解釋
性能測試定義：指通過自動化測試工具模擬多種正常，峯值以及負載條件對系統的各項性能指標進行測試
響應時間：測單接口的性能，響應時間可以簡單理解爲用戶發送一個請求到服務器返回的響應數據這段時間就是響應時間。
併發用戶數：某一物理時刻同時向系統提交請求的用戶數，提交的請求可能是同一個場景，也可以是不同場景。
TPS： 全拼是Transaction per second，每秒事務數；測單接口的性能，一個事務可以理解爲一個客戶機向服務器發送請求然後服務器做出反應的過程。
單推： 下發一條消息只推送一個用戶id （多個用戶收到消息是通過推送多條消息來實現的）
多推：一條推送消息可以同時推送多個用戶id。（多個用戶收到消息是通過一條消息來實現的） -
測試策略
3.1 需求分析：
針對需求，現需測試下列幾個場景：
使用域名單推，查看發送的最大TPS
使用域名多推，查看發送的最大TPS
3.2 測試方法
1 、性能測試的前期準備：
分析業務場景：場景內容有哪些，範圍較廣，可與開發、產品，討論確定本次測試的範圍
分析測試策略：得到設計的測試場景有哪些
分析生產環境
選擇測試工具：用什麼方式來測試性能
2 性能測試的目的：
性能測試則通過提前模擬場景壓力，發現系統中可能的瓶頸，進行系統調優，減少服務器宕機的風險
性能測試還可以用來評估待測軟件在不同負載下的系統負載能力，爲系統部署，提供性能數據決策
3 性能下降曲線分析法：
性能隨用戶數增長而出現下降趨勢的曲線，如圖所示：
藍線表示 TPS，黃色表示響應時間
在 TPS 增加的過程中，響應時間一開始會處在較低的狀態，也就是在 A 點之前。接着響應時間開始有些增加，直到業務可以承受的時間點 B，這時 TPS 仍然有增長的空間。再接着增加壓力，達到 C 點時，達到最大 TPS。我們再接着增加壓力，響應時間接着增加，但 TPS 會有下降。
3.3 測試工具
使用分佈式壓測工具locust
3.4 測試環境
3.4.1 壓測數據流程圖
3.4.2 被測系統
API服務爲雙機雙節點部署方式，相關依賴服務部署也都部署在這臺服務起上，且都是雙節點
服務器資源：4核16G
使用域名壓測：域名通過lbs轉發到服務器
4 測試工具Locust
4.1 簡要
JMeter和LoadRunner性能測試工具，是比較老牌的，都是通過線程來作爲虛擬虛擬用戶，而Locust是基於協程實現併發用戶的，協程是比線程更小的單位，也稱爲子線程，在一個線程中可以運行多個協程。所以基於協程的Locust，在進行分佈式部署時，不僅可以進行多機壓測部署，而且還可以在一臺宿主機中完成
4.2 壓測工具：locust，版本：0.14.5
4.3 Locust本地宿主機部署步驟
1.首先我們需要通過python+locust寫出程序需要運行的ABC.py文件
腳本說明：
新建一個類TPush(TaskSet)，繼承TaskSet，該類下面寫需要請求的接口以及相關信息； self.client調用get和post方法，和requests一樣；
@task裝飾該方法表示爲用戶行爲，括號裏面參數表示該行爲的執行權重：數值越大，執行頻率越高，不設置默認是1；
on_start方法:當模擬用戶開始執行該 TaskSet 類時，將調用該方法；
WebsiteUser()類用於設置生成負載的基本屬性：
tasks：指向定義了用戶行爲的類；
min_wait：模擬負載的任務之間執行時的最小等待時間，單位爲毫秒；
max_wait：模擬負載的任務之間執行時的最大等待時間，單位爲毫秒。
2.創建locust運行的master:
寫好需要運行的locust文件之後，我們需要先利用命令“locust -f xxxx.py --master”創建一個master，這個master不參與創建併發用戶的工作，它主要是進行監聽以及收集統計數據.
2.1 提供給web端，我們完全可以利用python當中的os的system函數直接編寫出cmd命令進行運行
2.2 使用no-web，也可以利用python當中的os的system函數直接編寫出cmd命令進行運行
當然也可以直接輸入命令執行
此時我們運行py文件，可以看到以下的信息，則說明我們已經啓動了locust分佈式的主節點master
3.創建locust運行的slave
我們就可以創建用於製造併發用戶的分支節點slave了，方法就是複製master的文件，然後修改一下文件名稱，一定要保證slave運行的文件與master文件是一樣的，自己的機器有多少個cpu就可以弄多少個slave，一般一個slave會使用一個cpu創建併發用戶
ABC.py ABC_slave1.py 3.1 然後每個slave文件中需要在主函數中輸入cmd命令
3.2 也可直接輸入命令執行slave
運行多個slave，可以查看以下內容來判斷分佈式是否部署成功
當開啓全部slave後，可以查看master的控制檯信息，看到下面的信息則表示locust分佈式部署成功了
4、打開web端同樣也可以查看到分佈式的slave
登陸頁面
啓動壓測前，需要填寫用戶總數(Number of total users to simulate)、每秒增加的用戶數(Spawn rate)以及域名(HOST)。
每秒增加的用戶數(Spawn rate)會在用戶數達到用戶總數(Number of total users to simulate)時停止增加。
查看slave節點數
由上圖可以看出slave都存於running狀態，且壓力分佈均勻。
測試結果數據下載
在locust當中使用web模式進行壓測時是沒有辦法設定執行時間的，所以web模式下的壓測會一直運行，直到點擊stop才能運行，如果想在web模式下運行壓測一段時間自動停止的話，那麼需要在參數配置時加入stop_timeout參數即可，value值是執行的時間（單位是s）
class websitUser(HttpLocust):
task_set = Login #定義需要執行的任務集
min_wait = 1000 #最小等待時間
max_wait = 2000 #最大等待時間
stop_timeout = 60 # 停止的時間
5 通過locust可視化界面判斷接口性能瓶頸
在總用戶數爲100，每秒增加1個用戶的情況下運行一段時間，我們查看locustweb界面：
發現tps穩定停留在某個數值(9.8)，這時候我們點擊Charts查看TPS、延遲和用戶數的詳情分佈圖
可以看出在TPS在10之前，隨着用戶數的增加而增加；但增加到10之後，用戶數再怎麼增加tps依然穩定在10左右，只有延遲在增加；
再查看服務器性能
可以看出cpu都被該程序佔用，那麼我們可以初步認爲該接口的tps爲10，且瓶頸在cpu上。
6.數據採集實操
單推接口：/single
多推接口：/mutiplie
- 數據分析
壓測時內存消耗沒有cpu消耗明顯。從系統穩定性考慮，需要考慮服務不掛，穩定情況下的性能指標。需要對數據採集進行分析，分析得如下結論：
單推：每秒增加用戶數爲3，併發用戶數爲160，cpu消耗在80%左右來持續壓測得出下面的性能各項指標。
多推：每秒增加用戶數爲2，併發用戶數爲120，cpu消耗在78%左右來持續壓測得出下面的性能各項指標。
注：（多推時，考慮到body的大小，deviceTokens設置3個數，對接口來說無差異，在數據落地時才消耗資源，另外借助單推的經驗和多推的系統邏輯，簡單可以定位出多推的資源消耗。所以數據採集相對少些。）
8.測試結論
單推接口： 接口TPS壓測結果爲 1757/s，90%請求可以在 0.1 秒內響應，因線上 部署多臺機器，所以該 tps 只限當前配置和部署的情況下，主要瓶頸是設備升級；
多推接口： 接口TPS壓測結果爲 1342/s，90%請求可以在 0.1 秒內響應，因線上部 署多臺機器，所以該 tps 只限當前配置和部署的情況下，主要瓶頸是設備升級；
文章引用的數據，僅代表特定壓測環境下的服務表現