原文地址:http://www.louisvv.com/archives/2127.html
许久不见,最近工作有点忙,没来得及更博
这段时间对几个大数据框架做了BenchMark(基准测试),待整理后,会分享出来
关于BenchMark
简单的来说,BenchMark是一个系统性能的测量工作,也可以看做是一种评价方式
主要测试负载的执行时间、传输速度、吞吐量、资源占用率等
对系统进行性能基准测试后,将得到的基准数据作为性能指标的参照物,可用于以下场景
1.任意一项变更为系统产生的影响
修改某项配置参数后(启用某项参数),系统的变化情况
2.系统环境的变更对系统性能产生的影响
3.在相同场景下,不同框架的系统性能表现的差异
![](/qrcode.jpg)
一些大数据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目录下
这里仅简单介绍一下该工具的一些必要参数
<span style="color:#000000">./kafka-producer-perf-test.sh
--topic 指定topic
--num-records 指定生产数据量
--throughtput 指定吞吐量
--record-size record数据大小
--producer-props key=value 指定producer配置</span>
一个实例如下:
<span style="color:#000000">./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</span>
测试参数
除了测试acks以及replication对kafka producer的吞吐量外,还对其他参数进行测试。
参数列表如下
参数 | 参数说明 |
acks | 数据发送确认机制 |
batch-size | 批处理大小 |
record-size | 数据长度 |
num-records | 数据条数 |
replication | topic备份数 |
partition | topic分区数 |
默认设置
1.以5000万数据测试结果为准,该结果更加具有代表性
2.测试其他参数时,默认设置acks=1,partition数为5,replication数为2
测试结果分析
acks
分别设置kafka producer acks参数为0、1、all,进行测试
测试结果如下:
数据(万) | 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=0的1.23倍,约为acks=all的3.51倍
2.在保证数据不丢失的情况下,需要选择使用acks=all,但吞吐量会明显降低
replication数
设置Kafka的replication-factor为2、3,进行测试
测试结果如下:
数据(万) | replication | 平均吞吐量 (条/秒) |
平均延时(毫秒) | 平均吞吐速率(MB/S) |
5000 | 2 | 627045.7367 | 250.83 | 119.6 |
5000 | 3 | 584692.744 | 269.28 | 111.52 |
图表如下:
结论:
replication数越多,吞吐量越低
batch大小
分别设置Kafka的batch-size批处理大小为1000、5000、8000、10000、100000、500000、550000、600000进行测试
测试结果:
数据 (万) |
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的压缩格式为lz4、snappy、gzip,进行测试
测试结果:
数据 (万) |
压缩格式 | 平均吞吐量(条/秒) | 平均延时(毫秒) | 平均吞吐速率(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大小为100、200、500、1000进行测试
测试结果:
数据 (万) |
消息长度 (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 |
图表如下:
结论:
随着消息长度的增加,吞吐量逐渐减小,但平均吞吐速率会增大
分区
分别设置partition为1、3、5进行测试
数据 (万) |
平均吞吐量(条/秒) | 平均延时(毫秒) | 平均吞吐速率(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目录下
这里仅简单介绍一下该工具的一些必要参数
<span style="color:#000000">./kafka-consumer-perf-test.sh
--topic 指定topic
--threads 指定线程数
--messages 指定消费数据条数
--broker-list kafka broker列表</span>
一个实例如下:
<span style="color:#000000">./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</span>
测试参数
测试参数列表如下
注意:replication并不会影响consumer的吞吐率,因为consumer只会从每个partition的leader读数据,而与replicaiton无关
参数 | 参数说明 |
threads | 线程数 |
fetch-size | 拉取数据大小 |
num-records | 数据条数 |
replication | topic备份数 |
partition | topic分区数 |
默认设置
1.以5000万数据测试结果为准,该结果更加具有代表性默认设置
2.测试其他参数时,partition数为5,replication数为2
测试结果分析
分区
分别设置partition为1、3、5进行测试
测试结果:
数据 (万) |
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大小为50000、100000、200000、300000、400000、450000、500000、550000、600000行测试
测试结果如下:
数据 (万) |
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
设置Kafka的replication-factor为2、3,进行测试
测试结果如下:
数据 (万) |
replication | 平均吞吐量 (条/秒) |
平均吞吐速率 (MB/S) |
5000 | 3 | 3070336.69 | 585.6202 |
5000 | 2 | 3327792.28 | 617.277 |
图表如下:
结论:
分区数越少,吞吐量越大
线程数
设置Kafka的consumer线程数为1、3、5、10、20、30,进行测试
测试结果:
数据 (万) |
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.测试结果可能存在误差,请谅解,请以实际情况为准
欢迎大家指出问题
亲,看完了点个赞呀!!