Kafka性能基准测试

许久不见,最近工作有点忙,没来得及更博

这段时间对几个大数据框架做了BenchMark(基准测试),待整理后,会分享出来


关于BenchMark

简单的来说,BenchMark是一个系统性能的测量工作,也可以看做是一种评价方式

主要测试负载的执行时间、传输速度、吞吐量、资源占用率等

对系统进行性能基准测试后,将得到的基准数据作为性能指标的参照物,可用于以下场景

1.任意一项变更为系统产生的影响

修改某项配置参数后(启用某项参数),系统的变化情况

2.系统环境的变更对系统性能产生的影响

3.在相同场景下,不同框架的系统性能表现的差异

一些大数据BenchMark工具:

1.Hibench由Intel开发的针对Hadoop的基准测试工具

2.Berkeley BigDataBench:随着Spark的推出,由AMPLab开发的一套大数据基准测试工具

3.Hadoop GridMix:Hadoop自带的Benchmark,作为Hadoop自带的测试工具使用方便、负载经典,应用广泛

除此之外,有些大型的框架会自带BenchMark工具,方便进行测试


了解BenchMark后,就要开始今天的文章:Kafka基准测

分别实用Kafka自带的基准工具对Kafka Producer/Consumer进行性能基准测试

Kafka版本Scala_2.11-1.1.0

服务器配置

    三台服务器

  • IntelXeon 3.2 GHz * 12 cores
  • 251GB RAM
  • Red Hat 7.5
  • 10 Gb Ethernet

Kafka Producer基准测试

测试背景

需要对Kafka Producer在不同参数下的性能

性能指标

平均吞吐量(条/秒)、平均延时(毫秒)、平均吞吐率速率(MB/秒)

测试方法

使用Kafka基准测试工具kafka-producer-perf进行测试

这个工具位于kafka/bin目录下

这里仅简单介绍一下该工具的一些必要参数

./kafka-producer-perf-test.sh 
--topic 指定topic
--num-records	指定生产数据量
--throughtput	指定吞吐量
--record-size   record数据大小
--producer-props key=value	指定producer配置

一个实例如下:

./kafka-producer-perf-test.sh 
--topic louisvv
--num-records 5000000
--throughtput -1
--record-size 200
--producer-props bootstrap.servers=192.168.1.20:9092,192.168.1.21:9092,192.168.1.22:9092 acks=1

测试参数

除了测试acks以及replicationkafka producer的吞吐量外,还对其他参数进行测试。

参数列表如下

参数 参数说明
acks 数据发送确认机制
batch-size 批处理大小
record-size 数据长度
num-records 数据条数
replication topic备份数
partition topic分区数

默认设置

1.5000万数据测试结果为准,该结果更加具有代表性

2.测试其他参数时,默认设置acks=1partition数为5replication数为2

测试结果分析

acks

分别设置kafka producer acks参数为01all,进行测试

测试结果如下:

数据(万) acks 平均吞吐量
(条/秒)
平均延时(毫秒) 平均吞吐速率(MB/S)
5000 0 627045.7367 250.83 119.6
5000 1 771771.6791 202.89 147.2
5000 all 219516.7996 721.08 41.87

图表如下:

 

结论:

1.在不考虑数据丢失等情况下,设置acks=1时,吞吐量最大,约为acks=01.23倍,约为acks=all3.51

2.保证数据不丢失的情况下,需要选择使用acks=all,但吞吐量会明显降低

replication数

设置Kafkareplication-factor23,进行测试

测试结果如下:

数据(万) replication 平均吞吐量
(条/秒)
平均延时(毫秒) 平均吞吐速率(MB/S)
5000 2 627045.7367 250.83 119.6
5000 3 584692.744 269.28 111.52

图表如下:

结论:

replication数越多,吞吐量越低

batch大小

分别设置Kafkabatch-size批处理大小为10005000800010000100000500000550000600000进行测试

测试结果:

数据
(万)
acks batch大小 平均吞吐量
(条/秒)
平均延时(毫秒) 平均吞吐速率(MB/S)
5000 1 1000 63177.41989 2116.31 12.05
5000 1 5000 284257.2642 539.31 54.22
5000 1 8000 416545.1743 369.21 79.45
5000 1 10000 480833.9584 324.23 91.71
5000 1 20000 635332.0881 246.09 121.18
5000 1 50000 949180.8569 158.87 181.04
5000 1 100000 1167051.794 112.02 222.6
5000 1 500000 1238696.891 78.08 236.26
5000 1 550000 1206127.126 85.54 230.05
5000 1 600000 1139575.166 85.97 217.36

折线图如下:

结论:

batch-size大小达到阈值时,会达到吞吐量峰值

batch-size大小超过阈值后,并不会提升性能

压缩

分别设置Kafka的压缩格式为lz4snappygzip,进行测试

测试结果:

数据
(万)
压缩格式 平均吞吐量(条/秒) 平均延时(毫秒) 平均吞吐速率(MB/S)
5000 lz4 1203833.004 6.6 229.61
5000 snappy 1310719.06 7.35 250
5000 gzip 198008.8233 4.29 37.77
5000 627045.7367 250.83 119.6

条形图如下:

结论:

1.使用snappy压缩格式,吞吐量最高

2.启用压缩的平均延时远小于不启用压缩的平均延时

3.Gzip压缩格式,吞吐量最低,比默认不使用压缩吞吐量还低

record-size

分别设置record-size大小为1002005001000进行测试

测试结果:

数据
(万)
消息长度
(bytes)
平均吞吐量(条/秒) 平均延时(毫秒) 平均吞吐速率(MB/S)
5000 100 1047032.709 274.06 99.85
5000 200 627045.7367 250.83 119.6
5000 500 270552.5224 240.7 129.01
5000 1000 140846.6574 231.52 134.32

图表如下:

结论:

随着消息长度的增加,吞吐量逐渐减小,但平均吞吐速率会增大

分区

分别设置partition135进行测试

数据
(万)
平均吞吐量(条/秒) 平均延时(毫秒) 平均吞吐速率(MB/S)
5000w 627045.7367 250.83 119.6
5000w 581320.9938 271.2 110.88
5000w 351456.7884 451.9 67.04

图表如下:

结论:

分区数越多,吞吐量越大


Kafka Consumer吞吐量测试

测试背景

需要对Kafka Consumer在不同参数下的吞吐量

性能指标

平均吞吐量(条/秒)、平均延时(毫秒)、平均吞吐率速率(MB/秒)

测试方法

使用Kafka基准测试工具kafka-consumer-perf进行测试

这个工具位于kafka/bin目录下

这里仅简单介绍一下该工具的一些必要参数

./kafka-consumer-perf-test.sh
--topic 指定topic
--threads 指定线程数
--messages 指定消费数据条数
--broker-list kafka broker列表

一个实例如下:

./kafka-consumer-perf-test.sh
--topic louisvv
--threads 1
--messages 5000000
--broker-list 192.168.1.20:9092,192.168.1.21:9092,192.168.1.22:9092

测试参数

测试参数列表如下

注意:replication并不会影响consumer的吞吐率,因为consumer只会从每个partition的leader读数据,而与replicaiton无关

参数 参数说明
threads 线程数
fetch-size 拉取数据大小
num-records 数据条数
replication topic备份数
partition topic分区数

默认设置

1.以5000万数据测试结果为准,该结果更加具有代表性默认设置

2.测试其他参数时,partition数为5,replication数为2

测试结果分析

分区

分别设置partition135进行测试

测试结果:

数据
(万)
partition 平均吞吐量(条/秒) 平均吞吐速率(MB/S)
5000 1 2371936.86 452.4103
5000 3 2907150.765 554.495
5000 5 3238761.498 600.7541

图表如下:

结论:

分区数越多,吞吐量越高

fetch-size

分别设置record-size大小为50000100000200000300000400000450000500000550000600000行测试

测试结果如下:

数据
(万)
fetch-size 平均吞吐量
(条/秒)
平均吞吐速率
(MB/S)
5000 50000 1400249.552 259.3288
5000 100000 1792191.871 332.445
5000 200000 2990615.049 552.0419
5000 300000 3053828.071 564.4809
5000 400000 3373830.567 624.0051
5000 450000 3593015.45 665.9499
5000 500000 3651258.507 676.8822
5000 550000 3246984.869 602.0835
5000 600000 3069380.54 569.1356

折线图如下:

结论:

fetch-size大小达到一定阈值时,会达到吞吐量峰值,当fetch-size超过阈值后,不会提升性能

replication

设置Kafkareplication-factor23,进行测试

测试结果如下:

数据
(万)
replication 平均吞吐量
(条/秒)
平均吞吐速率
(MB/S)
5000 3 3070336.69 585.6202
5000 2 3327792.28 617.277

图表如下:

结论:

分区数越少,吞吐量越大

线程数

设置Kafkaconsumer线程数为135102030,进行测试

测试结果:

数据
(万)
threads 平均吞吐量
(条/秒)
平均吞吐速率
(MB/S)
5000 1 3238761.498 600.7541
5000 3 3398817.212 630.415
5000 5 3229765.519 599.0854
5000 10 3234152.652 599.9312
5000 20 3414602.677 633.3892
5000 30 3367910.548 624.6824
5000 40 3392590.582 629.2721

图表如下:


结论:

提高consumer线程数,对吞吐量性能影响并不明显


注意:

1.不同环境下,测试结果不相同,请以实际情况为准

2.测试结果可能存在误差,请谅解,请以实际情况为准


欢迎大家指出问题

亲,看完了点个赞呀!!

赫墨拉

我是一个喜爱大数据的小菜鸡,这里是我分享我的成长和经历的博客

You may also like...

5 Responses

  1. 匿名说道:

    大佬 求带飞

  2. 匿名说道:

    求大佬带我飞

  3. 匿名说道:

    帖子写的很不错!

  4. 匿名说道:

    分区数量并非越大越好

发表评论

电子邮件地址不会被公开。