> ## Documentation Index
> Fetch the complete documentation index at: https://docs.automq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 性能测试
> Optimize AutoMQ’s Kafka compatibility with rapid elasticity, high performance, and cost efficiency built on S3 storage. Test cluster performance with robust tools.
AutoMQ 基于 S3 共享存储的存算分离架构，在与 Apache Kafka 保证 100% 兼容性的基础上提供了极速弹性、低成本、高性能等优势特性。AutoMQ 相比 Apache Kafka 可以在冷读时提供更好的吞吐性能以及提供更高的极限吞吐。本文档介绍如何对 AutoMQ 集群进行性能测试。
### 前置条件
进行集群性能测试前，需要满足如下条件：
1. **完成 AutoMQ 集群的安装部署** ，您可以参考以下方式安装部署 AutoMQ：
* [Linux 主机部署多节点集群▸](/zh/automq/deployment/deploy-multi-nodes-cluster-on-linux)
* [Kubernetes 部署多节点集群▸](/zh/automq/deployment/deploy-multi-nodes-cluster-on-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 主机部署多节点集群▸](/zh/automq/deployment/deploy-multi-nodes-cluster-on-linux) 部署，则获取的集群 Bootstrap 地址是类似 “**192.168.0.1:9092,192.168.0.2:9092,192.168.0.3:9092** ”。
请根据部署的实际配置，将下方的 bootstrap-server 地址更换成实际集群的地址。
#### 创建 Topic
```bash theme={null}
./kafka-topics.sh --create --topic test-topic --bootstrap-server 192.168.0.1:9092,192.168.0.2:9092,192.168.0.3:9092
```
#### 发送消息
```bash theme={null}
./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` 等是性能调优的关键参数，可参见 [客户端性能调优▸](/zh/automq/configuration/performance-tuning-for-client) 按实际需求进行设置。
#### 消费消息
```bash theme={null}
./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 接入点地址。
```bash theme={null}
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 接入点地址。
```bash theme={null}
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 集群的性能取决于计算资源的规格、内核参数调优等多方面因素。面向生产场景的性能调优和基线标定相对复杂。
您可以通过[此处表单](https://www.automq.com/contact)联系 AutoMQ 团队获取性能测试报告以及生产场景的性能调优最佳实践。