> ## 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 Tuning for Broker

> Optimize AutoMQ's broker performance with memory and network tuning, leveraging cloud-native scalability and Kafka compatibility for efficient resource allocation.

AutoMQ enhances server performance through methods like read/write efficiency optimization and resource isolation, ensuring stable and efficient operation.

<Tip>
  Users should adjust parameters based on their hardware environment and business scenarios.
</Tip>

## Memory-related Parameters

### s3.stream.allocator.policy

Configure the memory allocation strategy for AutoMQ by selecting either `POOLED_HEAP` or `POOLED_DIRECT`. If memory resources are abundant (> 8 GiB), it is advisable to use `POOLED_DIRECT` to alleviate GC pressure.

### s3.wal.cache.size

Manage the size of the Log Cache, which influences the maximum size of cached data during Tail Read (hot reads).

### s3.block.cache.size

Control the size of the Block Cache; it influences the maximum size of data cached during Catch-up Read (catch-up read, cold read). In Catch-up Read scenarios, consider appropriately increasing this value.

### s3.wal.upload.threshold

Manage the amount of data AutoMQ accumulates in the Log Cache before triggering an S3 upload. It is advisable not to exceed 1/3 of `s3.wal.cache.size`.

### Recommended Parameter Values

When the memory allocation strategy is `POOLED_HEAP`, the sum of `s3.wal.cache.size` and `s3.block.cache.size` should be approximately 1/4 of `MaxHeapSize`.

When the memory allocation strategy is `POOLED_DIRECT`, the sum of `s3.wal.cache.size` and `s3.block.cache.size` should be about 1/2 of `MaxDirectMemorySize` (if `MaxDirectMemorySize` is large, it can be slightly increased).

| -<br />                          | Small<br />         | Medium<br />         | Large<br />          |
| -------------------------------- | ------------------- | -------------------- | -------------------- |
| Physical Memory<br />            | 8 GiB<br />         | 16 GiB<br />         | 32 GiB<br />         |
| s3.stream.allocator.policy<br /> | POOLED\_HEAP<br />  | POOLED\_DIRECT<br /> | POOLED\_DIRECT<br /> |
| -XX:MaxHeapSize<br />            | 6g<br />            | 6g<br />             | 12g<br />            |
| -XX:MaxDirectMemorySize<br />    | -<br />             | 6g<br />             | 14g<br />            |
| s3.wal.cache.size<br />          | 1,073,741,824<br /> | 2,147,483,648<br />  | 6,442,450,944<br />  |
| s3.block.cache.size<br />        | 536,870,912<br />   | 1,073,741,824<br />  | 4,294,967,296<br />  |
| s3.wal.upload.threshold<br />    | 357,913,941<br />   | 536,870,912<br />    | 536,870,912<br />    |

## Network-related Parameters

### s3.network.baseline.bandwidth

The baseline for assessing local network bandwidth should be the network's stable capability to achieve both outbound and inbound bandwidth.

Since the server internally performs operations such as writing the WAL, S3, and Compaction, each data write from a client translates into three network writes by the server. By considering the business's read/write ratio, you can ultimately determine the maximum write load a single machine can manage.