测试环境准备
前置准备
本文后续的测试结果所采用的压测机及配置:
数量:37 台(1 台 master,18 台 producer,18 台 consumer)
规格:8c16g
镜像及磁盘配置参考如下:

CKafka 实例准备
CKafka 实例购买
CKafka Topic 准备
Topic 总数:10
Topic 副本数:2
Topic 分区数为:实例规格分区总数 / (10*2)
Topic 名称:需与 driver.yaml 配置文件中 topics 一致
注意:
建议整体配置按照满额消耗分区规格和生产带宽进行配置。
CKafka 接入点
需将接入点 IP 与端口填入配置文件 driver.yaml 的 bootstrap.servers 字段。
安装部署 OpenMessaging
1. 下载 OpenMessaging 最新代码。
2. 构建 OpenMessaging 执行包:
# 需安装java 17 和mvnmvn clean package
3. 将包上传到购买的云服务器,执行解压:
tar -zxvf openmessaging-benchmark.tar.gz
OpenMessaging 参数配置
Driver 配置文件
配置文件名称: driver.yaml
配置文件内容如下:
name: KafkadriverClass: io.openmessaging.benchmark.driver.kafka.KafkaBenchmarkDriverreplicationFactor: 2reset: falseuseMyTopic: truetopics: topic_1,topic_2,topic_3,topic_4,topic_5,topic_6,topic_7,topic_8,topic_9,topic_10 #与实际创建的10个topic名称一致useSharedConsumerGroup: falsetopicConfig: |min.insync.replicas=2commonConfig: |bootstrap.servers= #接入点路由producerConfig: |acks=1compression.type=none #压缩算法可分别配置为none,gzip,snappy,lz4linger.ms=30000batch.size=32768receive.buffer.bytes = 32768max.request.size=1048576max.in.flight.requests.per.connection=5request.timeout.ms=30000consumerConfig: |auto.offset.reset=latestenable.auto.commit=truereceive.buffer.bytes = 32768max.partition.fetch.bytes = 1048576fetch.max.wait.ms=500max.poll.interval.ms=300000
TestCase 配置文件
配置文件名称:testcase.yaml
配置文件内容如下:
name: perftesttopics: 10partitionsPerTopic: 100 #实例总分区数/(10*2)messageSize: 1024 #不开启压缩算法时,配置为1024; 开启压缩算法参见 《3.4压缩比相关配置》payloadFile: "date.file"subscriptionsPerTopic: 1consumerPerSubscription: 120producersPerTopic: 100 #实例为20M规格时配置为10, 其它均填100useRandomizedPayloads: truerandomBytesRatio: 0.1producerRate: 307200 #注意:producerRate=(实例带宽/2)*1024consumerBacklogSizeGB: 0testDurationMinutes: 30randomizedPayloadPoolSize: 100keyDistributor: RANDOM_NANO
启动 OpenMessaging 测试服务
启动 slave 节点
在购买的云服务器上逐台执行下面命令。
cd openmessaging-benchmark-0.0.1-SNAPSHOT && sh bin/benchmark-worker --port 9090 --stats-port 9091
启动 Master 节点
根据 slave 机器 ip 地址,替换以下命令行中的 slave_ip1, slave_ip2... 等地址,通过 master 控制 slave 机器的运行。
cd openmessaging-benchmark-0.0.1-SNAPSHOT && bin/benchmark --drivers driver.yaml --workers http://slave_ip1:9090,http://slave_ip2:9090 testcase.yaml
压测场景介绍
客户端配置
生产者配置
参数 | 压测值 | 默认值 |
Topic 总数 | 10 个 | |
Topic 副本数 | 2 个 | |
每个 Topic 生产者数 | 100 | |
每个 Topic 消费组数 | 1 | |
每个消费组消费者数 | 5 | |
平均消息大小 | 1KB | |
linger.ms | 30000 | 0 |
batch.size | 32768 | 16384 |
receive.buffer.bytes | 32768 | 32 * 1024 |
acks | 1 | 1 |
compression.type | none | none |
max.in.flight.requests.per.connection | 5 | 5 |
max.request.size | 1048576 | 1M |
request.timeout.ms | 30 | 30s |
消费者配置
参数 | 压测值 | 默认值 |
每个 Topic 消费组数 | 1 | |
每个消费组消费者数 | 120(与分区数一致) | |
receive.buffer.bytes | 32768 | 32 * 1024 |
max.partition.fetch.bytes | 1048576 | 1M |
fetch.max.wait.ms | 500ms | 500ms |
max.poll.interval.ms | 300000 | 5分钟 |
场景一:实时写入并读取
实时写入数据,同步消费数据,模拟大部分客户的常规读写场景。
场景二:写入后回溯读取
先写入 10 分钟数据,待数据刷到磁盘,再将客户端 offset 设置到 0 进行消费,同时持续写数据,模拟客户的回溯读写场景。
压测结果
压测结果文件查看
结束后会在 master 节点生成如下 JSON 报告文件:

压测指标查看
耗时指标查看
生产时延-平均(毫秒):aggregatedPublishLatencyAvg。
生产时延-P95(毫秒):aggregatedPublishLatency95pct。
生产时延-P99(毫秒):aggregatedPublishLatency99pct。
端到端消费时延-平均(毫秒):aggregatedEndToEndLatencyAvg。
端到端消费时延-P95(毫秒):aggregatedEndToEndLatency95pct。
端到端消费时延-P99(毫秒):aggregatedEndToEndLatency99pct。
注意:
场景二因客户端统计延时问题,端到端消费时延可在管控台查看 P95 和 P999 数据。
TPS 指标查看
生产 TPS:Ckafka 管控 > 监控 > 实例,如下:

消费 TPS:Ckafka 管控 > 监控 > 实例,如下:

场景一结果
压测规格 | 压缩配置 | 实际生产带宽(MB/s) | 实际消费带宽(MB/s) | 生产时延-平均(毫秒) | 生产时延-P95(毫秒) | 生产时延-P99(毫秒) | 消费时延-平均(毫秒) | 消费时延-P95(毫秒) | 消费时延-P99(毫秒) | 生产QPS | 消费QPS | 集群负载指标 |
实例带宽上限:20MB/s | 关闭压缩 | 10M | 10M | 2520 | 5045 | 5791 | 5 | 9 | 16 | 400 | 600 | 10% |
| 开启gzip | 10M | 10M | 1294 | 2693 | 3213 | 5 | 9 | 16 | 800 | 920 | 20% |
| 开启snappy | 10M | 10M | 1611 | 3303 | 3903 | 4 | 8 | 14 | 640 | 800 | 13% |
| 开启lz4 | 10M | 10M | 1292 | 2691 | 3210 | 4 | 7 | 14 | 800 | 920 | 18% |
实例带宽上限:600MB/s | 关闭压缩 | 300M | 300M | 4068 | 7968 | 8913 | 17 | 36 | 71 | 14920 | 14480 | 40% |
| 开启gzip | 300M | 300M | 1919 | 3864 | 4475 | 26 | 69 | 138 | 32520 | 27600 | 93% |
| 开启snappy | 300M | 300M | 2455 | 4910 | 5627 | 12 | 26 | 48 | 25000 | 23600 | 60% |
| 开启lz4 | 300M | 300M | 1894 | 3837 | 4456 | 13 | 30 | 57 | 32760 | 30400 | 70% |
实例带宽上限:1600MB/s | 关闭压缩 | 800M | 800M | 2268 | 4587 | 5221 | 43 | 152 | 340 | 48800 | 30000 | 50% |
| 开启gzip | 800M | 800M | 1335 | 2679 | 3124 | 260 | 903 | 3295 | 94800 | 44000 | 100% |
| 开启snappy | 800M | 800M | 2810 | 5580 | 6331 | 62 | 274 | 565 | 72800 | 52000 | 62% |
| 开启lz4 | 800M | 800M | 1096 | 2215 | 2568 | 135 | 320 | 684 | 94400 | 59000 | 72% |
说明:
1. 为什么生产延时在不压缩时比压缩大?
当 batch size 配置为 32K 时,不压缩实际攒批 20K,压缩后攒批 10K,不压缩时攒批时间长,耗时主要消耗在攒批上。
2. 生产延迟和消费耗时指标如何计算?
生产延时 = 调用 send 消息时的时间戳 - 消息发送成功的时间戳,包含攒批 + 压缩 + 网络发送 + 等待 broker 回包的时间。
消费端到端延时 = 消费到数据时间戳 - 消息落盘时间戳。
场景二结果
压测规格 | 压缩配置 | 实际生产带宽(MB/s) | 实际消费带宽(MB/s) | 生产时延-平均(毫秒) | 生产时延-P95(毫秒) | 生产时延-P99(毫秒) | 服务端:消费时延-P95(毫秒) | 服务端:消费时延-P999(毫秒) | 生产QPS | 消费QPS | 集群负载指标 |
实例带宽上限:20MB/s | 关闭压缩 | 10M | 20M | 2520 | 5046 | 5794 | 50 | 500 | 400 | 260 | 10% |
| 开启gzip | 10M | 20M | 1294 | 2694 | 3222 | 60 | 500 | 800 | 200 | 13% |
| 开启snappy | 10M | 20M | 1612 | 3304 | 3898 | 60 | 500 | 640 | 180 | 12% |
| 开启lz4 | 10M | 20M | 1290 | 2682 | 3207 | 60 | 500 | 800 | 180 | 12% |
实例带宽上限:600MB/s | 关闭压缩 | 300M | 600M | 4072 | 7972 | 8919 | 180 | 280 | 14960 | 4960 | 40% |
| 开启gzip | 300M | 600M | 1919 | 3866 | 4481 | 160 | 300 | 32520 | 5040 | 80% |
| 开启snappy | 300M | 600M | 2452 | 4897 | 5606 | 170 | 270 | 25120 | 4920 | 41% |
| 开启lz4 | 300M | 600M | 1890 | 3827 | 4440 | 170 | 300 | 32800 | 4800 | 52% |
实例带宽上限:1600MB/s | 关闭压缩 | 800M | 1600M | 2290 | 4611 | 5249 | 180 | 450 | 48800 | 12000 | 45% |
| 开启gzip | 800M | 1600M | 1364 | 2716 | 3175 | 180 | 670 | 94800 | 12000 | 90% |
| 开启snappy | 800M | 1600M | 2823 | 5588 | 6342 | 170 | 460 | 73200 | 12000 | 50% |
| 开启lz4 | 800M | 1600M | 1118 | 2240 | 2596 | 170 | 530 | 94800 | 12000 | 43% |