如何分析Apache TubeMQ的Benchmark測試

這篇文章將為大家詳細講解有關如何分析Apache TubeMQ的Benchmark測試，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

1. 前言

Apache TubeMQ的Benchmark測試項為什么要這么設計？每一個場景反饋了哪些內容，是否是為了放大TubeMQ的優點而做的針對性場景定義？和其他MQ的Benchmark測試用例相比異同點在哪里？這篇我們一起來做TubeMQ的Benchmark測試項及測試結果的解讀。

2. 說在前面

TubeMQ的Benchmark測試項及測試結果報告tubemq_perf_test_vs_Kafka包含在項目的website里沒有直接顯現在頁面上展示，主要是開源時團隊內部做過討論，無意去做PK賽，所以需要大家通過鏈接直接訪問該頁面。

在tubemq_perf_test_vs_Kafka這篇文檔里公布的內容僅測試場景就有8項，每一項里又包含多個測試條目，整體合起來有近百項，實際的測試報告要比這個更詳盡，而公布出來的測試項和測試結果已經可以讓大家很清晰的了解TubeMQ的實際情況。

TubeMQ最新版本的測試數據一定是要比開源初期做的這份數據更好一點，只是因為最初的測試結果已發表沒有必要花時間和資源來調整這些內容，大家可以在了解TubeMQ的Benchmark測試項的構思后進行更有針對性的分析和復核，來驗證它的真實性。

3. TubeMQ Benchmark測試項設計思路

在設計Apache TubeMQ這份Benchmark測試項時主要考慮了這幾點：系統核心設計方案的長處和短處是什么，在應用時它的邊界值在哪里？真實環境里我們會怎么使用這套系統，對應配置的調整會給系統帶來的影響是怎樣？隨著負載增加，系統的指標趨勢在設計容許的限度范圍內表現情況是怎樣？

測試報告里的每個測試場景已經按照【場景，結論，數據】的方式給出，并給出了我們的各個指標視圖，這里我們仍然按照【場景，數據解讀】的方式給出，便于大家的查看和參考。

4. TubeMQ Benchmark測試結果解讀：

4.1 場景一：基礎場景，單topic情況，一入兩出模型，分別使用不同的消費模式、不同大小的消息包，分區逐步做橫向擴展，對比TubeMQ和Kafka性能

通過這個測試項，大家可以獲得一個基準信息，TubeMQ的Topic吞吐能力不隨Partition個數增加而提升，吞吐量與Partition的個數沒有關系；同時TubeMQ單個的存儲實例的吞吐量不如Kafka單Partition的吞吐能力。結合我們存儲的設計介紹和這個數據測試結果我們可以了解到，TubeMQ里Partition并不是實際的存儲單元，在使用的時候需要與Kafka的Partiton概念做區分；換句話說TubeMQ的Partition是邏輯分區，只與消費的并行度掛鉤。

為什么采用1份生產2份消費前置條件： 大部分的測試場景都是1份生產2份消費，為什么要設置這個前提呢？從我們的觀點看，純生產的場景其實是不符合MQ的實際線上應用場景的，在線上數據至少會有一份消費，最多可能幾十份，如果只測試純粹的生產則不能反映出系統上線后實際的運行情況；我們也做過純生產的測試，同時也做過1份生產1份消費，以及1份生產2份消費，以及1份生產多份消費的情況，從測試的數據來看，系統的TPS（TransactionsPerSecond的縮寫，每秒成功的請求響應數）會受消費份數直接影響，而我們環境多是2份數據讀取，因而我們主體測試場景里都是2份消費的基準測試要求。

為什么單包選擇1K大小作為前置： 對于包長選擇也是通過這個測試用例獲得，通過場景一的測試數據我們可以看到，隨著包長增加，雖然流量隨之增長了，但系統的TPS逐步下降，包越大TPS下降越多。從我們測試數據來看，1 ~ 4K左右，系統在TPS、成本等方面是比較好接受的，以1K作為基準，不長也不短，會比較符合系統上線后的實際使用情況。

4.2 場景二：單topic情況，一入兩出模型，固定消費包大小，橫向擴展實例數，對比TubeMQ和Kafka性能情況

從這個表格里，我們可以獲得的幾個信息：

1. 場景一里雖然Apache TubeMQ的單存儲實例的吞吐能力不如Kafka的單Parititon能力，但存儲實例在4個左右時會追平Kafka同等的配置；

2. 吞吐能力與存儲實例數的關系，從1到10，TubeMQ的吞吐量有增加趨勢，而Kafka呈現下降趨勢；

3. 調整TubeMQ里消費者的消費方式（qryPriorityId，消費優先級ID），系統的吞吐能力會呈現出不一樣的變化，線上可以根據實際的運營情況調整消費組的消費能力，進行差異化服務同時提升系統單位資源下的吞吐能力。

4.3 場景三：多topic場景，固定消息包大小、實例及分區數，考察100、200、500、1000個topic場景下TubeMQ和Kafka性能情況

為什么要測試這么多的Topic： 有同學表達過這個疑惑，我們為什么不像其他MQ的Benchmark測試項樣，采用單Topic多Partiton，或者幾十個Topic的測試呢？

基于線上實際應用需要： TubeMQ的現網上每個配置的Topic動輒幾十上百，而我們設計容量是1000個，我們要通過這個場景獲得系統隨著Topic數增加而呈現出來的負載曲線，所以幾個或者幾十個Topic是不太滿足我們實際需求的。

實際上目前各個MQ所做的Benchmark測試項不太符合大家的實際系統應用情況，特別是在大數據場景里，試想，我們一個集群動輒幾十臺機器，每個Broker會只配置少數的幾個Topic和Partition嗎？如果只能配置幾十個Topic機器資源利用率就提升不起來，所以我們的基準測試就是成百上千的Topic負載測試。

我們通過不同刻度的負載來分析和對比系統的穩定性情況，吞吐量的變化情況，以及系統在設計范圍內的最大可能情況，從文檔的附錄里，我們還給出了不同Topic場景下的流量變化情況。通過這些我們就清楚的知道系統在實際應用時的表現是怎樣：

4.4 場景四：100個topic，一入一全量出五份部分過濾出：一份全量Topic的Pull消費；過濾消費采用5個不同的消費組，從同樣的20個Topic中過濾出10%消息內容

這個場景反饋的是Apache TubeMQ過濾消費對系統的影響，線上業務在構造Topic的時候，不會每個業務都會構造一個Topic，很多都是混在同一個Topic里進行數據上報和消費，那么就會存在過濾消費數據的需求。

這個用例比較好的反饋了客戶端過濾和服務器端過濾數據的差異；同時，這個指標也反饋出了在過濾消費時，相比全量消費，雖然消費份數由2份全量變成了1份全量5份過濾，但系統的吞吐量增加了約5萬的TPS，說明過濾消費給系統帶來的負載壓力要比全量消費的低。

4.5 TubeMQ、Kafka數據消費時延比對

Kafka端到端時延是否真如此？ 似乎和大家用的有出入，有同學在這篇帖子里有過反饋《如何評價騰訊開源的消息中間件TubeMQ？》 。

為什么會有差異？ 因為我們為了提高Kafka的吞吐能力，將Kafka的生產配置linger.ms調整為了200ms，batch.size調整成了50000字節，如果我們去掉這2個設置，Kafka的端到端時延和TubeMQ差不多，但其請求TPS又和該測試報告里給出的測試結果存在較大的差距，而我們此前已發布過這個測試報告，為了避免不必要的誤會，我們仍然保持了這個報告數據，因為從我們提供的測試參數配置下，數據確實如此：

這個問題如果大家感興趣，可以直接在自己環境驗證下，驗證下我們的測試結果及分析，看看是不是如此。

4.6 場景六：調整Topic配置的內存緩存大小（memCacheMsgSizeInMB）對吞吐量的影響

這個場景反饋的是Apache TubeMQ調整內存緩存的大小時給系統帶來的變化，從數據看內存塊的大小會影響到TubeMQ的吞吐量。這個和我們設計是符合的，具體多大的量影響又有多大，我們再另外的文檔里介紹。

4.7 場景七：消費嚴重滯后情況下兩系統的表現

磁盤系列的弊端： 從這個測試我們可以看到基于磁盤的MQ都有這個弊端，磁盤的好處就是成本低，讀寫次數會比SSD好，在硬件提升前，磁盤有可能會用比較長的時間；這個測試也驗證了我們最初版本的一個構思，通過SSD來緩存滯后數據，以此來換取磁盤滯后讀導致的IO拉升問題。

通過SSD來緩存滯后數據這個思路在《如何評價騰訊開源的消息中間件TubeMQ？》 里也有過交流，后來我們覺得這樣操作還不如直接擴容Broker節點來的快捷，因而新版本里我們廢棄了轉存SSD的操作。

通過這個測試，我們需要清楚的知道磁盤系發生后讀的時候系統表現，及如何處理。

4.8 場景八：評估多機型情況下兩系統的表現

不同機型的適應面： 從這個測試，我們可以看到TubeMQ在磁盤系里，隨著內存、CPU增大，吞吐量會提升很大；而到了SSD機型時Kafka反而會好很多。我們分析應該與我們的讀取模式有關，在存儲不是瓶頸的模式下，Kafka的塊讀塊寫會比TubeMQ的塊寫隨機讀要好不少；從這個測試也很明確的反饋出，每個系統都有它的適應面，關鍵是系統的應用環境和場景。

關于如何分析Apache TubeMQ的Benchmark測試就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。