【kafka性能测试脚本详解、性能测试、性能分析与性能调优】

Love The Way You Lie 2024-03-16 17:09 72阅读 0赞

## Kafka 性能测试 ##

### 一、介绍 ###

Apache Kafka 官方提供了两个客户端性能测试脚本，它们的存放位置如下：

*  生产者性能测试脚本：$KAFKA\_HOME/bin/kafka-producer-perf-test.sh
 *  消费者性能测试脚本：$KAFKA\_HOME/bin/kafka-consumer-perf-test.sh  
    kafka-producer-perf-test.sh 支持测试的性能指标包括：吞吐量（throughput）、最大时延（max-latency）、平均时延（avg-latency）；kafka-consumer-perf-test.sh 同样支持吞吐量指标，还提供了一些消费端特有的指标，但没有直接提供时延信息。

### 二、使用 ###

#### 2.1 kafka-producer-perf-test.sh ####

此脚本用于测试 Kafka 生产消息的性能，可选参数列表如下，加粗项为常用参数。  
暂时无法在飞书文档外展示此内容

<table> 
 <thead> 
  <tr> 
   <th>参数名</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>-h, --help</td> 
   <td>显示使用帮助并退出</td> 
  </tr> 
  <tr> 
   <td>参数名</td> 
   <td>指定生产的消息发往的 topic</td> 
  </tr> 
  <tr> 
   <td>-h, --help</td> 
   <td>指定生产的消息总数</td> 
  </tr> 
  <tr> 
   <td>–topic</td> 
   <td>如果通过 --payload-file 指定了从文件中获取消息内容，那么这个参数的意义是指定文件的消息分隔符，默认值为 \n，即文件的每一行视为一条消息；如果未指定 --payload-file 则此参数不生效</td> 
  </tr> 
  <tr> 
   <td>–num-records</td> 
   <td>限制每秒发送的最大的消息数，设为 -1 表示不限制</td> 
  </tr> 
  <tr> 
   <td>–payload-delimeter</td> 
   <td>直接指定 Producer 配置，格式为 NAME=VALUE，例如 bootstrap.server=127.0.0.1:9092，通过此种方式指定的配置优先级高于 --producer.config</td> 
  </tr> 
  <tr> 
   <td>–throughput</td> 
   <td>指定 Producer 的配置文件，格式参照官方的 config/producer.properties</td> 
  </tr> 
  <tr> 
   <td>–producer-props</td> 
   <td>在测试结束后打印更详尽的指标，默认为 false</td> 
  </tr> 
  <tr> 
   <td>–producer-config</td> 
   <td>指定事务 ID，测试并发事务的性能时需要，只有在 --transaction-duration-ms &gt; 0 时生效，默认值为 performance-producer-default-transactional-id</td> 
  </tr> 
  <tr> 
   <td>–print-metrics</td> 
   <td>在测试结束后打印更详尽的指标，默认为 false</td> 
  </tr> 
  <tr> 
   <td>–transactional-id</td> 
   <td>指定事务 ID，测试并发事务的性能时需要，只有在 --transaction-duration-ms &gt; 0 时生效，默认值为 performance-producer-default-transactional-id</td> 
  </tr> 
  <tr> 
   <td>–transactional-duration-ms</td> 
   <td>指定事务持续的最长时间，超过这段时间后就会调用 commitTransaction 来提交事务，只有指定了 &gt; 0 的值才会开启事务，默认值为 0</td> 
  </tr> 
  <tr> 
   <td>–record-size</td> 
   <td>指定每条消息的大小，单位是字节，和 --payload-file 两个中必须指定一个，但不能同时指定</td> 
  </tr> 
  <tr> 
   <td>–payload-file</td> 
   <td>指定消息的来源文件，只支持 UTF-8 编码的文本文件，文件的消息分隔符通过 --payload-delimeter 指定，和 --record-size 两个中必须指定一个，但不能同时指定</td> 
  </tr> 
 </tbody> 
</table>

**【示例】**

bin/kafka-producer-perf-test.sh --topic perf-test --num-records 1000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=127.0.0.1:9092 compression.type=lz4

**【输入解释】**  
发送 1000 条大小为 1KB 的消息到地址为 127.0.0.1:9092 的 broker 上的 perf-test 主题，发送时不限制吞吐量，并使用 lz4 算法压缩消息。  
执行示例命令后，控制台输出一行测试结果，如下：

1000 records sent, 3424.657534 records/sec (3.34 MB/sec), 13.61 ms avg latency, 255.00 ms max latency, 13 ms 50th, 20 ms 95th, 255 ms 99th.

**【输出解释】**  
成功消费了 1000 条消息，吞吐量为 3424.657534 条/秒 (或 3.34 MB/秒)，平均时延为 13.61 ms，最大时延为 255.00 ms，50 % 的消息延时在 13 ms 内，95 % 的消息延时在 20 ms 内，99 % 的消息延时在 255 毫秒内。

#### 2.2 kafka-consumer-perf-test.sh ####

此脚本用于测试 Kafka 消费消息的性能，可选参数列表如下，加粗项为常用参数。

<table> 
 <thead> 
  <tr> 
   <th>参数名</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>–bootstrap-server</td> 
   <td>指定 broker 地址，必选，除非用 --broker-list 代替（不建议）</td> 
  </tr> 
  <tr> 
   <td>–topic</td> 
   <td>指定消费的 topic，必选</td> 
  </tr> 
  <tr> 
   <td>–version</td> 
   <td>输出 Kafka 版本</td> 
  </tr> 
  <tr> 
   <td>–consumer.config</td> 
   <td>指定 Consumer 配置文件</td> 
  </tr> 
  <tr> 
   <td>–date-format</td> 
   <td>指定用于格式化 *.time 的规则，默认为 yyyy-MM-dd HH:mm:ss:SSS</td> 
  </tr> 
  <tr> 
   <td>–fetch-size</td> 
   <td>指定一次请求消费的大小，默认为 1048576 即 1 MB</td> 
  </tr> 
  <tr> 
   <td>–from-latest</td> 
   <td>如果 Consumer 没有已经建立的 offset，则指定从 log 中最新的位点开始消费，而不是从最早的位点开始消费</td> 
  </tr> 
  <tr> 
   <td>–group</td> 
   <td>指定 ConsumerGroup ID，默认为 perf-consumer-40924</td> 
  </tr> 
  <tr> 
   <td>–help</td> 
   <td>显示使用帮助并退出</td> 
  </tr> 
  <tr> 
   <td>–hide-header</td> 
   <td>指定后不输出 header 信息</td> 
  </tr> 
  <tr> 
   <td>–messages</td> 
   <td>指定消费的消息数量，必选</td> 
  </tr> 
  <tr> 
   <td>–num-fetch-threads</td> 
   <td>指定 fetcher 线程的数量</td> 
  </tr> 
  <tr> 
   <td>–print-metrics</td> 
   <td>指定打印 metrics 信息</td> 
  </tr> 
  <tr> 
   <td>–reporting-interval</td> 
   <td>指定打印进度信息的时间间隔，默认为 5000 即 5 秒</td> 
  </tr> 
  <tr> 
   <td>–show-detailed-stats</td> 
   <td>指定每隔一段时间（由 --reporting-interval 指定）输出显示详细的状态信息</td> 
  </tr> 
  <tr> 
   <td>–socket-buffer-size</td> 
   <td>指定 TCP 的 RECV 大小，默认为 2097152 即 2 MB</td> 
  </tr> 
  <tr> 
   <td>–threads</td> 
   <td>指定消费的线程数，默认为 10</td> 
  </tr> 
  <tr> 
   <td>–timeout</td> 
   <td>指定允许的最大超时时间，即每条消息返回的最大时间间隔，默认为 10000 即 10 秒</td> 
  </tr> 
 </tbody> 
</table>

【示例】

bin/kafka-consumer-perf-test.sh --bootstrap-server 127.0.0.1:9092 --topic perf_test --messages 1000000 --threads 8 --reporting-interval 1000 --show-detailed

【输入解释】  
同时开启 8 个消费线程，从 127.0.0.1:9092 的 broker 上的 perf-test 主题中消费 1000 条消息，每隔 1000 ms = 1 s 打印一次消费进度信息。最后两个参数在消费数量很小的场景下没有什么帮助，比如若消费数量只有 1000，命令瞬间就可以执行返回；但当指定的消费数量很大（如示例中为 1000 万）时，需要 10 s 左右才能消费完，此时定时输出一下进度信息就显得很有用了。  
执行示例命令后，控制台输出两行信息，其中第一行为表头，接下来的数行为每秒的进度信息，如下：

> time, threadId, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg,nMsg.sec, rebalance.time.ms, fetch.time.ms, fetch.MB.sec,fetch.nMsg.sec  
> 2021-03-25 15:57:59:426, 0, 657.2275, 657.2275, 673001,  
> 673001.0000, 1616659078690, -1616659077690, 0.0000, 0.0000

…  
【输出解释】

*  time：当前时间，格式由 --date-format 指定
 *  threadId：线程 ID
 *  data.consumed.in.MB：消费到的数据总大小，单位为 MB
 *  MB.sec：消费 TPS，即每秒消费的消息大小
 *  data.consumed.in.nMsg：消费到的总消息数
 *  nMsg.sec：消费 TPS，即每秒消费的消息条数
 *  rebalance.time.ms：消费者组重平衡的耗时，单位为 ms，0 表示没有发生重平衡
 *  fetch.time.ms：fetch 线程的总耗时，单位为 ms
 *  fetch.MB.sec：fetch 线程每秒钟获取到的消息大小
 *  fetch.nMsg.sec：fetch 线程每秒钟获取到的消息数量  
    **【注意】**  
    若没有指定 --show-detailed，则输出信息中的前两项会有所不同，如下：

> start.time, end.time, data.consumed.in.MB, MB.sec, …

*  start.time：消费开始的时间，格式由 --date-format 指定
 *  end.time：消费结束的时间，格式由 --date-format 指定

## 测试 ##

### producer（生产者） ###

#### partitions（分区） ####

##### 3个分区（partitions） #####

–replication-factor 4 --partitions 3(**test**)  
1000 条大小为 1KB 的消息

bin/kafka-producer-perf-test.sh --topic test --num-records 1000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=192.168.1.5:9092 compression.type=lz4

![\[图片\]][3fa0143134264266bf8ba1a68828bfda.png]  
1000000 条大小为 1KB 的消息

bin/kafka-producer-perf-test.sh --topic test --num-records 1000000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=192.168.1.5:9092 compression.type=lz4

![\[图片\]][b7437a2b009f4bf092fc3929d353f374.png]

–replication-factor 1 --partitions 3(**test13**)  
1000000 条大小为 1KB 的消息  
![在这里插入图片描述][fa6a54d9f53147bdb8d4c079e887aab3.png]

##### 4个分区（partitions） #####

–replication-factor 4 --partitions 4（testpro）  
1000000 条大小为 1KB 的消息  
![\[图片\]][122f76f804c84dbfb6513d0a80bfa370.png]

–replication-factor 3 --partitions 4(testpro34)  
1000000 条大小为 1KB 的消息  
![\[图片\]][3d02e202611c4edd97e8b614a6e94fcc.png]

–replication-factor 1 --partitions 4(testpro14)  
1000000 条大小为 1KB 的消息  
![\[图片\]][84f2cc76208a49ba96509ea6ba1330b7.png]

##### 5个分区（partitions） #####

–replication-factor 4 --partitions 5(testpro45)  
1000000 条大小为 1KB 的消息  
![\[图片\]][efcb3b7fc7934b84bff989c4f435101d.png]

–replication-factor 3 --partitions 5(**testpro35**)  
1000000 条大小为 1KB 的消息  
![\[图片\]][d019c1c725f146d1bda983cf4a21b0d4.png]

##### 2个broker的集群 #####

4个副本3个分区（test）与4个副本5个分区（testpro45）生产1000000条数据对比：  
**test**吞吐量相对高一点点(高3 mb/sec)，而平均时延、最大时延、即生产各完成百分段时延都是testpro45较低

4个副本3个分区（test）与4个副本4个分区（testpro）生产1000000条数据对比：  
**testpro**吞吐量高很多(高51 mb/sec)，而平均时延、最大时延、即生产各完成百分段时延都是testpro低

3个副本4个分区（testpro34）与4个副本4个分区（testpro）生产1000000条数据对比：  
**testpro**吞吐量相对较高(高15 mb/sec)，而平均时延testpro34相对较低，最大时延testpro44相对较低，50%的消息时延testpro34较低，95%之后都是testpro的消息时延较低！

4个副本4个分区（testpro）与4个副本5个分区（testpro45）生产1000000条数据对比：  
**testpro**吞吐量高很多(高54 mb/sec)，而平均时延、最大时延、即生产各完成百分段时延都是testpro低

--------------------

> **在同等条件下，消息数为1000000，分区数由小到大变化，其他参数不变，4个分区时，性能最优。**

--------------------

#### compression（压缩算法） ####

![\[图片\]][9fec655b39394927b03220110dd3e581.png]

--------------------

> **在同等条件下，消息数为1000000，压缩算法为gzip、snappy、lz4，其他参数不变，当采用lz4时吞吐量最高，而对于消息时延来说，gzip的平均和最大时延都是最低。**

--------------------

> 建议只有在producer **cpu资源充裕**的情况下，才开启压缩，否则会使机器cpu资源耗尽，反而得不偿失;  
> 如果宽带资源比较紧张，建议开启压缩，可以使用zstd，极大的减少网络资源开销

### Consumer（消费者） ###

#### compression（压缩算法） ####

使用不同的压缩算法生产消息  
![\[图片\]][9f4d26f4d84542ce9ae53640f472538d.png]  
![\[图片\]][13a776fa03e54e6d967d259cf8f615e8.png]

![\[图片\]][f6b52048ccdc4d23a50309f4f61c440e.png]

使用不同的解压缩算法消费消息  
![\[图片\]][fbdb14aadea64f3eb807fe72e3caea8b.png]

--------------------

> **在同等条件下，消息数为1000000，压缩算法为gzip、snappy、lz4，其他参数不变，当生产和消费消息时采用lz4时性能最优。**

--------------------

#### threads（线程） ####

bin/kafka-consumer-perf-test.sh --broker-list 192.168.1.5:9092 --topic test --messages 1000000 --threads 8 compression.type=lz4  
![\[图片\]][0f05ff78d9b94a838ddc20085c8115a0.png]

bin/kafka-consumer-perf-test.sh --broker-list 192.168.1.5:9092 --topic test --messages 1000000 --threads 4

![\[图片\]][1d67a0e46d654839853fd57a6da51780.png]

threads 1  
![\[图片\]][60af4faadd3f455ba20022953501e69d.png]

> ***获取消息的线程数与实际吞吐率影响不大。**  
> 在增加分区数与消费线程数时，在小于3个分区时，3个分区与3个消费线程性能最优，在其他条件不改变的前提下，再进一步增加分区数与消费程数时，实际吞吐量变化不大。*

## 配置建议 ##

基于kafka的高度可配置的特性，可以应用到不同的业务场景，比如，实时性较强的跟踪用户在页面上的行为动作、实时性不高但可靠性很高的信用卡支付操作的处理等。

### 可靠性配置： ###

#### replication.factor ####

副本因子，针对topic级别的配置参数是**replication.factor**，以本次测试为例，有3个broker实例，建议合理的复制系数为1-3，以3为例，也就是每个分区会被3个broker各复制一次，即每个broker保存一个分区，即使在2个broker失效的情况下，仍然可以向topic写入消息或从topic读取消息。总结如下：  
如果复制系数为N，那么在N-1个broker失效的情况下，仍然具备读写能力，因此更高的复制系数会带来更高的可靠性，但另一方面，N个复制系数需要至少N个broker，而且会有N份数据副本(副本包含leader与follower)。

#### unclean.leader.election.enable ####

不完全的leader选举，unclean.leader.election.enable在broker级别上进行配置，默认值为true(仅在当前版本为true，后续高版本为false)**确保分区可从非 ISR 中选举 leader**，官方在kafka高版本发行时，修改了这个默认值，暂时理解为官网的推荐设置，但对于实时性较高的业务，比如实时统计用户访问量的分析，一般会启用这个配置，即设置为true，但对于可靠性较高的业务，比如银行的业务，宁可花费几分钟或几个小时的延时后再处理像信用卡支付的业务，也不会冒险处理错误的消息。因此，按真实的业务场景来设置即为合理。

#### min.insync.replicas ####

**最少同步副本，min.insync.replicas**默认是1，本次测试中采用了3个broker，因此这个值可以设置1-3，当然如果选择3时，即为最少要同步3个副本才可以向分区写入数据，即为真正的提交，需要注意的是如果有1个broker出现问题，无法同步副本，那么剩下的broker就会停止生产者的所有请求，并抛出NotEnouqhReplicasException给生产者，直至问题broker恢复，此时消费者可以正常读取消息。

#### producer ####

producer发送确认，生产者可以选择3种不同模式的确认，acks为0时，只要生产者把消息发送出去，即认为已成功写入broker，这种模式下运行速度非常快，吞吐率和带宽利用率非常高，不过采用这种模式风险较高，容易丢失一些消息。一般压力测试都是基于这个模式的。使用实时性较高的系统，也不建议采用该模式。

#### acks ####

acks为1时，即为leader收到消息并写入分区数据文件(不一定同步到磁盘)后，提交成功，返回确认响应。  
acks为-1或all时，即leader收到消息后，会等待所有同步副本都收到消息，才会返回确认响应。

> **acks = 0**  
> 如果设置为零，则生产者将不会等待来自服务器的任何确认，该记录将立即添加到套接字缓冲区并视为已发送。在这种情况下，无法保证服务器已收到记录，并且重试配置将不会生效（因为客户端通常不会知道任何故障），为每条记录返回的偏移量始终设置为-1。  
> **acks = 1**  
> 这意味着leader会将记录写入其本地日志，但无需等待所有副本服务器的完全确认即可做出回应，在这种情况下，如果leader在确认记录后立即失败，但在将数据复制到所有的副本服务器之前，则记录将会丢失。  
> **acks = all**  
> 这意味着leader将等待完整的同步副本集以确认记录，这保证了只要至少一个同步副本服务器仍然存活，记录就不会丢失，这是最强有力的保证，这相当于acks= -1的设置。  
> 可以设置的值为：all, -1, 0, 1

#### producer ####

**producer**失败重试参数，当生产者没有收到成功的响应，重试发送次数，当前版本默认为0，根据实际业务来设置该参数，并非越大越好，也不建议设置为0，生产者收到的错误会包括2种，一种是可恢复性错误，一种是不可恢复性错误，遇到可恢复性的错误时，可以通过重试来解决，不可恢复性错误，只能由开发者手动处理。但由于网络原因造成的无法收到成功响应，此时如果无限次的重试发送，会造成分区内存在重复消息，增加了消费者读取消息时的业务处理的复杂度。因此分析实际业务场景，谨慎设置。

#### consumer auto.offset.reset ####

**consumer auto.offset.reset**，默认值为latest,即在没有offset时，消费者会从分区的末尾开始读取数据，减少读取重复消息的可能性，但可能会错过一些消息。设置为earliest，当出现offset不存在的情况时，从分区的开始位置读取数据，这样会读取大量重复消息，由消费端的业务逻辑来处理重复消息。增加了业务的复杂度。

> 当kafka中没有初始offset或offset超出范围时将自动重置offset  
> **earliest**:重置为分区中最小的offset;  
> **latest**:重置为分区中最新的offset(消费分区中新产生的数据);  
> **none**:只要有一个分区不存在已提交的offset,就抛出异常;

#### consumer auto.commit.interval.ms ####

**consumer auto.commit.interval.ms**，默认值为5000ms，即5秒提交一次，可以通过该参数来设置提交的频度，一般来说，提交频度越高，越会带来更高的系统开销，可靠性也随之提高。

#### 1、实时类业务 ####

实时类业务，把零延时作为第一考虑因素，比如聊天室、会议室、直播类似系统等，在保证最小延时的基础上，适当设置可靠性相关参数。建议可靠性参数如下：

replication.factor:1
    
    unclean.leader.election.enable:true
    
    min.insync.replicas:1
    
    acks:0
    
    retries:0

#### 2、近实时类业务 ####

即可接受一定范围内的延时，比如实时计算用户访问量等类似web监控类业务，在保证最小延时的基础上，适当设置可靠性相关参数。建议可靠性参数如下：

replication.factor:2
    
    unclean.leader.election.enable:true
    
    min.insync.replicas:2
    
    acks:1
    
    retries:1/2/3
    
    consumer auto.commit.interval.ms:1000ms
    
    consumer auto.offset.reset:latest

#### 3、非实时类业务 ####

非实时类业务，即可以允许一定时间的延时，从而来保证系统更高的可靠性。以3个broker以例，建议可靠性参数如下：

replication.factor:3 
    
    unclean.leader.election.enable:false
    
    min.insync.replicas:2/3
    
    acks:all
    
    retries:MAX_INT
    
    consumer auto.commit.interval.ms:500ms
    
    consumer auto.offset.reset:earliest

![在这里插入图片描述][af4e1b0888e04c3cba9a32edee0cf34b.png]

[3fa0143134264266bf8ba1a68828bfda.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/68e8ea27c7b84a34a4f9a7877be4f548.png
[b7437a2b009f4bf092fc3929d353f374.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/1f055f03d2ee44448dc222d1f9769289.png
[fa6a54d9f53147bdb8d4c079e887aab3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/31f37875256246e188cd1602a64ad0f0.png
[122f76f804c84dbfb6513d0a80bfa370.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/d36b802295a94c54afa48491d2c4f352.png
[3d02e202611c4edd97e8b614a6e94fcc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/d3df3106d5444fa1b48f2ed5b3847535.png
[84f2cc76208a49ba96509ea6ba1330b7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/ce68184da7cf4862b9520a56d836dc6a.png
[efcb3b7fc7934b84bff989c4f435101d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/ce303469d1994683aad39cb6aa7f79cd.png
[d019c1c725f146d1bda983cf4a21b0d4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/6fad2750137f465da84ab526bfbc409b.png
[9fec655b39394927b03220110dd3e581.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/3b8e77fe29124406a03527f33801e8ea.png
[9f4d26f4d84542ce9ae53640f472538d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/854fbb89e5144d439eb8beb12c379f3e.png
[13a776fa03e54e6d967d259cf8f615e8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/b784d0fe3216400ca7f90db71c010892.png
[f6b52048ccdc4d23a50309f4f61c440e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/2a1a02b998ce4f728716d69c312aa5bb.png
[fbdb14aadea64f3eb807fe72e3caea8b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/8b8fdb041bda4abe93deb1fe49722c45.png
[0f05ff78d9b94a838ddc20085c8115a0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/4235540c994b4c3499017188b7484c63.png
[1d67a0e46d654839853fd57a6da51780.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/a5b09a07af2d47f88c1387b8f1e8aa4e.png
[60af4faadd3f455ba20022953501e69d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/1485ff9626264764bffcbe9ad641dc21.png
[af4e1b0888e04c3cba9a32edee0cf34b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/99d782c922d24211a3a53279b3b8bd88.png