如何分析Apache TubeMQ的Benchmark測試

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

1. 前言

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

2. 說在前面

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

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

TubeMQ最新版本的測試數(shù)據(jù)一定是要比開源初期做的這份數(shù)據(jù)更好一點，只是因為最初的測試結(jié)果已發(fā)表沒有必要花時間和資源來調(diào)整這些內(nèi)容，大家可以在了解TubeMQ的Benchmark測試項的構(gòu)思后進(jìn)行更有針對性的分析和復(fù)核，來驗證它的真實性。

3. TubeMQ Benchmark測試項設(shè)計思路

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

測試報告里的每個測試場景已經(jīng)按照【場景，結(jié)論，數(shù)據(jù)】的方式給出，并給出了我們的各個指標(biāo)視圖，這里我們?nèi)匀话凑铡緢鼍埃瑪?shù)據(jù)解讀】的方式給出，便于大家的查看和參考。

4. TubeMQ Benchmark測試結(jié)果解讀：

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

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

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

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

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

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

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

2. 吞吐能力與存儲實例數(shù)的關(guān)系，從1到10，TubeMQ的吞吐量有增加趨勢，而Kafka呈現(xiàn)下降趨勢；

3. 調(diào)整TubeMQ里消費者的消費方式（qryPriorityId，消費優(yōu)先級ID），系統(tǒng)的吞吐能力會呈現(xiàn)出不一樣的變化，線上可以根據(jù)實際的運營情況調(diào)整消費組的消費能力，進(jìn)行差異化服務(wù)同時提升系統(tǒng)單位資源下的吞吐能力。

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

為什么要測試這么多的Topic： 有同學(xué)表達(dá)過這個疑惑，我們?yōu)槭裁床幌衿渌鸐Q的Benchmark測試項樣，采用單Topic多Partiton，或者幾十個Topic的測試呢？

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

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

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

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

這個場景反饋的是Apache TubeMQ過濾消費對系統(tǒng)的影響，線上業(yè)務(wù)在構(gòu)造Topic的時候，不會每個業(yè)務(wù)都會構(gòu)造一個Topic，很多都是混在同一個Topic里進(jìn)行數(shù)據(jù)上報和消費，那么就會存在過濾消費數(shù)據(jù)的需求。

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

4.5 TubeMQ、Kafka數(shù)據(jù)消費時延比對

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

為什么會有差異？ 因為我們?yōu)榱颂岣逰afka的吞吐能力，將Kafka的生產(chǎn)配置linger.ms調(diào)整為了200ms，batch.size調(diào)整成了50000字節(jié)，如果我們?nèi)サ暨@2個設(shè)置，Kafka的端到端時延和TubeMQ差不多，但其請求TPS又和該測試報告里給出的測試結(jié)果存在較大的差距，而我們此前已發(fā)布過這個測試報告，為了避免不必要的誤會，我們?nèi)匀槐３至诉@個報告數(shù)據(jù)，因為從我們提供的測試參數(shù)配置下，數(shù)據(jù)確實如此：

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

4.6 場景六：調(diào)整Topic配置的內(nèi)存緩存大?。╩emCacheMsgSizeInMB）對吞吐量的影響

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

4.7 場景七：消費嚴(yán)重滯后情況下兩系統(tǒng)的表現(xiàn)

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

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

通過這個測試，我們需要清楚的知道磁盤系發(fā)生后讀的時候系統(tǒng)表現(xiàn)，及如何處理。

4.8 場景八：評估多機型情況下兩系統(tǒng)的表現(xiàn)

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

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