> ## 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. # Azure 性能报告 > AutoMQ BYOC 在 Azure 上的性能报告：共享存储架构、ZRS WAL 部署、吞吐与延迟测量，以及 Premium SSD 档位对比。 本报告介绍 AutoMQ BYOC 在 Azure 上的性能表现，测试采用 Azure Blob Storage 保存保留期内的数据，以区域冗余 Premium SSD 磁盘承载预写日志（WAL）。报告涵盖 15 个 Broker 的集群测试、120 至 300 MiB/s 的补充负载测试，以及 WAL 磁盘选择对延迟的影响。 ## AutoMQ 共享存储架构 AutoMQ 将 WAL 与保留数据的存储分离。Broker 先将收到的记录持久化到 WAL，再上传至对象存储，因此 WAL 和保留数据可以分别选择底层存储服务。 本次 Azure 部署使用 Azure Zone-redundant Disk 承载 WAL，以 Azure Blob Storage 保存保留期内的数据。存储架构详情请参阅 [WAL 存储](https://docs.automq.com/zh/automq/architecture/s3stream-shared-streaming-storage/wal-storage.md)。 ## Azure 部署配置 Azure 区域冗余存储（ZRS）在三个可用区（AZ）之间同步复制托管磁盘数据。在本次部署中，每个 Broker 使用一块开启 ZRS 的 Premium SSD 承载 WAL，Azure Blob Storage 则保存保留期内的数据。 ![分布在三个可用区的 AutoMQ Broker，使用 ZRS WAL 磁盘和共享 Azure Blob Storage](https://mintcdn.com/automq/R1tAdP-AVBNoPIQz/automq-cloud/appendix/performance-benchmark-for-azure/azure-deployment.webp?fit=max\&auto=format\&n=R1tAdP-AVBNoPIQz\&q=85\&s=8282e5eb71cc83ce572c3944776ce902) 跨可用区同步复制会增加 WAL 写入路径的延迟。服务的复制和恢复机制请参阅 [Azure 托管磁盘冗余](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-redundancy#zone-redundant-storage-for-managed-disks)。 主要集群测试部署在 Azure Kubernetes Service（AKS）上，配置如下： | 组件 | 规格 | 数量 | | - | - | - | | Broker 虚拟机 | Standard\_D4as\_v5，4 vCPU、16 GiB 内存 | 15 台 | | WAL 磁盘 | Premium SSD P20，512 GiB，`Premium_ZRS` | 每个 Broker 一块，共 15 块 | | 保留数据存储 | Azure Blob Storage | 共享存储 | P10、P15 和 P20 是 Azure Premium SSD 的三个规格档位。更高档位同时提供更大的容量和更高的基准 I/O 性能： | 规格 | P10 | P15 | P20 | | - | - | - | - | | 容量（GiB） | 128 | 256 | 512 | | 基准 IOPS | 500 | 1,100 | 2,300 | | 基准吞吐（MB/s） | 100 | 125 | 150 | WAL 本身只需要数 GiB 空间。主要测试选择 P20 是为了获得所需的 I/O 性能，而非用它保存保留期内的 Kafka 数据。虚拟机和磁盘都存在 I/O 上限：D4as v5 的文档标明，其 Premium SSD 非缓存吞吐在不使用突发能力时上限为 144 MB/s。复测时应同时核对 [Dasv5 虚拟机规格](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dasv5-series)和 [Premium SSD 档位](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssds)。 ## 测试配置 测试使用 AutoMQ 开源项目自带的性能测试工具 [automq-perf-test.sh](https://github.com/AutoMQ/automq/blob/main/bin/automq-perf-test.sh)。该工具参考 [OpenMessaging Benchmark](https://github.com/openmessaging/benchmark) 的核心逻辑实现，可以在单个进程中运行多个 Producer 和 Consumer，统计写入和消费吞吐、写入延迟及端到端延迟的各分位数。使用方式和负载配置请参阅 [AutoMQ 性能测试](https://docs.automq.com/zh/automq/deployment/automq-benchmark.md)。 本次负载固定记录大小为 64 KiB，并关闭 Producer 批处理，以减少客户端批处理策略带来的差异。这些结果不代表逐条发送小消息时的延迟。 | 参数 | 主要集群测试 | 120 和 300 MiB/s 测试 | | - | - | - | | Topic 数 | 1 | 1 | | 记录大小 | 65,536 字节（64 KiB） | 65,536 字节（64 KiB） | | Consumer group 数 | 1 | 1 | | Producer 配置 | `batch.size=0` | `batch.size=0` | | Consumer 配置 | `fetch.max.wait.ms=1000` | `fetch.max.wait.ms=1000` | | 分区数 | 288 | 48 或 96，详见下文 | | Producer / Consumer 数 | 64 / 64 | 详见下文 | | 预热 / 测试时长 | 10 / 5 分钟 | 5 / 5 分钟 | 写入延迟指收到写入确认所需的时间，端到端（E2E）延迟还包含消费过程。Azure 服务规格使用十进制 MB/s，下文实测吞吐使用二进制 MiB/s。 [在 Azure AKS 上部署 AutoMQ](https://docs.automq.com/zh/automq-cloud/deploy-automq-on-kubernetes/deploy-to-azure-aks.md) 后，可以使用以下命令作为主要集群测试的起始负载。将 bootstrap 地址替换为实际集群端点。 ```bash theme={null} bin/automq-perf-test.sh \ --bootstrap-server :9092 \ --producer-configs batch.size=0 \ --consumer-configs fetch.max.wait.ms=1000 \ --topics 1 \ --partitions-per-topic 288 \ --producers-per-topic 64 \ --groups-per-topic 1 \ --consumers-per-group 64 \ --record-size 65536 \ --send-rate 16640 \ --warmup-duration 10 \ --test-duration 5 ``` WAL 调优采用 16 或 32 的队列深度，并按磁盘规格设置 IOPS 限制。对象 Compaction 间隔设为 1,440 分钟，遥测指标关闭。 ## 测试结果 ### 高吞吐集群测试 15 个 Broker 的 D4as v5 / P20 集群以 16,640 条/秒为目标，即 1,040 MiB/s，约 1 GiB/s。实测**平均写入和消费吞吐均为 778.09 MiB/s**，写入错误数为零。 | 统计项 | 写入延迟（ms） | E2E 延迟（ms） | | - | - | - | | 平均值 | 9.508 | 11.508 | | P50 | 8.125 | 9.169 | | P75 | 10.655 | 12.299 | | P90 | 13.281 | 16.695 | | P95 | 16.179 | 21.443 | | P99 | 27.538 | 39.886 | | P99.9 | 342.085 | 338.467 | | 最大值 | 1,346.923 | 1,325.127 | 写入延迟的中位数为 8.125 ms，P99 为 27.538 ms。更高分位数显示了间歇性延迟尖峰，延迟敏感业务需要同时关注这些长尾数据。 ### 120 MiB/s 下的 WAL 磁盘对比 P10 和 P15 测试均使用 E2as v5 虚拟机、一个含 96 个分区的 Topic、24 个 Producer，以及同一 Consumer group 中的 24 个 Consumer。记录大小为 64 KiB，两组实测写入和消费吞吐均为 120.05 MiB/s。 | 参数或结果 | P10 测试 | P15 测试 | | - | - | - | | WAL 磁盘容量（GiB） | 128 | 256 | | 平均写入吞吐（MiB/s） | 120.05 | 120.05 | | 平均消费吞吐（MiB/s） | 120.05 | 120.05 | | 平均写入延迟（ms） | 7.996 | 6.909 | | 写入 P50（ms） | 7.229 | 6.033 | | 写入 P99（ms） | 21.597 | 18.398 | | 平均 E2E 延迟（ms） | 9.860 | 8.605 | | E2E P99（ms） | 37.757 | 32.886 | 在相同吞吐下，P15 配置的平均延迟和 P99 更低。P15 和 P10 的平均写入延迟分别为 6.909 ms 和 7.996 ms，写入 P99 分别为 18.398 ms 和 21.597 ms。P10 测试的 WAL 队列深度为 16，IOPS 限制为 400。 ### 150–180 MiB/s 的补充测试 这组测试使用 128 GiB WAL 磁盘，队列深度为 16，IOPS 限制为 400。负载分别在约 150 MiB/s 下运行两次，在 180 MiB/s 下运行一次。 | 结果 | 150 MiB/s，第 1 次 | 150 MiB/s，第 2 次 | 180 MiB/s | | - | - | - | - | | 平均写入吞吐（MiB/s） | 150.05 | 150.06 | 180.05 | | 平均消费吞吐（MiB/s） | 150.05 | 150.06 | 180.05 | | 平均写入延迟（ms） | 9.121 | 8.773 | 10.831 | | 写入 P50（ms） | 8.130 | 7.718 | 9.336 | | 写入 P99（ms） | 24.065 | 25.073 | 31.621 | | 平均 E2E 延迟（ms） | 11.228 | 11.768 | 13.346 | | E2E P99（ms） | 38.114 | 60.041 | 44.476 | 在约 150 MiB/s 的两次测试中，平均写入延迟分别为 9.121 ms 和 8.773 ms，E2E P99 分别为 38.114 ms 和 60.041 ms。在 180.05 MiB/s 下，平均写入延迟为 10.831 ms，E2E P99 为 44.476 ms。 ### 300 MiB/s 下的分区数与客户端并发 两次 D4as v5 / P20 测试均以 300 MiB/s 为目标，每秒发送 4,800 条 64 KiB 记录。第二组同时将分区数和 Producer、Consumer 并发数翻倍。 | 参数或结果 | 配置 A | 配置 B | | - | - | - | | 分区数 | 48 | 96 | | Producer / Consumer 数 | 12 / 12 | 24 / 24 | | 平均写入吞吐（MiB/s） | 300.07 | 300.05 | | 平均消费吞吐（MiB/s） | 300.07 | 300.05 | | 平均写入延迟（ms） | 5.760 | 5.855 | | 写入 P99（ms） | 15.088 | 15.062 | | 平均 E2E 延迟（ms） | 8.101 | 7.647 | | E2E P99（ms） | 21.261 | 21.853 | 配置 A 和配置 B 的平均 E2E 延迟分别为 8.101 ms 和 7.647 ms，E2E P99 分别为 21.261 ms 和 21.853 ms。两组配置的 WAL 队列深度均为 32，IOPS 限制为 1,000。 ## 参考资料 * [AutoMQ WAL 存储](https://docs.automq.com/zh/automq/architecture/s3stream-shared-streaming-storage/wal-storage.md) * [在 Azure AKS 上部署 AutoMQ](https://docs.automq.com/zh/automq-cloud/deploy-automq-on-kubernetes/deploy-to-azure-aks.md) * [Azure 托管磁盘冗余](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-redundancy#zone-redundant-storage-for-managed-disks) * [Azure Premium SSD 规格](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssds) * [Azure Dasv5 虚拟机规格](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dasv5-series) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.