Spark SQL 在極光的建設(shè)實踐
Locust性能測試工具的使用
數(shù)據(jù)質(zhì)量建設(shè)實踐
百億級數(shù)據(jù)的實時存取優(yōu)化與實踐
極光clickhouse千億級數(shù)據(jù)分析實踐之路
1. 需求背景
通過介紹locust分布式負(fù)載測試工具的使用方法，讓大家能快速掌握性能測試的基本方法，提高工作效率。
2. 術(shù)語解釋
性能測試定義：指通過自動化測試工具模擬多種正常，峰值以及負(fù)載條件對系統(tǒng)的各項性能指標(biāo)進(jìn)行測試
響應(yīng)時間：測單接口的性能，響應(yīng)時間可以簡單理解為用戶發(fā)送一個請求到服務(wù)器返回的響應(yīng)數(shù)據(jù)這段時間就是響應(yīng)時間。
并發(fā)用戶數(shù)：某一物理時刻同時向系統(tǒng)提交請求的用戶數(shù)，提交的請求可能是同一個場景，也可以是不同場景。
TPS： 全拼是Transaction per second，每秒事務(wù)數(shù)；測單接口的性能，一個事務(wù)可以理解為一個客戶機向服務(wù)器發(fā)送請求然后服務(wù)器做出反應(yīng)的過程。
單推： 下發(fā)一條消息只推送一個用戶id （多個用戶收到消息是通過推送多條消息來實現(xiàn)的）
多推：一條推送消息可以同時推送多個用戶id。（多個用戶收到消息是通過一條消息來實現(xiàn)的）
3. 測試策略
3.1 需求分析：
針對需求，現(xiàn)需測試下列幾個場景：
使用域名單推，查看發(fā)送的最大TPS
使用域名多推，查看發(fā)送的最大TPS
3.2 測試方法
（1）性能測試的前期準(zhǔn)備：
分析業(yè)務(wù)場景：場景內(nèi)容有哪些，范圍較廣，可與開發(fā)、產(chǎn)品，討論確定本次測試的范圍
分析測試策略：得到設(shè)計的測試場景有哪些
分析生產(chǎn)環(huán)境： 分析用戶實際使用場景及系統(tǒng)詳細(xì)部署情況
選擇測試工具：用什么方式來測試性能
（2）性能測試的目的：
性能測試則通過提前模擬場景壓力，發(fā)現(xiàn)系統(tǒng)中可能的瓶頸，進(jìn)行系統(tǒng)調(diào)優(yōu)，減少服務(wù)器宕機的風(fēng)險。
性能測試還可以用來評估待測軟件在不同負(fù)載下的系統(tǒng)負(fù)載能力，為系統(tǒng)部署，提供性能數(shù)據(jù)決策
（3） 性能下降曲線分析法：
性能隨用戶數(shù)增長而出現(xiàn)下降趨勢的曲線，如圖所示：
藍(lán)線表示 TPS，黃色表示響應(yīng)時間
在 TPS 增加的過程中，響應(yīng)時間一開始會處在較低的狀態(tài)，也就是在 A 點之前。接著響應(yīng)時間開始有些增加，直到業(yè)務(wù)可以承受的時間點 B，這時 TPS 仍然有增長的空間。再接著增加壓力，達(dá)到 C 點時，達(dá)到最大 TPS。我們再接著增加壓力，響應(yīng)時間接著增加，但 TPS 會有下降。
3.3 測試工具
使用分布式壓測工具locust
3.4 測試環(huán)境
3.4.1 壓測數(shù)據(jù)流程圖
3.4.2 被測系統(tǒng)
API服務(wù)為雙機雙節(jié)點部署方式，相關(guān)依賴服務(wù)部署也都部署在這臺服務(wù)起上，且都是雙節(jié)點
服務(wù)器資源：4核16G
使用域名壓測：域名通過lbs轉(zhuǎn)發(fā)到服務(wù)器
4 .測試工具Locust
4.1 簡要
JMeter和LoadRunner性能測試工具，是比較老牌的，都是通過線程來作為虛擬虛擬用戶，而Locust是基于協(xié)程實現(xiàn)并發(fā)用戶的，協(xié)程是比線程更小的單位，也稱為子線程，在一個線程中可以運行多個協(xié)程。所以基于協(xié)程的Locust，在進(jìn)行分布式部署時，不僅可以進(jìn)行多機壓測部署，而且還可以在一臺宿主機中完成
4.2 壓測工具：locust，版本：0.14.5
4.3 Locust本地宿主機部署步驟
(1)首先我們需要通過python+locust寫出程序需要運行的ABC.py文件
腳本說明：
新建一個類TPush(TaskSet)，繼承TaskSet，該類下面寫需要請求的接口以及相關(guān)信息； self.client調(diào)用get和post方法，和requests一樣；
@task裝飾該方法表示為用戶行為，括號里面參數(shù)表示該行為的執(zhí)行權(quán)重：數(shù)值越大，執(zhí)行頻率越高，不設(shè)置默認(rèn)是1；
on_start方法:當(dāng)模擬用戶開始執(zhí)行該 TaskSet 類時，將調(diào)用該方法；
WebsiteUser()類用于設(shè)置生成負(fù)載的基本屬性：
l tasks：指向定義了用戶行為的類；
l min_wait：模擬負(fù)載的任務(wù)之間執(zhí)行時的最小等待時間，單位為毫秒；
l max_wait：模擬負(fù)載的任務(wù)之間執(zhí)行時的最大等待時間，單位為毫秒。
(2)創(chuàng)建locust運行的master:
寫好需要運行的locust文件之后，我們需要先利用命令“l(fā)ocust -f xxxx.py --master”創(chuàng)建一個master，這個master不參與創(chuàng)建并發(fā)用戶的工作，它主要是進(jìn)行監(jiān)聽以及收集統(tǒng)計數(shù)據(jù).
2.1 提供給web端，我們完全可以利用python當(dāng)中的os的system函數(shù)直接編寫出cmd命令進(jìn)行運行
2.2 使用no-web，也可以利用python當(dāng)中的os的system函數(shù)直接編寫出cmd命令進(jìn)行運行
當(dāng)然也可以直接輸入命令執(zhí)行
此時我們運行py文件，可以看到以下的信息，則說明我們已經(jīng)啟動了locust分布式的主節(jié)點master
(3)創(chuàng)建locust運行的slave
我們就可以創(chuàng)建用于制造并發(fā)用戶的分支節(jié)點slave了，方法就是復(fù)制master的文件，然后修改一下文件名稱，一定要保證slave運行的文件與master文件是一樣的，自己的機器有多少個cpu就可以弄多少個slave，一般一個slave會使用一個cpu創(chuàng)建并發(fā)用戶
ABC.py ABC_slave1.py 3.1 然后每個slave文件中需要在主函數(shù)中輸入cmd命令
3.2 也可直接輸入命令執(zhí)行slave
運行多個slave，可以查看以下內(nèi)容來判斷分布式是否部署成功
當(dāng)開啟全部slave后，可以查看master的控制臺信息，看到下面的信息則表示locust分布式部署成功了
(4)、打開web端同樣也可以查看到分布式的slave
登陸頁面
啟動壓測前，需要填寫用戶總數(shù)(Number of total users to simulate)、每秒增加的用戶數(shù)(Spawn rate)以及域名(HOST)。
每秒增加的用戶數(shù)(Spawn rate)會在用戶數(shù)達(dá)到用戶總數(shù)(Number of total users to simulate)時停止增加。
查看slave節(jié)點數(shù)
由上圖可以看出slave都存于running狀態(tài)，且壓力分布均勻。
測試結(jié)果數(shù)據(jù)下載
在locust當(dāng)中使用web模式進(jìn)行壓測時是沒有辦法設(shè)定執(zhí)行時間的，所以web模式下的壓測會一直運行，直到點擊stop才能運行，如果想在web模式下運行壓測一段時間自動停止的話，那么需要在參數(shù)配置時加入stop_timeout參數(shù)即可，value值是執(zhí)行的時間（單位是s）
class websitUser(HttpLocust):
task_set = Login #定義需要執(zhí)行的任務(wù)集
min_wait = 1000 #最小等待時間
max_wait = 2000 #最大等待時間
stop_timeout = 60 # 停止的時間
5.通過locust可視化界面判斷接口性能瓶頸
在總用戶數(shù)為100，每秒增加1個用戶的情況下運行一段時間，我們查看locustweb界面：
發(fā)現(xiàn)tps穩(wěn)定停留在某個數(shù)值(9.8)，這時候我們點擊Charts查看TPS、延遲和用戶數(shù)的詳情分布圖
可以看出在TPS在10之前，隨著用戶數(shù)的增加而增加；但增加到10之后，用戶數(shù)再怎么增加tps依然穩(wěn)定在10左右，只有延遲在增加；
在查看服務(wù)器性能
可以看出cpu都被該程序占用，那么我們可以初步認(rèn)為該接口的tps為10，且瓶頸在cpu上。
6.數(shù)據(jù)采集實操
單推接口：/single
多推接口：/mutiplie
7. 數(shù)據(jù)分析
壓測時內(nèi)存消耗沒有cpu消耗明顯。從系統(tǒng)穩(wěn)定性考慮，需要考慮服務(wù)不掛，穩(wěn)定情況下的性能指標(biāo)。需要對數(shù)據(jù)采集進(jìn)行分析，分析得如下結(jié)論：
單推：每秒增加用戶數(shù)為3，并發(fā)用戶數(shù)為160，cpu消耗在80%左右來持續(xù)壓測得出下面的性能各項指標(biāo)。
多推：每秒增加用戶數(shù)為2，并發(fā)用戶數(shù)為120，cpu消耗在78%左右來持續(xù)壓測得出下面的性能各項指標(biāo)。
注：（多推時，考慮到body的大小，deviceTokens設(shè)置3個數(shù)，對接口來說無差異，在數(shù)據(jù)落地時才消耗資源，另外借助單推的經(jīng)驗和多推的系統(tǒng)邏輯，簡單可以定位出多推的資源消耗。所以數(shù)據(jù)采集相對少些。）
8.測試結(jié)論
單推接口： 接口TPS壓測結(jié)果為 1757/s，90%請求可以在 0.1 秒內(nèi)響應(yīng)，因線上 部署多臺機器，所以該 tps 只限當(dāng)前配置和部署的情況下，主要瓶頸是設(shè)備升級；
多推接口： 接口TPS壓測結(jié)果為 1342/s，90%請求可以在 0.1 秒內(nèi)響應(yīng)，因線上部 署多臺機器，所以該 tps 只限當(dāng)前配置和部署的情況下，主要瓶頸是設(shè)備升級；
文章引用的數(shù)據(jù)，僅代表特定壓測環(huán)境下的服務(wù)表現(xiàn)
熱門文章
《GPTBots Multi-Agent架構(gòu)解析：如何通過多Agent協(xié)同實現(xiàn)業(yè)務(wù)智能化升級》
2025-10-13
GPTBots × ZohoSalesIQ 集成實戰(zhàn)：智能代理與?效轉(zhuǎn)??的最佳實踐解析
2025-09-05
EngageLab 發(fā)布 Chrome 插件推送能力：解鎖 WebPush 免授權(quán)、系統(tǒng)級通知新體驗
2025-09-01
GPTBots 技術(shù)揭秘：我們?nèi)绾螐?到1打造支撐AI高效運行的會話級代碼解釋器
2025-08-18
開發(fā)者必看：2025最高效的推送圖標(biāo)配置指南
2025-07-16
相關(guān)文章
極光官方微信公眾號
關(guān)注我們，即時獲取最新極光資訊
現(xiàn)在注冊，領(lǐng)取新人大禮包
