性能测试

AutoMQ 基于 S3 共享存储的存算分离架构，在与 Apache Kafka 保证 100% 兼容性的基础上提供了极速弹性、低成本、高性能等优势特性。AutoMQ 相比 Apache Kafka 可以在冷读时提供更好的吞吐性能以及提供更高的极限吞吐。本文档介绍如何对 AutoMQ 集群进行性能测试。

前置条件

进行集群性能测试前，需要满足如下条件：

1. 完成 AutoMQ 集群的安装部署 ，您可以参考以下方式安装部署 AutoMQ：

• Linux 主机部署多节点集群▸

• Kubernetes 部署多节点集群▸

2. 准备必要的压力机资源， 建议在相同的 VPC 网络下创建一定数量的压力机，确保压力机的网络吞吐和 CPU 不会成为测试场景的瓶颈。

测试场景

场景1：Tail Read

Tail Read，即“追尾读”或“热读”，测试 Producer 与 Consumer 间位点差距不大的场景。热写热读场景主要关注如下指标：

• 读写吞吐： 实时读写场景是 Kafka 的典型场景，在相同硬件资源的基础上吞吐越高、性能越好。

• 写入和 E2E 耗时： 在相同网络吞吐的条件下消息写入耗时越低越好，E2E 耗时（消息从生产到消费的耗时）越低越好。

在 Tail Read场景下，Producer 发送的消息在被写入 Broker 后立即就会被 Consumer 消费掉，此时 Consumer 消费到的消息直接来自于 AutoMQ Log Cache，无需读取对象存储，资源消耗较少。

场景 2：Catch-Up Read

Catch-Up Read，即“追赶读”或“冷读”，测试 Consumer 消费位点远落后于 Producer 位点的场景。在该场景下，首先将暂停 Consumer，在积攒一定大小的消息后，再重新开始消费。此时 Consumer 消费的消息将从对象存储中读取，并由 Block Cache 进行预读与缓存。

在该测试场景下，主要关注以下两方面指标：

• 追赶读速度是否最够快 。观察每个 Consumer Group 的消费速度是否超过了 Producer 的写入速度，只有超过了，才意味着 Consumer 可以追上 Producer。

• 追赶读期间写入流量是否受到影响 。观察追赶读期间 Producer 发送消息的流量是否有所下降，以及发送延迟是否升高。

使用 Kafka CLI 进行测试

用户可通过 Kafka CLI 工具，运行 kafka-producer-perf-test.sh 和 kafka-consumer-perf-test.sh 进行性能测试。

如果此前的 AutoMQ 集群参考 Linux 主机部署多节点集群▸ 部署，则获取的集群 Bootstrap 地址是类似 “192.168.0.1:9092,192.168.0.2:9092,192.168.0.3:9092 ”。

请根据部署的实际配置，将下方的 bootstrap-server 地址更换成实际集群的地址。

创建 Topic

./kafka-topics.sh --create --topic test-topic --bootstrap-server 192.168.0.1:9092,192.168.0.2:9092,192.168.0.3:9092

发送消息

./kafka-producer-perf-test.sh --topic test-topic --num-records=1024000 --throughput 5120 --record-size 1024 --producer-props bootstrap.servers=192.168.0.1:9092,192.168.0.2:9092,192.168.0.3:9092

linger.ms 和 batch.size 等是性能调优的关键参数，可参见 客户端性能调优▸ 按实际需求进行设置。

消费消息

./kafka-consumer-perf-test.sh --topic test-topic --show-detailed-stats --timeout 300000 --messages=1024000 --reporting-interval 1000 --bootstrap-server=192.168.0.1:9092,192.168.0.2:9092,192.168.0.3:9092

使用 AutoMQ 压测工具进行测试（推荐）

AutoMQ 团队针对社区提供的 Kafka性能测试 CLI 工具进行改进，发布了一键压测工具，该压测工具参考OpenMessaging Benchmark 框架，具备如下优势：

• 支持单进程多客户端，提升压测密度和效率： 相较于 Apache Kafka 自带的 kafka-producer-perf-test.sh 与 kafka-consumer-perf-test.sh 脚本，automq-perf-test.sh 支持了在一个进程中同时启动多个 Producer、Consumer，并向多个 Topic 收发消息，更加贴近实际场景，使用起来更加方便。

• 一键运行，无需分布式部署： 相较于 OpenMessaging Benchmark 测试框架，不再需要分布式部署多个 Worker，单机即可一键执行测试。在不特别大规模的测试场景下，部署与使用起来更加方便。

• 提供 Catch Up Read 测试场景： 除此之外 automq-perf-test.sh 脚本还支持了更加复杂的冷读测试场景——可以启动多个 Consumer Group，并且每个 Group 分别从不同的位点开始消费，这样可以避免在冷读时复用 Cache，进而测试更加极端场景下的冷读性能。

• 开放和中立： 该测试脚本仅依赖 Apache Kafka Client，可以支持对 Apache Kafka、MSK 等兼容 Kafka 协议的流系统进行性能测试。

场景1：Tail Read

下面的这个用例测试了 AutoMQ 的 Tail Read 性能，该测试用例：

• 生产和消费流量比例为 1:1

• 将向 10 个 Topic 合计 1280 个 Partition 中写入数据

• 每秒写入 1600 条大小为 51 KiB 的消息（不进行任何攒批），写入速度为 80 MiB/s

注意在执行如下脚本前，需要将 --bootstrap-server 地址替换为实际的 AutoMQ 接入点地址。

KAFKA_HEAP_OPTS="-Xmx12g -Xms12g" ./bin/automq-perf-test.sh \
--bootstrap-server 0.kf-v8tj9bmunqdo1og8.wanshao-for-aws.automq.private:9092,1.kf-v8tj9bmunqdo1og8.wanshao-for-aws.automq.private:9092,2.kf-v8tj9bmunqdo1og8.wanshao-for-aws.automq.private:9092 \
--producer-configs batch.size=0 \
--consumer-configs fetch.max.wait.ms=1000 \
--topics 10 \
--partitions-per-topic 128 \
--producers-per-topic 1 \
--groups-per-topic 1 \
--consumers-per-group 1 \
--record-size 52224 \
--send-rate 1600 \
--warmup-duration 10 \
--test-duration 5 \
--reset

场景 2：Catch-Up Read

下面的这个用例测试了 AutoMQ 的 Catch-Up Read 性能，该测试用例：

• 生产和消费流量比例为 1:3

• 将向 10 个 Topic 合计 1280 个 Partition 中写入数据

• 每秒写入 800 条大小为 64 KiB 的消息（不进行任何攒批），写入速度为 50 MiB/s

• 在追赶读前将积攒 600 秒数据（~30 GiB），随后启动 3 个 Consumer Group 开始追赶读，每个 Group 的起始位点将有 30 秒的间隔（~1.5 GiB）

注意在执行如下脚本前，需要将 --bootstrap-server 地址替换为实际的 AutoMQ 接入点地址。

KAFKA_HEAP_OPTS="-Xmx12g -Xms12g" ./bin/automq-perf-test.sh \
--bootstrap-server 0.kf-hsd29pri8q5myud5.wanshao-for-aws.automq.private:9092,1.kf-hsd29pri8q5myud5.wanshao-for-aws.automq.private:9092,2.kf-hsd29pri8q5myud5.wanshao-for-aws.automq.private:9092 \
--producer-configs batch.size=0 \
--consumer-configs fetch.max.wait.ms=1000 \
--topics 10 \
--partitions-per-topic 128 \
--producers-per-topic 1 \
--groups-per-topic 3 \
--consumers-per-group 1 \
--record-size 65536 \
--send-rate 800 \
--backlog-duration 600 \
--group-start-delay 30 \
--warmup-duration 5 \
--reset

启动项参数

• --bootstrap-server ：指定 Kafka 集群的初始连接节点，形如 "host1:port1,host2:port2"。值得说明的是，这些地址仅用于初始连接到 Kafka 集群，以获取集群元数据，所以无需提供集群中全部 Broker 的地址，仅需提供少量运行中且可访问的地址即可。

• --common-configs ：指定 Kafka Admin Client、Producer 与 Consumer 的公共配置，例如鉴权相关配置。

• --topic-configs ：指定 Topic 相关配置，例如消息保留时间等。

• --producer-configs ：指定 Producer 相关配置，例如攒批大小、攒批时间、压缩方式等。

• --consumer-configs ：指定 Consumer 相关配置，例如单次拉取消息的最大大小等。

• --reset ：是否在运行 Benchmark 前删除集群中原有的所有 Topic。

• --topic-prefix ：测试使用的 Topic 的前缀。

• --topics ：测试时创建的 Topic 的数量。

• --partitions-per-topic ：每个 Topic 中 Partition 的数量， --topics * --partitions-per-topic 即为测试使用的 Partition 总数。

• --producers-per-topic ：每个 Topic 上创建的 Producer 的数量。 --topics * --producers-per-topic 即为测试使用的 Producer 总数。

• --groups-per-topic ：每个 Topic 上创建的 Consumer Group 的数量，亦即测试时的读写比（fan-out）。

• --consumers-per-group ：每个 Consumer Group 中 Consumer 的数量。 --topics * --groups-per-topic * --consumers-per-group 即为测试使用的 Consumer 总数。

• --record-size ：Producer 发送的每条消息的大小，单位为字节。

• --send-rate ：所有 Producer 每秒发送的消息条数的总和。 --record-size * --send-rate 即为测试时的写流量。

• --random-ratio ：消息中随机数据的比例，常用于 Producer 开启压缩场景的测试。取值为 0.0 至 1.0 之间，值越大，消息中随机数据越多，理论压缩效果越差；默认为 0.0，即每条消息完全一致。

• --random-pool-size ：随机消息池的大小，每次发送消息时会从该消息池中随机选取一条。该选项仅在 --random-ratio 大于 0 时生效。

• --backlog-duration ：用于追赶读测试场景，控制积攒消息的持续时间，单位为秒。 --record-size * --send-rate * --backlog-duration 即为在追赶读前积攒的消息大小。

• --group-start-delay ：用于追赶读测试场景，控制每个 Consumer Group 在追赶读时消费起点的间隔，单位为秒。设置该选项可以使得每个 Consumer Group 的消费进度错开，避免 Cache 复用，以更好地模拟真实追赶读场景。

• --send-rate-during-catchup ：用于追赶读测试场景，控制在追赶读期间 Producer 的发送速率，默认为 --send-rate 。

• --warmup-duration ：进行测试前预热的时长，单位为分钟。在预热期间，前 50% 的时间会逐步提升 Producer 的发送速率至 --send-rate ，后 50% 的时间维持在 --send-rate 。预热期间的相关指标不会计入最终结果，为了充分预热 JVM，建议将 --warmup-duration 设置为 10 分钟或以上。

• --test-duration ：进行正式测试的时长，单位为分钟。仅非追赶读测试场景（ --backlog-duration 不大于 0）生效。

• --reporting-interval ：测试期间相关指标的统计间隔，单位为秒。

性能调优和技术支持

AutoMQ 集群的性能取决于计算资源的规格、内核参数调优等多方面因素。面向生产场景的性能调优和基线标定相对复杂。

您可以通过此处表单联系 AutoMQ 团队获取性能测试报告以及生产场景的性能调优最佳实践。