Kafka机器数量计算、性能评估、压力测试

一、Kafka机器数量计算

Kafka机器数量（经验公式）= 2 *（峰值生产速度 * 副本数 / 100）+ 1

先拿到峰值生产速度，再根据设定的副本数，就能预估出需要部署Kafka的数量。

1）峰值生产速度

峰值生产速度可以压测得到。

2）副本数

副本数默认是1个，在企业里面2-3个都有，2个居多。

副本多可以提高可靠性，但是会降低网络传输效率。

比如我们的峰值生产速度是50M/s。副本数为2。

Kafka机器数量 = 2 *（50 * 2 / 100）+ 1 = 3台

二、Kafka分区数计算

（1）创建一个只有1个分区的topic

（2）测试这个topic的producer吞吐量和consumer吞吐量。

（3）假设他们的值分别是Tp和Tc，单位可以是MB/s。

（4）然后假设总的目标吞吐量是Tt，那么分区数 = Tt / min（Tp，Tc）

例如：producer吞吐量 = 20m/s；consumer吞吐量 = 50m/s，期望吞吐量100m/s；

分区数 = 100 / 20 = 5分区

如何根据数据量确定Kafka分区个数、Kafka的分区是不是越多越好、Kafak生产者分发策略，消费者负载均衡 09_啊策策的博客-CSDN博客https://blog.csdn.net/weixin_42641909/article/details/89294698

分区数一般设置为：3-10个

一、性能评估

1.14.1 单broker性能评估

我们做单broker性能评估的目的包括以下几方面：

1)为我们进行资源申请评估提供依据；

2)让我们更了解集群的读写能力及瓶颈在哪里，针对瓶颈进行优化；

3)为我们限流阈值设置提供依据；

4)为我们评估什么时候应该扩容提供依据；

1.14.2 topic分区性能评估

1)为我们创建topic时，评估应该指定多少分区合理提供依据；

2)为我们topic的分区扩容评估提供依据；

1.14.3 单磁盘性能评估

1)为我们了解磁盘的真正读写能力，为我们选择更合适Kafka的磁盘类型提供依据；

2)为我们做磁盘流量告警阈值设置提供依据；

1.14.4 集群规模限制摸底

1）我们需要了解单个集群规模的上限或者是元数据规模的上限，探索相关信息对集群性能和稳定性的影响；

2）根据摸底情况，评估集群节点规模的合理范围，及时预测风险，进行超大集群的拆分等工作；

二、压力测试

1.测试目的

 本次性能测试在正式环境下单台服务器上Kafka处理MQ消息能力进行压力测试。测试包括对Kafka写入MQ消息和消费MQ消息进行压力测试，根据10w、100w和1000w级别的消息处理结果，评估Kafka的处理性能是否满足项目需求。（该项目期望Kafka能够处理上亿级别的MQ消息）

2.测试范围及方法

2.1测试范围概述
   测试使用Kafka自带的测试脚本，通过命令对Kafka发起写入MQ消息和Kafka消费MQ消息的请求。模拟不同数量级的MQ消息写入和MQ消息消费场景，根据Kafka的处理结果，评估Kafka是否满足处理亿级以上的消息的能力。

2.2性能测试场景设计
2.2.1Kafka写入消息压力测试

测试场景	MQ消息数	每秒写入消息数	记录大小(单位:字节Byte)
Kafka消息写入测试	10W	2000条	1000
	100W	5000条	1000
	1000W	5000条	1000

2.2.2Kafka消费消息压力测试

测试场景	消费MQ消息数
Kafka消息消费测试	10W
	100W
	1000W

2.3测试方法简要描述

        Kafka 官方自带压力测试脚本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。Kafka 压测时，可以查看到哪个地方出现了瓶颈（CPU，内存，网络 IO）。一般都是网络 IO达到瓶颈

2.3.1测试目的
     验证带台服务器上Kafka写入消息和消费消息的能力，根据测试结果评估当前Kafka集群模式是否满足上亿级别的消息处理能力。

2.3.2测试方法
     在服务器上使用Kafka自带的测试脚本，分别模拟10w、100w和1000w的消息写入请求，查看Kafka处理不同数量级的消息数时的处理能力，包括每秒生成消息数、吞吐量、消息延迟时间。Kafka消息吸入创建的topic命名为test_perf，使用命令发起消费该topic的请求，查看Kafka消费不同数量级别的消息时的处理能力。

压测命令信息： 

测试项	压测消息数（单位:W）	测试命令
写入MQ消息	10	./kafka-producer-perf-test.sh --topic test_perf --num-records 100000 --record-size 1000  --throughput 2000 --producer-props bootstrap.servers=10.150.30.60:9092
	100	/kafka-producer-perf-test.sh --topic test_perf --num-records 1000000 --record-size 2000  --throughput 5000 --producer-props bootstrap.servers=10.150.30.60:9092
	1000	./kafka-producer-perf-test.sh --topic test_perf --num-records 10000000 --record-size 2000  --throughput 5000 --producer-props bootstrap.servers=10.150.30.60:9092
消费MQ消息	10	./kafka-consumer-perf-test.sh --zookeeper localhost:2181 --topic test_perf --fetch-size 1048576 --messages 1000000 --threads 1
	100	./kafka-consumer-perf-test.sh --zookeeper localhost:2181 --topic test_perf --fetch-size 1048576 --messages 10000000 --threads 1

kafka-producer-perf-test.sh 脚本命令的参数解析（以100w写入消息为例）：
--topic topic名称，本例为test_perf
--num-records 总共需要发送的消息数，本例为100000
--record-size 每个记录的字节数，本例为1000
--throughput 每秒钟发送的记录数，本例为5000
--producer-props bootstrap.servers=localhost:9092 （发送端的配置信息，本次测试取集群服务器中的一台作为发送端,可在kafka的config目录，以该项目为例：/usr/local/kafka/config；查看server.properties中配置的zookeeper.connect的值，默认端口：9092） 

3.测试环境

3.1测试环境机器配置表
  

4.测试结果
4.1测试结果说明
本次测试针对Kafka消息处理的能力 进行压力测试，对Kafka集群服务器中的一台进行MQ消息服务的压力测试，关注Kafka消息写入的延迟时间是否满足需求。对Kafka集群服务器中的一台进行MQ消息处理的压力测试，验证Kafka的消息处理能力。

4.2测试结果

4.2.1写入MQ消息

压测结果截图

写入100w消息压测结果 

699884 records sent, 139976.8 records/sec (13.35 MB/sec), 1345.6 ms avg latency, 2210.0 ms max latency.

713247 records sent, 141545.3 records/sec (13.50 MB/sec), 1577.4 ms avg latency, 3596.0 ms max latency.

773619 records sent, 153862.2 records/sec (14.67 MB/sec), 2326.8 ms avg latency, 4051.0 ms max latency.

773961 records sent, 154206.2 records/sec (15.71 MB/sec), 1964.1 ms avg latency, 2917.0 ms max latency.

776970 records sent, 154559.4 records/sec (15.74 MB/sec), 1960.2 ms avg latency, 2922.0 ms max latency.

MQ消息写入测试结果解析：
本例中写入100w条MQ消息为例，每秒平均向kafka写入了4.77MB的数据，大概是4999.875条消息/秒，每次写入的平均延迟为1毫秒，最大的延迟为647毫秒，1ms内占99%。

4.2.2消费MQ消息

压测结果截图

消费10w消息压测结果

消费100w消息压测结果

消费1000w消息压测结果

kafka-consumer-perf-test.sh 脚本命令的参数为：
--zookeeper 指定zookeeper的链接信息，本例为localhost:2181 ；
--topic 指定topic的名称，本例为test_perf，即4.2.1中写入的消息；
--fetch-size 指定每次fetch的数据的大小，本例为1048576，也就是1M
--messages 总共要消费的消息个数，本例为1000000，100w
以本例中消费100w条MQ消息为例总共消费了953.66M的数据，每秒消费数据大小为177.19M，总共消费了10000004条消息，每秒消费185804.53条消息。

吞吐量受网络带宽和fetch-size的影响 

start.time, end.time, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg, nMsg.sec

2021-08-03 21:22:57:671, 2021-08-03 21:23:41:938, 514.7169, 11.6276, 5397198, 121923.7355

5.结果分析

根据4.2.测试结果，可以看出在单台服务器上，写入MQ消息设置5000条/秒时，消息写入及时，95%的消息延迟时间小于等于1ms，在可接受范围内；Kafka消费MQ消息时，1000W待处理消息的处理能力在每秒20w条以上，处理结果理想。
   根据Kafka处理10w、100w和1000w级的消息时的处理能力，可以评估出Kafka集群服务，是否有能力处理上亿级别的消息。
本次测试是在正式环境集群服务中的单台服务器上进行，基本不需要考虑网络带宽的影响。所以单台服务器的测试结果，对评估集群服务是否满足上线后实际应用的需求，很有参考价值。
 
原文链接：https://blog.csdn.net/laofashi2015/article/details/81111466

Kafka性能测试内容 

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

性能测试工具：

• kafka-producer-perf-test.sh (生产端)
• kafka-consumer-perf-test.sh (消费端)

性能测试环境：

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

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内存，并增加缓冲区大小。