1. 前言：
我们在应用Apache TubeMQ时，该如何配置它的参数才能使系统的性能达到最优？有哪些坑会影响到系统的性能我们要提前关注？生产和消费份数对整体的入出流量影响情况是怎样？
本篇文档引用的是2018年测试数据，但不影响大家对些问题的理解和掌握。通过调整各个参数值来获取其对TubeMQ系统性能的影响情况后，大家基本上就清楚了各个因子对系统性能的影响，方便大家基于此展开相关的线上操作。大家也看得到各个因子的组合非常多，应用前也可以按照我们方案进行复核和改进，如果有获取到更好的参数配比，欢迎给贡献社区。
2. 测试总结：
通过对测试数据分析，我们获取到对Apache TubeMQ线上运营有指导意义的信息：
- 在万兆机上包长1K大小时，TubeMQ的单个存储实例配置2M内存Buffer缓存、3K的磁盘刷盘条数，入流量就可以达到1G以上；
- 通过扩容Topic的存储实例个数可以显著提升该Topic的入流量，但个数不是越多越好；增加Topic的Partition个数并不能带来入流量提升；
- Topic的消费份数直接影响生产能力；
- Topic的入流量很大时，需要通过增加Topic的Partition个数来提高消费并行度，不然就会出现消费追不上生产问题；不间断生产消费时，Topic至少要配置4个分区消费才能追平生产，考虑数据处理时间，实际线上运营时，对于大业务我们需要增加Partition个数来提升消费速度；
- 磁盘IO-Util对生产和消费有直接影响，线上运营时，我们要避免业务长期大比例滞后消费的情况出现。
3. 生产消费影响因子测试详情：
3.1 纯生产性能摸底：
3.1.1 单Topic单Partition 纯生产 最佳入流量测试
数据解读： 这项测试固定了Topic和Partition的个数，以及读写IO线程、数据刷盘时间的间隔，来分析内存Buffer大小、文件刷盘条数大小对Topic的吞吐量影响情况。
从测试情况看，内存Buffer的大小，文件的刷盘频率（刷盘条数和刷盘间隔）对生产有直接的影响，内存Buffer越大吞吐量越大，文件刷盘频率越低吞吐越大；内存Buffer在2M，文件刷盘按3K条配置时，Broker可以满足单Topic 1G的入流量需求。
3.1.2 单Topic单Partition 纯生产 读写IO线程数影响测试
数据解读： 从测试情况，读写IO线程的数量对Topic的生产性能没有很直接的影响，读写IO线程并不是越多越好。
该项在 3.1 单Topic单Partition 纯生产性能测试 1 基础上，验证了随着读写IO线程数变动，调整内存Buffer大小和磁盘刷盘条数大小，对吞吐量带来的影响情况。
从测试对比情况看，读写线程IO的个数对Topic的性能有稍微的影响，但影响能力不如内存Buffer大小及磁盘刷盘条数形成的影响，比如A.2-1-1 相对于 A.1-6-1、A.2-1-2 相对于 A.1-3-4性能随着读写IO线程的减少入流量有所减少，但A.2-2-2相对于A.2-1-2只调整了内存Buffer多8M，就可以提升入流量100M。
3.1.3 单Topic单Partition 纯生产 内存Buffer影响测试
数据解读： 从测试情况，磁盘刷盘条数对系统性能影响最直接，内存Buffer大小的调整对性能有影响，但在一定量级下效果也很有限，说明磁盘是系统性能的瓶颈所在。
该项在3.1.1，3.1.2基础上进行的参数调整测试，从图可以看到，A.4-1-1对比A.2-1-2参数只有内存Buffer变化了，相比起来入流量的增长很有限。
3.1.4 单Topic单Partition 纯生产 实例个数影响测试
数据解读： 从测试情况，实例个数可以有效的提升Topic的入流量，但最终瓶颈还是在磁盘，随着写入磁盘的量超过磁盘承受力时，整体入流量呈下降趋势。
从测试结果看，在单Topic单实例不满足需求的情况下，单机最多配置不超10个实例就可以把系统的能力完全榨干。
3.2 边生产边消费性能摸底：
3.2.1 单Topic下不同Partiton数对消费的影响
数据解读： 从该项场景的测试数据我们可以得到几个信息：
- 消费能够对生产形成实质的影响，并且随着消费份数的增多，生产能力处于下降趋势；
- Topic的Partiton数决定数据能否被快速消费完，分区数并不是越多越好；
- Topic的Partition数在纯数据拉取前提下，大概4个分区就能追平生产速度且不滞后；
3.2.2 影响消费能力的因素分析
数据解读： 该组测试主要是分析消费速度影响因子，从测试情况看，磁盘IO-util对消费速度影响最大，少量几个客户端的滞后读就可以把磁盘IO-Util给拉爆，对齐实际运营中要防止业务长期滞后读的情况。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
