Skip to content

feat: Increase Kafka fetch size#87

Open
bigbluechief wants to merge 5 commits intodevelopfrom
feature/increase_kafka_fetch
Open

feat: Increase Kafka fetch size#87
bigbluechief wants to merge 5 commits intodevelopfrom
feature/increase_kafka_fetch

Conversation

@bigbluechief
Copy link
Copy Markdown
Contributor

@bigbluechief bigbluechief commented Apr 7, 2026

Set fetch.min.bytes to 64 KiB and fetch.max.wait.ms to 500 ms for Kafka consumers.

Previously, consumers used the default configuration (fetch.min.bytes=1), which causes the broker to return data as soon as any message is available. In low-throughput scenarios, this leads to very frequent fetch requests with small payloads, increasing CPU usage on the brokers.

With this change:

  • The broker will wait until at least 64 KiB of data is available before responding, or up to 500 ms if the threshold is not reached.
  • This reduces the number of fetch requests and improves batching efficiency.
  • CPU overhead on Kafka brokers is expected to decrease due to fewer, larger responses.

Impact:

  • In low-traffic topics: slightly increased latency (up to ~500 ms) but significantly fewer fetch requests.
  • In high-throughput periods (e.g. full dumps): no meaningful delay, as the threshold is reached quickly and batching improves throughput.

This is a trade-off favoring throughput and resource efficiency over minimal latency, which is acceptable for our use cases.

Set fetch.min.bytes to 64 KiB and fetch.max.wait.ms to 500 ms for Kafka consumers.

Previously, consumers used the default configuration (fetch.min.bytes=1), which causes the broker to return data as soon as any message is available. In low-throughput scenarios, this leads to very frequent fetch requests with small payloads, increasing CPU usage on the brokers.

With this change:

The broker will wait until at least 64 KiB of data is available before responding, or up to 500 ms if the threshold is not reached.
This reduces the number of fetch requests and improves batching efficiency.
CPU overhead on Kafka brokers is expected to decrease due to fewer, larger responses.

Impact:

In low-traffic topics: slightly increased latency (up to ~500 ms) but significantly fewer fetch requests.
In high-throughput periods (e.g. full dumps): no meaningful delay, as the threshold is reached quickly and batching improves throughput.

This is a trade-off favoring throughput and resource efficiency over minimal latency, which is acceptable for our use cases.
@bigbluechief bigbluechief requested a review from nozoz April 7, 2026 10:40
@bigbluechief bigbluechief self-assigned this Apr 7, 2026
bigbluechief and others added 4 commits April 9, 2026 13:08
Adding integration test, which verifies that "idle-between-polls" actually is in effect.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants