[转帖]关于kafka压力测试（使用官方自带脚本测试）

文章目录

• kafka官方自带压测脚本文件
• Producer生产者环境测试
• • • 测试命令
    • 返回测试结果
• Consumer消费者环境测试
• • • 测试命令
    • 测试结果说明
• 提升kafka的吞吐量
• • 可通过以下的方式来提升kafka生产者的吞吐量
  • • buffer.memory
    • compression.type
    • batch.size
    • linger.ms
  • 可以通过以下方法提高消费效率

kafka官方自带压测脚本文件

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

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

Producer生产者环境测试

测试命令

bin/kafka-producer-perf-test.sh  --topic test --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

文章知识点与官方知识档案匹配，可进一步学习相关知识

Java技能树首页概览120812 人正在系统学习中