> ## 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. # Performance Benchmark for Azure > AutoMQ BYOC performance on Azure: shared storage architecture, ZRS WAL deployment, throughput and latency measurements, and Premium SSD tier comparisons. This report describes AutoMQ BYOC performance on Azure using Azure Blob Storage for retained data and zone-redundant Premium SSD disks for the write-ahead log (WAL). It covers a 15-broker cluster test, additional workloads between 120 and 300 MiB/s, and the effect of WAL disk selection on latency. ## Shared storage architecture of AutoMQ AutoMQ separates the WAL from the storage of retained data. Brokers first persist incoming records to the WAL, then upload them to object storage. This allows the WAL storage service to be selected independently from the service that holds retained data. In the tested Azure deployment, Azure Zone-redundant Disk provides the WAL storage, and Azure Blob Storage holds retained data. See [WAL storage](https://docs.automq.com/automq/architecture/s3stream-shared-streaming-storage/wal-storage.md) for the storage architecture. ## Deployment configuration on Azure Azure's zone-redundant storage (ZRS) synchronously replicates managed disks across three availability zones (AZs). In the tested deployment, each broker uses a Premium SSD with ZRS for its WAL, while Azure Blob Storage holds retained data. ![AutoMQ brokers across three availability zones, with ZRS WAL disks and shared 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) Synchronous replication across zones adds latency to the WAL write path. See [Azure managed disk redundancy](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-redundancy#zone-redundant-storage-for-managed-disks) for the service's replication and recovery behavior. The main cluster test used the following configuration on Azure Kubernetes Service (AKS): | Component | Specification | Quantity | | - | - | - | | Broker VM | Standard\_D4as\_v5, 4 vCPUs, 16 GiB memory | 15 | | WAL disk | Premium SSD P20, 512 GiB, `Premium_ZRS` | One per broker, 15 total | | Retained data | Azure Blob Storage | Shared storage | P10, P15, and P20 are Azure Premium SSD tiers. Increasing the tier increases both capacity and baseline I/O performance: | Specification | P10 | P15 | P20 | | - | - | - | - | | Capacity (GiB) | 128 | 256 | 512 | | Baseline IOPS | 500 | 1,100 | 2,300 | | Baseline throughput (MB/s) | 100 | 125 | 150 | The WAL itself required only a few GiB. The main test selected P20 for its I/O performance, rather than to hold retained Kafka data. Both the VM and disk impose I/O limits: D4as v5 has a documented uncached Premium SSD throughput limit of 144 MB/s before bursting. Check the [Dasv5 VM specifications](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dasv5-series) and [Premium SSD tiers](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssds) when reproducing the test. ## Benchmark setup The tests used [automq-perf-test.sh](https://github.com/AutoMQ/automq/blob/main/bin/automq-perf-test.sh), a performance testing tool included in the AutoMQ open-source project. Its implementation draws on the core logic of [OpenMessaging Benchmark](https://github.com/openmessaging/benchmark). It runs multiple producers and consumers within a single process and reports produce and consume throughput, produce latency, and end-to-end latency percentiles. See [AutoMQ Benchmark](https://docs.automq.com/automq/deployment/automq-benchmark.md) for usage and workload configuration. The workload used fixed 64 KiB records and disabled producer batching. This reduces differences caused by client batching; the results do not represent the latency of individually sent small records. | Parameter | Main cluster test | 120 and 300 MiB/s tests | | - | - | - | | Topics | 1 | 1 | | Record size | 65,536 bytes (64 KiB) | 65,536 bytes (64 KiB) | | Consumer groups | 1 | 1 | | Producer configuration | `batch.size=0` | `batch.size=0` | | Consumer configuration | `fetch.max.wait.ms=1000` | `fetch.max.wait.ms=1000` | | Partitions | 288 | 48 or 96, as specified below | | Producers / consumers | 64 / 64 | As specified below | | Warmup / test duration | 10 / 5 minutes | 5 / 5 minutes | Produce latency measures the time to receive the produce acknowledgment. End-to-end (E2E) latency also includes consumption. Azure service specifications use decimal MB/s; measured throughput below uses binary MiB/s. After [deploying AutoMQ on Azure AKS](https://docs.automq.com/automq-cloud/deploy-automq-on-kubernetes/deploy-to-azure-aks.md), use this command as the starting workload for the main cluster test. Replace the bootstrap address with your cluster endpoint. ```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 tuning used queue depths of 16 or 32 and disk-specific IOPS limits. The object compaction interval was set to 1,440 minutes, and telemetry metrics were disabled. ## Benchmark results ### High-throughput cluster test The 15-broker D4as v5 / P20 cluster was tested with a target of 16,640 records/s, or 1,040 MiB/s, approximately 1 GiB/s. The measured average produce and consume throughput was **778.09 MiB/s**, with zero producer errors. | Statistic | Produce latency (ms) | E2E latency (ms) | | - | - | - | | Average | 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 | | Maximum | 1,346.923 | 1,325.127 | The median produce latency was 8.125 ms, while P99 was 27.538 ms. The higher percentiles show intermittent spikes that matter for latency-sensitive workloads. ### WAL disk comparison at 120 MiB/s The P10 and P15 trials used E2as v5 VMs, one topic with 96 partitions, 24 producers, and 24 consumers in one group. Both achieved 120.05 MiB/s produce and consume throughput with 64 KiB records. | Parameter or result | P10 trial | P15 trial | | - | - | - | | WAL disk capacity (GiB) | 128 | 256 | | Average produce throughput (MiB/s) | 120.05 | 120.05 | | Average consume throughput (MiB/s) | 120.05 | 120.05 | | Average produce latency (ms) | 7.996 | 6.909 | | P50 produce latency (ms) | 7.229 | 6.033 | | P99 produce latency (ms) | 21.597 | 18.398 | | Average E2E latency (ms) | 9.860 | 8.605 | | P99 E2E latency (ms) | 37.757 | 32.886 | At the same throughput, the P15 configuration had lower average and P99 latency. Average produce latency was 6.909 ms for P15 and 7.996 ms for P10; produce P99 was 18.398 ms and 21.597 ms, respectively. The P10 run used a WAL queue depth of 16 and an IOPS limit of 400. ### Additional runs at 150–180 MiB/s This test used a 128 GiB WAL disk, queue depth 16, and an IOPS limit of 400. The workload ran twice at approximately 150 MiB/s and once at 180 MiB/s. | Result | 150 MiB/s, run 1 | 150 MiB/s, run 2 | 180 MiB/s | | - | - | - | - | | Average produce throughput (MiB/s) | 150.05 | 150.06 | 180.05 | | Average consume throughput (MiB/s) | 150.05 | 150.06 | 180.05 | | Average produce latency (ms) | 9.121 | 8.773 | 10.831 | | P50 produce latency (ms) | 8.130 | 7.718 | 9.336 | | P99 produce latency (ms) | 24.065 | 25.073 | 31.621 | | Average E2E latency (ms) | 11.228 | 11.768 | 13.346 | | P99 E2E latency (ms) | 38.114 | 60.041 | 44.476 | At approximately 150 MiB/s, average produce latency was 9.121 ms and 8.773 ms across the two runs, with E2E P99 of 38.114 ms and 60.041 ms. At 180.05 MiB/s, average produce latency was 10.831 ms and E2E P99 was 44.476 ms. ### Partition and client concurrency at 300 MiB/s Two D4as v5 / P20 tests targeted 300 MiB/s, using 4,800 records/s of 64 KiB each. The second configuration doubled both the partition count and producer/consumer concurrency. | Parameter or result | Configuration A | Configuration B | | - | - | - | | Partitions | 48 | 96 | | Producers / consumers | 12 / 12 | 24 / 24 | | Average produce throughput (MiB/s) | 300.07 | 300.05 | | Average consume throughput (MiB/s) | 300.07 | 300.05 | | Average produce latency (ms) | 5.760 | 5.855 | | P99 produce latency (ms) | 15.088 | 15.062 | | Average E2E latency (ms) | 8.101 | 7.647 | | P99 E2E latency (ms) | 21.261 | 21.853 | Average E2E latency was 8.101 ms in configuration A and 7.647 ms in configuration B. E2E P99 was 21.261 ms and 21.853 ms, respectively. Both configurations used a WAL queue depth of 32 and an IOPS limit of 1,000. ## References * [AutoMQ WAL storage](https://docs.automq.com/automq/architecture/s3stream-shared-streaming-storage/wal-storage.md) * [Deploy AutoMQ to Azure AKS](https://docs.automq.com/automq-cloud/deploy-automq-on-kubernetes/deploy-to-azure-aks.md) * [Azure managed disk redundancy](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-redundancy#zone-redundant-storage-for-managed-disks) * [Azure Premium SSD specifications](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssds) * [Azure Dasv5 VM specifications](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.