kafka性能测试、性能分析与性能调优
前言:最近在做kafka、mq、redis、fink、kudu等在中间件性能压测,压测kafka的时候参考了这篇文章,大家可以借鉴下!一、测试环境测试使用到三台机器,机器配置如下:共同配置:Intel® Core™ i7-7700 CPU @ 3.60GHz、Cores:4、Threads:232GB内存1000Mb/sec网卡差异化配置2TB、7200rpm、SATA 3.1, 6.0 Gb/s
前言:最近在做kafka、mq、redis、fink、kudu等在中间件性能压测,压测kafka的时候参考了这篇文章,大家可以借鉴下!
一、测试环境
测试使用到三台机器,机器配置如下:
共同配置:
Intel® Core™ i7-7700 CPU @ 3.60GHz、Cores:4、Threads:2
32GB内存
1000Mb/sec网卡
差异化配置
2TB、7200rpm、SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
1TB、7200rpm、SATA 3.1, 6.0Gb/s (current: 6.0 Gb/s)
250G、SSD、SATA3.1, 6.0 Gb/s (current: 6.0 Gb/s)
三台机器操作系统采用centos7,Release版本为7.5.1804。其中两台机器用来搭建kafka集群,另一台机器作为客户机测试。
二、producer吞吐率
本次测试producer的吞吐率,因此不存consumer的消费场景,使用官方提供的测试工具kafka-producer-perf-test.sh来测试。
测试参数:
测试结果:
在2个broker的集群中,partition的分区数为4时,性能最优,但随着partition的增长,吞吐率呈下降区势。同时增加集群中broker数与分区数,可提升吞吐率。
在2个broker的集群中,partition的分区数为4时,以CPU对应的线程数为性能最优,随着生产者线程数的增加,吞吐率呈下降区势。
针对kafka提供的3种压缩算法进行对比,在相同条件下,采用LZ4算法,性能最优。
在设置message.size大小不变的前提下,不断增加batch.size的大小,但小于最大值10000,当处于1000时,性能最优,随着batch.size继续增大,吞吐率下随趋势明显。
其它参数不变,不断增加message.size的大小,即每条消息的大小,吞吐率会急剧下降。消息的大小需按实际业务来度量,在每条消息为3072B时,每秒处理的数据总量最大。
partition
threads
compression
batch.size
message.size
三、consumer吞吐率
本次测试consumer的吞吐率,使用官方提供的测试工具kafka-consumer-perf-test.sh来测试。
测试参数:
测试结果:
在相同的参数配置下,fetchsize从2m至20m变化,在10m上下时性能最优,当然fetch.threads发生变化时,在某一fetch.size上下仍是性能最优。
采用snapyy算法消费性能最优。
获取消息的线程数与实际吞吐率影响不大。
第一次测试数据下图:
第二次测试数据下图:
在增加分区数与消费线程数时,在小于3个分区时,3个分区与3个消费线程性能最优,在其他条件不改变的前提下,再进一步增加分区数与消费程数时,实际吞吐量变化不大。
生产者与消费者同时写入与读取,不同压缩算法,snapyy方式性能最优,相比于单独消费场景,性能下降较大。
fetch.size
compression
fetch.threads
partitions与threads
producer与consume同时写入与读取
五、配置建议
基于kafka的高度可配置的特性,可以应用到不同的业务场景,比如,实时性较强的跟踪用户在页面上的行为动作、实时性不高但可靠性很高的信用卡支付操作的处理等。
可靠性配置:
复制系数,针对topic级别的配置参数是replication.factor,以本次测试为例,有3个broker实例,建议合理的复制系数为1-3,以3为例,也就是每个分区会被3个broker各复制一次,即每个broker保存一个分区,即使在2个broker失效的情况下,仍然可以向topic写入消息或从topic读取消息。总结如下:
如果复制系数为N,那么在N-1个broker失效的情况下,仍然具备读写能力,因此更高的复制系数会带来更高的可靠性,但另一方面,N个复制系数需要至少N个broker,而且会有N份数据副本(副本包含leader与follower)。
不完全的leader选举,unclean.leader.election.enable在broker级别上进行配置,默认值为true(仅在当前版本为true,后续高版本为false),官方在kafka高版本发行时,修改了这个默认值,暂时理解为官网的推荐设置,但对于实时性较高的业务,比如实时统计用户访问量的分析,一般会启用这个配置,即设置为true,但对于可靠性较高的业务,比如银行的业务,宁可花费几分钟或几个小时的延时后再处理像信用卡支付的业务,也不会冒险处理错误的消息。因此,按真实的业务场景来设置即为合理。
最少同步副本,min.insync.replicas默认是1,本次测试中采用了3个broker,因此这个值可以设置1-3,当然如果选择3时,即为最少要同步3个副本才可以向分区写入数据,即为真正的提交,需要注意的是如果有1个broker出现问题,无法同步副本,那么剩下的broker就会停止生产者的所有请求,并抛出NotEnouqhReplicasException给生产者,直至问题broker恢复,此时消费者可以正常读取消息。
producer发送确认,生产者可以选择3种不同模式的确认,acks为0时,只要生产者把消息发送出去,即认为已成功写入broker,这种模式下运行速度非常快,吞吐率和带宽利用率非常高,不过采用这种模式风险较高,容易丢失一些消息。一般压力测试都是基于这个模式的。即使实时性较高的系统,也不建议采用该模式。
acks为1时,即为leader收到消息并写入分区数据文件(不一定同步到磁盘)后,提交成功,返回确认响应。
acks为-1或all时,即leader收到消息后,会等待所有同步副本都收到消息,才会返回确认响应。
producer失败重试参数,当生产者没有收到成功的响应,重试发送次数,当前版本默认为0,根据实际业务来设置该参数,并非越大越好,也不建议设置为0,生产者收到的错误会包括2种,一种是可恢复性错误,一种是不可恢复性错误,遇到可恢复性的错误时,可以通过重试来解决,不可恢复性错误,只能由开发者手动处理。但由于网络原因造成的无法收到成功响应,此时如果无限次的重试发送,会造成分区内存在重复消息,增加了消费者读取消息时的业务处理的复杂度。因此分析实际业务场景,谨慎设置。
consumer auto.offset.reset,默认值为latest,即在没有offset时,消费者会从分区的末尾开始读取数据,减少读取重复消息的可能性,但可能会错过一些消息。设置为earliest,当出现offset不存在的情况时,从分区的开始位置读取数据,这样会读取大量重复消息,由消费端的业务逻辑来处理重复消息。增加了业务的复杂度。
consumer auto.commit.interval.ms,默认值为5000ms,即5秒提交一次,可以通过该参数来设置提交的频度,一般来说,提交频度越高,越会带来更高的系统开销,可靠性也随之提高。
1、实时类业务
实时类业务,把零延时作为第一考虑因素,比如聊天室、会议室、直播类似系统等,在保证最小延时的基础上,适当设置可靠性相关参数。建议可靠性参数如下:
replication.factor:1
unclean.leader.election.enable:true
min.insync.replicas:1
acks:0
retries:0
2、近实时类业务
即可接受一定范围内的延时,比如实时计算用户访问量等类似web监控类业务,在保证最小延时的基础上,适当设置可靠性相关参数。建议可靠性参数如下:
replication.factor:2
unclean.leader.election.enable:true
min.insync.replicas:2
acks:1
retries:1/2/3
consumer auto.commit.interval.ms:1000ms
consumer auto.offset.reset:latest
3、非实时类业务
非实时类业务,即可以允许一定时间的延时,从而来保证系统更高的可靠性。以3个broker以例,建议可靠性参数如下:
replication.factor:3
unclean.leader.election.enable:false
min.insync.replicas:2/3
acks:all
retries:MAX_INT
consumer auto.commit.interval.ms:500ms
consumer auto.offset.reset:earliest
六、疑问解答与加群学习交流
更多推荐
所有评论(0)