13518219792
这篇文章将为大家详细讲解有关如何分析Apache TubeMQ的Benchmark测试，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
为环翠等地区用户提供了全套网页设计制作服务，及环翠网站建设行业解决方案。主营业务为成都网站建设、网站设计、环翠网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
Apache TubeMQ的Benchmark测试项为什么要这么设计？每一个场景反馈了哪些内容，是否是为了放大TubeMQ的优点而做的针对性场景定义？和其他MQ的Benchmark测试用例相比异同点在哪里？这篇我们一起来做TubeMQ的Benchmark测试项及测试结果的解读。
TubeMQ的Benchmark测试项及测试结果报告tubemq_perf_test_vs_Kafka包含在项目的website里没有直接显现在页面上展示，主要是开源时团队内部做过讨论，无意去做PK赛，所以需要大家通过链接直接访问该页面。
在tubemq_perf_test_vs_Kafka这篇文档里公布的内容仅测试场景就有8项，每一项里又包含多个测试条目，整体合起来有近百项，实际的测试报告要比这个更详尽，而公布出来的测试项和测试结果已经可以让大家很清晰的了解TubeMQ的实际情况。
TubeMQ最新版本的测试数据一定是要比开源初期做的这份数据更好一点，只是因为最初的测试结果已发表没有必要花时间和资源来调整这些内容，大家可以在了解TubeMQ的Benchmark测试项的构思后进行更有针对性的分析和复核，来验证它的真实性。
在设计Apache TubeMQ这份Benchmark测试项时主要考虑了这几点：系统核心设计方案的长处和短处是什么，在应用时它的边界值在哪里？真实环境里我们会怎么使用这套系统，对应配置的调整会给系统带来的影响是怎样？随着负载增加，系统的指标趋势在设计容许的限度范围内表现情况是怎样？
测试报告里的每个测试场景已经按照【场景，结论，数据】的方式给出，并给出了我们的各个指标视图，这里我们仍然按照【场景，数据解读】的方式给出，便于大家的查看和参考。
通过这个测试项，大家可以获得一个基准信息，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作为基准，不长也不短，会比较符合系统上线后的实际使用情况。
从这个表格里，我们可以获得的几个信息：
场景一里虽然Apache TubeMQ的单存储实例的吞吐能力不如Kafka的单Parititon能力，但存储实例在4个左右时会追平Kafka同等的配置；
吞吐能力与存储实例数的关系，从1到10，TubeMQ的吞吐量有增加趋势，而Kafka呈现下降趋势；
调整TubeMQ里消费者的消费方式（qryPriorityId，消费优先级ID），系统的吞吐能力会呈现出不一样的变化，线上可以根据实际的运营情况调整消费组的消费能力，进行差异化服务同时提升系统单位资源下的吞吐能力。
为什么要测试这么多的Topic：有同学表达过这个疑惑，我们为什么不像其他MQ的Benchmark测试项样，采用单Topic多Partiton，或者几十个Topic的测试呢？
基于线上实际应用需要：TubeMQ的现网上每个配置的Topic动辄几十上百，而我们设计容量是1000个，我们要通过这个场景获得系统随着Topic数增加而呈现出来的负载曲线，所以几个或者几十个Topic是不太满足我们实际需求的。
实际上目前各个MQ所做的Benchmark测试项不太符合大家的实际系统应用情况，特别是在大数据场景里，试想，我们一个集群动辄几十台机器，每个Broker会只配置少数的几个Topic和Partition吗？如果只能配置几十个Topic机器资源利用率就提升不起来，所以我们的基准测试就是成百上千的Topic负载测试。
我们通过不同刻度的负载来分析和对比系统的稳定性情况，吞吐量的变化情况，以及系统在设计范围内的最大可能情况，从文档的附录里，我们还给出了不同Topic场景下的流量变化情况。通过这些我们就清楚的知道系统在实际应用时的表现是怎样： 
这个场景反馈的是Apache TubeMQ过滤消费对系统的影响，线上业务在构造Topic的时候，不会每个业务都会构造一个Topic，很多都是混在同一个Topic里进行数据上报和消费，那么就会存在过滤消费数据的需求。
这个用例比较好的反馈了客户端过滤和服务器端过滤数据的差异；同时，这个指标也反馈出了在过滤消费时，相比全量消费，虽然消费份数由2份全量变成了1份全量5份过滤，但系统的吞吐量增加了约5万的TPS，说明过滤消费给系统带来的负载压力要比全量消费的低。
Kafka端到端时延是否真如此？似乎和大家用的有出入，有同学在这篇帖子里有过反馈《如何评价腾讯开源的消息中间件TubeMQ？》 。
为什么会有差异？因为我们为了提高Kafka的吞吐能力，将Kafka的生产配置linger.ms调整为了200ms，batch.size调整成了50000字节，如果我们去掉这2个设置，Kafka的端到端时延和TubeMQ差不多，但其请求TPS又和该测试报告里给出的测试结果存在较大的差距，而我们此前已发布过这个测试报告，为了避免不必要的误会，我们仍然保持了这个报告数据，因为从我们提供的测试参数配置下，数据确实如此： 
这个问题如果大家感兴趣，可以直接在自己环境验证下，验证下我们的测试结果及分析，看看是不是如此。
这个场景反馈的是Apache TubeMQ调整内存缓存的大小时给系统带来的变化，从数据看内存块的大小会影响到TubeMQ的吞吐量。这个和我们设计是符合的，具体多大的量影响又有多大，我们再另外的文档里介绍。
磁盘系列的弊端：从这个测试我们可以看到基于磁盘的MQ都有这个弊端，磁盘的好处就是成本低，读写次数会比SSD好，在硬件提升前，磁盘有可能会用比较长的时间；这个测试也验证了我们最初版本的一个构思，通过SSD来缓存滞后数据，以此来换取磁盘滞后读导致的IO拉升问题。
通过SSD来缓存滞后数据这个思路在《如何评价腾讯开源的消息中间件TubeMQ？》 里也有过交流，后来我们觉得这样操作还不如直接扩容Broker节点来的快捷，因而新版本里我们废弃了转存SSD的操作。
通过这个测试，我们需要清楚的知道磁盘系发生后读的时候系统表现，及如何处理。
不同机型的适应面：从这个测试，我们可以看到TubeMQ在磁盘系里，随着内存、CPU增大，吞吐量会提升很大；而到了SSD机型时Kafka反而会好很多。我们分析应该与我们的读取模式有关，在存储不是瓶颈的模式下，Kafka的块读块写会比TubeMQ的块写随机读要好不少；从这个测试也很明确的反馈出，每个系统都有它的适应面，关键是系统的应用环境和场景。
关于如何分析Apache TubeMQ的Benchmark测试就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
