建站
咨詢
售后
建站咨詢
新聞中心
這篇文章將為大家詳細(xì)講解有關(guān)如何分析Apache TubeMQ的Benchmark測試，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
為環(huán)翠等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及環(huán)翠網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、環(huán)翠網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
1. 前言
Apache TubeMQ的Benchmark測試項(xiàng)為什么要這么設(shè)計(jì)？每一個(gè)場景反饋了哪些內(nèi)容，是否是為了放大TubeMQ的優(yōu)點(diǎn)而做的針對性場景定義？和其他MQ的Benchmark測試用例相比異同點(diǎn)在哪里？這篇我們一起來做TubeMQ的Benchmark測試項(xiàng)及測試結(jié)果的解讀。
2. 說在前面
TubeMQ的Benchmark測試項(xiàng)及測試結(jié)果報(bào)告tubemq_perf_test_vs_Kafka包含在項(xiàng)目的website里沒有直接顯現(xiàn)在頁面上展示，主要是開源時(shí)團(tuán)隊(duì)內(nèi)部做過討論，無意去做PK賽，所以需要大家通過鏈接直接訪問該頁面。
在tubemq_perf_test_vs_Kafka這篇文檔里公布的內(nèi)容僅測試場景就有8項(xiàng)，每一項(xiàng)里又包含多個(gè)測試條目，整體合起來有近百項(xiàng)，實(shí)際的測試報(bào)告要比這個(gè)更詳盡，而公布出來的測試項(xiàng)和測試結(jié)果已經(jīng)可以讓大家很清晰的了解TubeMQ的實(shí)際情況。
TubeMQ最新版本的測試數(shù)據(jù)一定是要比開源初期做的這份數(shù)據(jù)更好一點(diǎn)，只是因?yàn)樽畛醯臏y試結(jié)果已發(fā)表沒有必要花時(shí)間和資源來調(diào)整這些內(nèi)容，大家可以在了解TubeMQ的Benchmark測試項(xiàng)的構(gòu)思后進(jìn)行更有針對性的分析和復(fù)核，來驗(yàn)證它的真實(shí)性。
3. TubeMQ Benchmark測試項(xiàng)設(shè)計(jì)思路
在設(shè)計(jì)Apache TubeMQ這份Benchmark測試項(xiàng)時(shí)主要考慮了這幾點(diǎn)：系統(tǒng)核心設(shè)計(jì)方案的長處和短處是什么，在應(yīng)用時(shí)它的邊界值在哪里？真實(shí)環(huán)境里我們會怎么使用這套系統(tǒng)，對應(yīng)配置的調(diào)整會給系統(tǒng)帶來的影響是怎樣？隨著負(fù)載增加，系統(tǒng)的指標(biāo)趨勢在設(shè)計(jì)容許的限度范圍內(nèi)表現(xiàn)情況是怎樣？
測試報(bào)告里的每個(gè)測試場景已經(jīng)按照【場景，結(jié)論，數(shù)據(jù)】的方式給出，并給出了我們的各個(gè)指標(biāo)視圖，這里我們?nèi)匀话凑铡緢鼍?，?shù)據(jù)解讀】的方式給出，便于大家的查看和參考。
4. TubeMQ Benchmark測試結(jié)果解讀：
4.1 場景一：基礎(chǔ)場景，單topic情況，一入兩出模型，分別使用不同的消費(fèi)模式、不同大小的消息包，分區(qū)逐步做橫向擴(kuò)展，對比TubeMQ和Kafka性能
通過這個(gè)測試項(xiàng)，大家可以獲得一個(gè)基準(zhǔn)信息，TubeMQ的Topic吞吐能力不隨Partition個(gè)數(shù)增加而提升，吞吐量與Partition的個(gè)數(shù)沒有關(guān)系；同時(shí)TubeMQ單個(gè)的存儲實(shí)例的吞吐量不如Kafka單Partition的吞吐能力。結(jié)合我們存儲的設(shè)計(jì)介紹和這個(gè)數(shù)據(jù)測試結(jié)果我們可以了解到，TubeMQ里Partition并不是實(shí)際的存儲單元，在使用的時(shí)候需要與Kafka的Partiton概念做區(qū)分；換句話說TubeMQ的Partition是邏輯分區(qū)，只與消費(fèi)的并行度掛鉤。
為什么采用1份生產(chǎn)2份消費(fèi)前置條件：大部分的測試場景都是1份生產(chǎn)2份消費(fèi)，為什么要設(shè)置這個(gè)前提呢？從我們的觀點(diǎn)看，純生產(chǎn)的場景其實(shí)是不符合MQ的實(shí)際線上應(yīng)用場景的，在線上數(shù)據(jù)至少會有一份消費(fèi)，最多可能幾十份，如果只測試純粹的生產(chǎn)則不能反映出系統(tǒng)上線后實(shí)際的運(yùn)行情況；我們也做過純生產(chǎn)的測試，同時(shí)也做過1份生產(chǎn)1份消費(fèi)，以及1份生產(chǎn)2份消費(fèi)，以及1份生產(chǎn)多份消費(fèi)的情況，從測試的數(shù)據(jù)來看，系統(tǒng)的TPS（TransactionsPerSecond的縮寫，每秒成功的請求響應(yīng)數(shù)）會受消費(fèi)份數(shù)直接影響，而我們環(huán)境多是2份數(shù)據(jù)讀取，因而我們主體測試場景里都是2份消費(fèi)的基準(zhǔn)測試要求。
為什么單包選擇1K大小作為前置：對于包長選擇也是通過這個(gè)測試用例獲得，通過場景一的測試數(shù)據(jù)我們可以看到，隨著包長增加，雖然流量隨之增長了，但系統(tǒng)的TPS逐步下降，包越大TPS下降越多。從我們測試數(shù)據(jù)來看，1 ~ 4K左右，系統(tǒng)在TPS、成本等方面是比較好接受的，以1K作為基準(zhǔn)，不長也不短，會比較符合系統(tǒng)上線后的實(shí)際使用情況。
4.2 場景二：單topic情況，一入兩出模型，固定消費(fèi)包大小，橫向擴(kuò)展實(shí)例數(shù)，對比TubeMQ和Kafka性能情況
從這個(gè)表格里，我們可以獲得的幾個(gè)信息：
場景一里雖然Apache TubeMQ的單存儲實(shí)例的吞吐能力不如Kafka的單Parititon能力，但存儲實(shí)例在4個(gè)左右時(shí)會追平Kafka同等的配置；
吞吐能力與存儲實(shí)例數(shù)的關(guān)系，從1到10，TubeMQ的吞吐量有增加趨勢，而Kafka呈現(xiàn)下降趨勢；
調(diào)整TubeMQ里消費(fèi)者的消費(fèi)方式（qryPriorityId，消費(fèi)優(yōu)先級ID），系統(tǒng)的吞吐能力會呈現(xiàn)出不一樣的變化，線上可以根據(jù)實(shí)際的運(yùn)營情況調(diào)整消費(fèi)組的消費(fèi)能力，進(jìn)行差異化服務(wù)同時(shí)提升系統(tǒng)單位資源下的吞吐能力。
4.3 場景三：多topic場景，固定消息包大小、實(shí)例及分區(qū)數(shù)，考察100、200、500、1000個(gè)topic場景下TubeMQ和Kafka性能情況
為什么要測試這么多的Topic：有同學(xué)表達(dá)過這個(gè)疑惑，我們?yōu)槭裁床幌衿渌鸐Q的Benchmark測試項(xiàng)樣，采用單Topic多Partiton，或者幾十個(gè)Topic的測試呢？
基于線上實(shí)際應(yīng)用需要：TubeMQ的現(xiàn)網(wǎng)上每個(gè)配置的Topic動輒幾十上百，而我們設(shè)計(jì)容量是1000個(gè)，我們要通過這個(gè)場景獲得系統(tǒng)隨著Topic數(shù)增加而呈現(xiàn)出來的負(fù)載曲線，所以幾個(gè)或者幾十個(gè)Topic是不太滿足我們實(shí)際需求的。
實(shí)際上目前各個(gè)MQ所做的Benchmark測試項(xiàng)不太符合大家的實(shí)際系統(tǒng)應(yīng)用情況，特別是在大數(shù)據(jù)場景里，試想，我們一個(gè)集群動輒幾十臺機(jī)器，每個(gè)Broker會只配置少數(shù)的幾個(gè)Topic和Partition嗎？如果只能配置幾十個(gè)Topic機(jī)器資源利用率就提升不起來，所以我們的基準(zhǔn)測試就是成百上千的Topic負(fù)載測試。
我們通過不同刻度的負(fù)載來分析和對比系統(tǒng)的穩(wěn)定性情況，吞吐量的變化情況，以及系統(tǒng)在設(shè)計(jì)范圍內(nèi)的最大可能情況，從文檔的附錄里，我們還給出了不同Topic場景下的流量變化情況。通過這些我們就清楚的知道系統(tǒng)在實(shí)際應(yīng)用時(shí)的表現(xiàn)是怎樣： 
4.4 場景四：100個(gè)topic，一入一全量出五份部分過濾出：一份全量Topic的Pull消費(fèi)；過濾消費(fèi)采用5個(gè)不同的消費(fèi)組，從同樣的20個(gè)Topic中過濾出10%消息內(nèi)容
這個(gè)場景反饋的是Apache TubeMQ過濾消費(fèi)對系統(tǒng)的影響，線上業(yè)務(wù)在構(gòu)造Topic的時(shí)候，不會每個(gè)業(yè)務(wù)都會構(gòu)造一個(gè)Topic，很多都是混在同一個(gè)Topic里進(jìn)行數(shù)據(jù)上報(bào)和消費(fèi)，那么就會存在過濾消費(fèi)數(shù)據(jù)的需求。
這個(gè)用例比較好的反饋了客戶端過濾和服務(wù)器端過濾數(shù)據(jù)的差異；同時(shí)，這個(gè)指標(biāo)也反饋出了在過濾消費(fèi)時(shí)，相比全量消費(fèi)，雖然消費(fèi)份數(shù)由2份全量變成了1份全量5份過濾，但系統(tǒng)的吞吐量增加了約5萬的TPS，說明過濾消費(fèi)給系統(tǒng)帶來的負(fù)載壓力要比全量消費(fèi)的低。
4.5 TubeMQ、Kafka數(shù)據(jù)消費(fèi)時(shí)延比對
Kafka端到端時(shí)延是否真如此？似乎和大家用的有出入，有同學(xué)在這篇帖子里有過反饋《如何評價(jià)騰訊開源的消息中間件TubeMQ？》 。
為什么會有差異？因?yàn)槲覀優(yōu)榱颂岣逰afka的吞吐能力，將Kafka的生產(chǎn)配置linger.ms調(diào)整為了200ms，batch.size調(diào)整成了50000字節(jié)，如果我們?nèi)サ暨@2個(gè)設(shè)置，Kafka的端到端時(shí)延和TubeMQ差不多，但其請求TPS又和該測試報(bào)告里給出的測試結(jié)果存在較大的差距，而我們此前已發(fā)布過這個(gè)測試報(bào)告，為了避免不必要的誤會，我們?nèi)匀槐３至诉@個(gè)報(bào)告數(shù)據(jù)，因?yàn)閺奈覀兲峁┑臏y試參數(shù)配置下，數(shù)據(jù)確實(shí)如此： 
這個(gè)問題如果大家感興趣，可以直接在自己環(huán)境驗(yàn)證下，驗(yàn)證下我們的測試結(jié)果及分析，看看是不是如此。
4.6 場景六：調(diào)整Topic配置的內(nèi)存緩存大?。╩emCacheMsgSizeInMB）對吞吐量的影響
這個(gè)場景反饋的是Apache TubeMQ調(diào)整內(nèi)存緩存的大小時(shí)給系統(tǒng)帶來的變化，從數(shù)據(jù)看內(nèi)存塊的大小會影響到TubeMQ的吞吐量。這個(gè)和我們設(shè)計(jì)是符合的，具體多大的量影響又有多大，我們再另外的文檔里介紹。
4.7 場景七：消費(fèi)嚴(yán)重滯后情況下兩系統(tǒng)的表現(xiàn)
磁盤系列的弊端：從這個(gè)測試我們可以看到基于磁盤的MQ都有這個(gè)弊端，磁盤的好處就是成本低，讀寫次數(shù)會比SSD好，在硬件提升前，磁盤有可能會用比較長的時(shí)間；這個(gè)測試也驗(yàn)證了我們最初版本的一個(gè)構(gòu)思，通過SSD來緩存滯后數(shù)據(jù)，以此來換取磁盤滯后讀導(dǎo)致的IO拉升問題。
通過SSD來緩存滯后數(shù)據(jù)這個(gè)思路在《如何評價(jià)騰訊開源的消息中間件TubeMQ？》 里也有過交流，后來我們覺得這樣操作還不如直接擴(kuò)容Broker節(jié)點(diǎn)來的快捷，因而新版本里我們廢棄了轉(zhuǎn)存SSD的操作。
通過這個(gè)測試，我們需要清楚的知道磁盤系發(fā)生后讀的時(shí)候系統(tǒng)表現(xiàn)，及如何處理。
4.8 場景八：評估多機(jī)型情況下兩系統(tǒng)的表現(xiàn)
不同機(jī)型的適應(yīng)面：從這個(gè)測試，我們可以看到TubeMQ在磁盤系里，隨著內(nèi)存、CPU增大，吞吐量會提升很大；而到了SSD機(jī)型時(shí)Kafka反而會好很多。我們分析應(yīng)該與我們的讀取模式有關(guān)，在存儲不是瓶頸的模式下，Kafka的塊讀塊寫會比TubeMQ的塊寫隨機(jī)讀要好不少；從這個(gè)測試也很明確的反饋出，每個(gè)系統(tǒng)都有它的適應(yīng)面，關(guān)鍵是系統(tǒng)的應(yīng)用環(huán)境和場景。
關(guān)于如何分析Apache TubeMQ的Benchmark測試就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。
本文標(biāo)題：如何分析ApacheTubeMQ的Benchmark測試
文章分享：http://ef60e0e.cn/article/pogihc.html
