kafka测试工具_技术干货 | 怎么做Kafka的压力测试(实操篇)

什么是Kafka?

Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在它可以处理消费者规模的网站中的所有动作流数据。简单而言它就是一个消息缓存池,既可以往其中插数据(Producer),也可以从其中取数据(Consumer)。

Kafka通常以集群的方式进行部署使用,每一个Kafka节点称为一个Broker。Kafka中会有很多个消息队列,每个消息队列称为一个topic。每个Topic也会分成很多Partition,分别存储在每个Broker上面。

Kafka的broker信息以及会话偏移量存储在Zookeeper中,当某一topic配置replication属性时,Zookeeper还会决定哪一个Broker成为特定Partition的Leader。

84729e40a97948d9fb3fb2bfc3747552.png

Kafka的架构

Kafka性能测试内容

性能测试内容:

kafka的测试主要分为producer端的吞吐量,consumer端的吞吐量,以及判断影响两者的因素。在实际测试环境中,需根据具体情况调整测试的数据量与参数。

性能测试工具:

我们使用Kafka自带的性能测试工具完成本次测试,当安装了Apache 版本的Kafka时,该测试工具的位置在安装目录的bin目录下;当安装了CDH版本的Kafka时,该测试工具一般位于Kafka Parcel路径下,默认位置为:/opt/cloudera/parcels/KAFKA/lib/kafka/bin。

这里我们用到的测试工具为:

kafka-producer-perf-test.sh  (生产端)

kafka-consumer-perf-test.sh  (消费端)

性能测试环境:

三台同样的虚拟机作为kafka broker,IP地址为192.168.1.81-192.168.1.83,配置如下:

11feb8aab2415630e4ad46f69700617a.gif 7069d6d58b8796b80f000ed69495bbc1.gif

CPU       内存       磁盘 

4core     16G       100G 

Producer端性能测试

a.Partition与速率的关系

方法:

建立两个topic, 两个topic除了partition数量不一致外其他参数完全一致,使用kafka-producer-perf-test.sh进行测试。

过程:

首先建立两个topic,分别为test_part1与test_part2:

kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test_part1 --partitions 1 --replication-factor 1

kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test_part2 --partitions 5 --replication-factor 1

test_part1进行测试跑批:

kafka-producer-perf-test.sh --topic test_part1 --num-records 2000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092 

运行结果:

2000000 records sent, 136211.945788 records/sec (25.98 MB/sec), 1002.59 ms avg latency, 2559.00 ms max latency, 801 ms 50th, 2271 ms 95th, 2538 ms 99th, 2553 ms 99.9th.

test_part2进行测试跑批:

kafka-producer-perf-test.sh --topic test_part2 --num-records 2000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092 

运行结果:

2000000 records sent, 187529.301453 records/sec (35.77 MB/sec), 520.00 ms avg latency, 2196.00 ms max latency, 336 ms 50th, 1922 ms 95th, 2159 ms 99th, 2190 ms 99.9th.

结论:Producer端传输效率和partition数成正比。

b.Replication与速率的关系

方法:

首先建立两个topic, 两个topic除了replication数量不一致外其他参数完全一致,使用kafka-producer-perf-test.sh进行测试。

过程:

首先建立两个topic,分别为test_rep1与test_rep2:

kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test_rep1 --partitions 1 --replication-factor 1

kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test_rep2 --partitions 1 --replication-factor 3 

test_rep1进行跑批测试:

kafka-producer-perf-test.sh --topic test_rep1 --num-records 2000000 --record-size 

运行结果:

2000000 records sent, 217438.573603 records/sec (41.47 MB/sec), 610.43 ms avg latency, 1387.00 ms max latency, 497 ms 50th, 1284 ms 95th, 1341 ms 99th, 1386 ms 99.9th.

test_rep2进行跑批测试:

kafka-producer-perf-test.sh --topic test_rep2 --num-records 2000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092 

运行结果:

2000000 records sent, 103423.311614 records/sec (19.73 MB/sec), 1353.03 ms avg latency, 4050.00 ms max latency, 1213 ms 50th, 3042 ms 95th, 3998 ms 99th, 4047 ms 99.9th

结论:Producer端传输效率和replication数量成反比。

C.传输的数据记录大小与速率的关系

方法:

向一个topic写入大小不同的数据记录,检验是否对速率有影响。

过程:

首先建立一个test topic:

kafka-topics.sh --zookeeper 192.168.1.81:2181 --create --topic test --partitions 3 --replication-factor 3 

使用小数据块跑批:

kafka-producer-perf-test.sh --topic test --num-records 1000000 --record-size 200 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092 

运行结果:

1000000 records sent, 149231.457991 records/sec (28.46 MB/sec), 814.24 ms avg latency, 1334.00 ms max latency, 810 ms 50th, 1290 ms 95th, 1327 ms 99th, 1333 ms 99.9th.

使用大数据块跑批:

kafka-producer-perf-test.sh --topic test --num-records 1000000 --record-size 2048 --throughput 300000 --producer-props bootstrap.servers=192.168.1.82:9092 

运行结果:

1000000 records sent, 22161.155926 records/sec (43.28 MB/sec), 637.75 ms avg latency, 1598.00 ms max latency, 576 ms 50th, 959 ms 95th, 1547 ms 99th, 1580 ms 99.9th.

结论:Producer端传输数量和单条记录大小成正比。

Customer端性能测试

由于kafka-consumer-perf-test.sh返回结果并不像producer端那么简洁易懂,这里解释一下,这个命令会返回类似以下的结果:

2019-11-18 13:47:53:297, 2019-11-18 13:47:55:078, 190.7349, 107.0943, 1000000, 561482.3133 

总共六个参数:

第一个是开始时间;

第二个是结束时间;

第三个是本次消费了多少MB数据;

第四个是本次消费的速率MB/S;

第五个是总的消费数据条数;

第六个是每秒消费数据条数。

a.Partition与速率的关系

方法:

首先建立两个topic, 两个topic除了partition数量不一致外其他参数完全一致,使用kafka-consumer-perf-test.sh进行测试。

过程:

建立topic,这里沿用Customer端测试过程中建立的test_part1和test_part2.

test_part1进行跑批测试:

kafka-consumer-perf-test.sh --topic test_part1 --messages 1000000 --threads 1  --num-fetch-threads 1 --zookeeper 192.168.1.81:2181 

运行结果:

2018-12-18 13:47:53:297, 2018-12-18 13:47:55:078, 190.7349, 107.0943, 1000000, 561482.3133

test_part2进行跑批测试:

kafka-consumer-perf-test.sh --topic test_part2 --messages 1000000 --threads 1  --num-fetch-threads 1 --zookeeper 192.168.1.81:2181 

运行结果:

2018-12-18 13:51:43:887, 2018-12-18 13:51:45:619, 190.7349, 110.1241, 1000000, 577367.2055

结论:Customer端消费效率和partitions数成正比(但影响不大)。

b.Threads与速率的关系

方法:

在一个topic中消费相同的数据,使用不同的threads,比较速率大小。

过程:

建立Topic,这里沿用Customer端测试过程中建立过的test。

使用一个线程消费时:

kafka-consumer-perf-test.sh --topic test --messages 500000 --threads 1  --num-fetch-threads 1 --zookeeper 192.168.1.81:2181 

运行结果:

2018-12-18 14:11:32:106, 2018-12-18 14:11:32:951, 95.3671, 112.8604, 500000, 591715.9763

使用三个线程消费时:

kafka-consumer-perf-test.sh --topic test --messages 500000 --threads 3  --num-fetch-threads 1 --zookeeper 192.168.1.81:2181 

运行结果:

2018-12-18 14:12:54:716, 2018-12-18 14:12:54:718, 95.3671, 47683.5270, 500000, 250000000.0000

使用六个线程消费时:

kafka-consumer-perf-test.sh --topic test --messages 500000 --threads 6  --num-fetch-threads 1 --zookeeper 192.168.1.81:2181 

运行结果:

2018-12-18 14:14:12:935, 2018-12-18 14:14:12:938, 95.3671, 31789.0180, 500000, 166666666.6667

结论:Cumsomer端消费速率和thread成正比,但是达到一定数量(parttion数量)以后趋于平稳,再增加也不会继续变大。

Kafka性能测试结论

由于每个kafka集群环境差异都很大,本文不代表所有情况。

但是一个通常的kafka生产集群以下特性是应该达到的:

1.单个consumer的消费速率必须远大于单个producer的生产速率。

2.单个broker数据生产效率不应小于50M/s,否则增加JVM内存,并增加缓冲区大小。

9bf7cf91b557cd4e96dff9d31740801f.png往期 精彩回顾技术干货 | 大数据指北系列-Hadoop3.X探秘技术干货 | 如何做Hadoop集群存储规划—HDFS篇技术干货 | 说说KUDU的小秘密技术干货 | 服务编排前传—缘起技术干货 | 服务编排基础—状态机技术干货 | 服务编排—Conductor
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值