記一次mqtt壓測過程
專案背景:機器人排程平臺
迭代背景:敏捷開發
記錄方向:mqtt壓測
記錄時間:20211009
===================================================
生產環境上線後,前期主要關注的是功能正確,非功能性的測試內容沒有過多關注,生產環境上線一段時候後,領導要求進行相關的效能測試。這裡記錄一下編寫測試計劃及重點測試問題(主要是rabbitmq方面)的處理處理過程;
=====================================效能測試計劃=====================================
效能測試計劃——10萬+裝置併發
一、前言... 1
二、準備工作... 1
2.1、系統基本功能驗證... 1
2.2、測試團隊組建... 1
2.3、工具選擇... 2
2.4、預先業務場景分析... 2
三、測試計劃... 2
3.1、效能測試專案相關資訊... 2
3.2、測試環境準備... 3
3.2.1、UAT和PRO對比... 3
3.3、效能場景分析及業務建模... 3
3.4、確定性能指標... 3
3.5、測試指令碼開發... 4
四、測試實施... 4
4.1、測試環境確認... 4
4.2、執行測試指令碼... 4
4.3、記錄測試結果... 4
4.4、階段進度統計... 4
五、測試分析... 4
5.1、測試環境的系統性能分析... 4
5.2、硬體裝置對系統性能表現的影響因素... 4
5.3、其他影響因素分析... 4
5.4、測試中發現的問題... 4
5.5、測試後續跟蹤... 4
一、前言
現在MARS系統基本的功能已經穩定,且後端框架基本定型,是時候來一個全身體檢了。領導提出MARS系統必須支援10萬+的裝置併發的模糊需求,沒有明確的各種系統資源水位,響應時間等具體指標,也沒有明確前段的使用者併發。現在根據該模糊需求制定一個比較籠統大概的效能測試計劃,只針對本次的效能測試需求,系統支援10萬+的併發;
二、準備工作
2.1、系統基本功能驗證
現在MARS系統已上生產環境,已經開始接入裝置,裝置資訊上報、告警、裝置控制已經打通,功能驗證已經通過,整個服務端框架已經定型,可以進行效能測試中容量測試、配置測試。
2.2、測試團隊組建
整個效能測試活動中的人員組成,需要各組成成員。在本次效能測試專案中專案負責人與產品為同一人,運維和DBA為同一人。
2.3、工具選擇
常規的效能測試工具主要有jmeter、loadrunner等,根據本次的效能需求主要是通過mqtt釋出訂閱操作來進行模擬裝置上進行釋出、訂閱訊息。經過調研,jmeter有相關mqtt協議的開源外掛,但是外掛效果不是很適用且有bug,所以直接採用python+第三方mqtt庫來模擬完成裝置的釋出訂閱操作。
2.4、預先業務場景分析
本次的效能需求為支援10萬+的裝置併發,根據I型機器人與平臺的通訊協議(I型機器人的通訊協議比較全,就暫時按照I型的協議進行羅列),主要有以下幾個方面的釋出、訂閱協議:裝置登入認證、屬性上報、組織下發協議、地圖互動協議、作業互動協議、告警協議、初始化定位等協議。
截止目前接入****系統的機器人主要有以下幾款協議:*****。
下表為不同機器人型別功能互動場景列舉截圖,具體的互動協議如下附件,****系統與機器人的互動協議主要為mqtt通訊,有少量的https介面。現在
三、測試計劃
3.1、效能測試專案相關資訊
序號 |
資訊型別 |
說明 |
1 |
專案名稱 |
***** |
2 |
專案型別 |
新建 |
3 |
專案背景 |
整體功能已經穩定,後端端架基本定型,已上生產環境 |
4 |
測試目的 |
容量測試、配置測試、負載測試、壓力測試、效能驗證 |
5 |
測試範圍 |
mqtt broker、各服務在10萬+併發下業務處理能力 |
6 |
里程碑 |
測試計劃、環境準備、測試實施、效能優化 |
7 |
影響因素 |
測試環境確定為UAt環境,測試環境與生產環境的配置不一致,無法準確評估生產環境的水位容量、沒有具體的效能指標,指標是否通過無法明確界定 |
3.2、測試環境準備
現目前MARS系統的環境有:DEV、SIT、UAT、PRO四個環境,生產環境已經上線開始執行,已經有部分裝置接入到生產環境中,不能直接用來作為效能測試的環境,有業務因素,也有技術不支援的因素。生產環境的壓測是需要進行進行請求流量區分、影子庫區分。所以確定使用最接近生產環境的UAT環境來進行效能測試。
3.2.1、UAT和PRO對比
現在UAT環境的各個服務的副本都是沒有進行資源限定的如CPU、記憶體、頻寬、磁碟大小、快取等,也無法知曉生產環境的各服務的資源配置,無法對UAT和PRO環境的資源配置及服務部署形成有效的對比。找運維確認過,PRO環境的系統資源配置是比UAT環境的配置要高,且PRO環境各個服務所開的副本數量是比UAT環境的副本要多。所以暫時就不在這兒邏輯效能測試環境與PRO環境的具體差異,直接簡單粗暴的使用UAT環境進行測試。
3.3、效能場景分析及業務建模
本次效能測試場景為10萬+裝置併發,根據此場景羅列出本次測試的核心業務場景。
根據上文的MARs系統的接入裝置型別及裝置佔比進行統計得出每種接入的裝置業務併發
10萬+裝置佔比情況 |
||||
序號 |
裝置型別 |
接入佔比 |
併發數量 |
備註 |
1 |
***** |
10% |
10000 |
|
2 |
***** |
40% |
40000 |
|
3 |
***** |
35% |
35000 |
|
4 |
***** |
10% |
10000 |
|
5 |
***** |
5% |
5000 |
|
合計 |
100% |
100000 |
|
根據接入裝置的實際佔比情況及接入裝置的通訊協議開發測試指令碼。
3.4、確定性能指標
3.5、測試指令碼開發
四、測試實施
4.1、測試環境確認
效能測試確定為UAT環境,UAT環境配置如下。
4.2、執行測試指令碼
4.3、記錄測試結果
4.4、階段進度統計
五、測試分析
5.1、測試環境的系統性能分析
5.2、硬體裝置對系統性能表現的影響因素
5.3、其他影響因素分析
5.4、測試中發現的問題
5.5、測試後續跟蹤
==========================效能測試過程中重點問題分析====================================
主要記錄一下rabbitmq方面的問題,訊息重複消費問題暫未發現,在前期編碼的時候進行過重複消費異常做過相應處理;
1、rabbitmq叢集在壓測時所有的壓力都堆積到一個node節點中;
分析:後續經過分析,運維人員配置rabbitmq的配置出現問題,重新修改配置後各個節點負載均衡;
2、通過模擬大量裝置併發推送訊息時有丟包現象;
分析:
原因1、mqtt broker接收到機器人推送的訊息後釋出到MQ釋出失敗,MQ記憶體超過限制,導致觸發報警,報警解除前不允許新的釋出
措施:增加MQ記憶體
原因2、訊息者消費訊息過慢,MQ巨集訊息堆積過多,導致訊息堆積阻塞。訊息堆積阻塞的本質就是生產訊息速率大於消費訊息速率,導致生產的訊息大量堆積在佇列中
措施:增加消費者數、提高消費者併發從而提高消費速率、提高消費者的預取檔案數。