0


关于kafka压力测试(使用官方自带脚本测试)

文章目录

kafka官方自带压测脚本文件

在kakfa的bin目录下有很多脚本,其中有两个脚本是kafka官方自带的压力测试脚本。用来测试kafka在生产和消费中,有哪些瓶颈来限制了工作效率。

kafka-consumer-perf-test.sh
kafka-producer-perf-test.sh

Producer生产者环境测试

测试命令

bin/kafka-producer-perf-test.sh  --topictest --record-size 100 --num-records
 100000--throughput-1 --producer-props bootstrap.servers=hadoop102:9092,hadoop103:9092,hadoop104:9092

各个参数解释

record-size 是一条信息有多大,单位是字节。
num-records 是总共发送多少条信息。
throughput 是每秒多少条信息,设成-1,表示不限流,可测出生产者最大吞吐量。

返回测试结果

100000 records sent, 95877.277085 records/sec (9.14 MB/sec), 187.68 ms avg latency, 424.00 ms max 
latency, 155 ms 50th, 411 ms 95th, 423 ms 99th, 424 ms 99.9th.

返回结果说明

一共写入10w条消息
吞吐量为9.14 MB/sec
每次写入的平均延迟为187.68毫秒
最大的延迟为424.00毫秒。

Consumer消费者环境测试

测试命令

bin/kafka-consumer-perf-test.sh --broker-list hadoop102:9092,hadoop103:9092,
hadoop104:9092 --topic test --fetch-size 10000 --messages 10000000  --threads 1

各个参数解析

fetch-size 指定每次fetch的数据的大小
messages 总共要消费的消息个数
threads 开启的线程数

测试结果说明

start.time, end.time, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg, nMsg.sec
2019-02-19 20:29:07:566, 2019-02-19 20:29:12:170, 9.5368, 2.0714, 100010, 21722.4153

共消费数据9.5368MB
吞吐量2.0714MB/s
共消费100010条
平均每秒消费21722.4153条

提升kafka的吞吐量

可通过以下的方式来提升kafka生产者的吞吐量

buffer.memory

该参数用来设置生产者内存缓冲区的大小,生产者用它缓冲要发送到服务器的消息。
如果应用程序发送消息的速度超过发送到服务器的速度,会导致生产者空间不足。
这个时候 send() 方法调用要么被阻塞,要么抛出异常,取决于如何设置 block.on.buffer.full 参数(在 0.9.0.0 版本里被替换成了 max.block.ms ,表示在抛出异常之前可以阻塞一段时间)。
设置发送消息的缓冲区,默认值是33554432,就是32MB
如果发送消息出去的速度小于写入消息进去的速度,就会导致缓冲区写满,此时生产消息就会阻塞住,所以说这里就应该多做一些压测,尽可能保证说这块缓冲区不会被写满导致生产行为被阻塞住

compression.type

默认情况下,消息发送时不会被压缩。
该参数可以设置为 snappy 、 gzp 或 1z4 ,它指定了消息被发送给 broker 之前使用哪一种压缩算法进行压缩。
snappy 压缩算法由 Google 发明,它占用较少的 CPU ,却能提供较好的性能和相当可观的压缩比,如果比较关注性能和网络带宽,可以使用这种算法。
gzip 压缩算法一般会占用较多的 CPU ,但会提供更高的压缩比,所以如果网络带宽比较有限,可以使用这种算法。
使用压缩可以降低网络传输开销和存储开销,而这往往是向 Kafka 发送消息的瓶颈所在。
默认是none,不压缩,但是也可以使用lz4压缩,效率还是不错的,压缩之后可以减小数据量,提升吞吐量,但是会加大producer端的cpu开销。

batch.size

当有多个消息需要被发送到同一个分区时,生产者会把它们放在同一个批次里。
该参数指定了一个批次可以使用的内存大小,按照字节数计算(而不是消息个数)。
当批次被填满,批次里的所有消息会被发送出去。
不过生产者并不一定都会等到批次被填满才发送,半满的批次,甚至只包含一个消息的批次也有可能被发送。
所以就算把批次大小设置得很大也不会造成延退,只是会占用更多的内存而已。
但如果设置得太小,因为生产者需要更频繁地发送消息,会增加一些额外的开销。
设置merge batch的大小,如果 batch 太小,会导致频繁网络请求,吞吐量下降;
如果batch太大,会导致一条消息需要等待很久才能被发送出去,而且会让内存缓冲区有很大压力,过多数据缓冲在内存里
默认值是:16384,就是16kb,也就是一个batch满了16kb就发送出去,一般在实际生产环境,这个batch的值可以增大一些来提升吞吐量,可以自己压测一下。

linger.ms

该参数指定了生产者在发送批次之前等待更多消息加入批次的时间。
KafkaProducer 会在批次填满或 linger.ms 达到上限时把批次发送出去。
默认情况下,只要有可用的线程,生产者就会把消息发送出去,就算批次里只有一个消息。
把 linger.ms 设置成比0大的数,让生产者在发送批次之前等待一会儿,使更多的消息加入到这个批次。
虽然这样会增加延退,但也会提升吞吐量(因为一次性发送更多的消息,每个消息的开销就变小了)。
这个值默认是0,意思就是消息必须立即被发送,但是这是不对的。
一般设置一个100毫秒之类的,这样的话就是说,这个消息被发送出去后进入一个batch,如果100毫秒内,这个batch满了16kb,自然就会发送出去。
但是如果100毫秒内,batch没满,那么也必须把消息发送出去了,不能让消息的发送延迟时间太长,也避免给内存造成过大的一个压力。

来源: https://juejin.cn/post/6997321470594514980

可以通过以下方法提高消费效率

增加CPU 内存的数量,启用更多的消费组,设置更多region

标签: kafka 压力测试 java

本文转载自: https://blog.csdn.net/itguangzhi/article/details/129365503
版权归原作者 广志大兄弟 所有, 如有侵权,请联系我们删除。

“关于kafka压力测试(使用官方自带脚本测试)”的评论:

还没有评论