kafka性能调优解密（三）-- Consumer端

Consumer篇

1  fetch.message.max.bytes

这个参数是Consumer每次发起获取消息请求的时候，会发往给broker端指导broker端每次读取partition日志时的最大消息长度。这个值越大有利于减少日志读取的次数，提升broker端获取数据的速度，但越大占的内存也越大。在读取数据时，BoundedByteBufferReceive.readFrom用来申请读取缓存的总大小（byteBufferAllocate）， 同时这个设置是针对每个分区的，即共需要的内存为fetch.size * partitionNum

1.3 实测分析

1. 个broker 创建10个分区的topic

2. 同时启动Producer与Consumer，一起测试

3. 测试Consumer scoket.receiver.buffer.bytes取值为256k 或者2M， 这两者在不同fetch.message.max.bytes的区别

10G网卡下，10分区，2k数据，发送1000000, ack都为1, N个Producer与N个Consumer一起跑, Consumer每次从队列开始读取数据，10个线程， bufferMemory为32M, Producer默认send buf为128k：

10分区，4k数据，发送1000000, ack都为1, N个Producer与N个Consumer一起跑, Consumer每次从队列开始读取数据，10个线程， bufferMemory为32M, Producer默认send buf为128k:

可以看出无论是2k或者4k数据，fetch.size在1M~8M之间，Consumer性能都是在峰值范围

结论：

1. 需要根据业务最大消息来配置，比如业务最大4M， 这个参数至少配置4M

2. 实测证明，在内存足够的情况下，也不是越大越好。从目前来看1M~8M性能都稳定在峰值附近

2 num.consumer.fetchers

该参数是用于指定Consumer端用于fetcht数据的线程数(fetch threads)，如下图：

Consumer跟根据这个线程个数和Topic的分区数，均匀地分布在这些fetch threads上。增大这些线程能起到一定的提升性能，但是多于分区个数后，就会有线程空闲。

2.3 实测分析

1. 2个broker 创建10个分区的topic

2. 同时启动Producer与Consumer，一起测试

3. 通过指定Consumer不同的fetch threads,查看性能结果

10G网卡下，10分区，2k数据，发送1000000, ack都为1, 10个Producer与10个Consumer一起跑, Consumer每次从队列开始读取数据，bufferMemory为32M：

结论：

1. 从性能上看，10个Consumer线程配10个Fetch 线程，性能最优

2. 10个Fetch线程后面就会有空闲的线程分配不到partition

3  offsets.storage

Kafka会记录offset到zk中。但是，zk client api对zk的频繁写入是一个低效的操作。0.8.2 kafka引入了native offset storage，将offset管理从zk移出，并且可以做到水平扩展。其原理就是利用了kafka的compacted topic，offset以consumer group,topic与partion的组合作为key直接提交到compacted topic中。同时Kafka又在内存中维护了的三元组来维护最新的offset信息，consumer来取最新offset信息的时候直接内存里拿即可。当然，kafka允许你快速的checkpoint最新的offset信息到磁盘上。

3.3 实测分析

1. 2个broker 创建10个分区的topic

2. 同时启动Producer与Consumer，一起测试

3. 在不同的压力下， 查看offsets.storage保存在zk上性能好还是broker上好

10G网卡下，10分区，2k数据，发送1000000, ack都为1, N个Producer与N个Consumer一起跑, Consumer每次从队列开始读取数据，10个线程， bufferMemory为32M, Consumer receiver buffer大小为2M:

从上面的数据来看，存储在zookeeper与存储在kafka，性能峰值相差不

结论：

1.在broker节点数不是很多并且对zk节点写入不大的情况下，这个选项对性能影响不是很大，但以后社区会推用存储在kafka，为了避免以后修改，建议值为kafka

尾声

性能相关的核心参数详解到处就结束了，希望对大家业务应用有帮助。对于应用PUMA或者kafka作为消息总线的用户，应该在实施过程关注过这样的问题：具体业务不同可靠模式下，对于特定硬件及网络，需要多少资源，才能达到业务需要的吞吐量。这个PUMA经过大量实践验证及理论分析，证明可以通过简单测试及公式计算就可以完成业务资源部署评估，相关进一步信息欢迎联系PUMA或持续关注后续的解密，谢谢~

Kafka 应用性能调优

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。