Skip to content
Kafka Is Fun

IntermediatePerformance

How would you tune a Kafka producer for maximum throughput?

Reference answer

Throughput tuning mostly means larger, fuller and cheaper batches, using the trade-offs described in the producer configs: 1) linger.ms: the producer waits up to this delay for more records to fill a batch (default 5 since Kafka 4.0); raising it trades a little latency for fewer, larger requests. 2) batch.size: the batch size in bytes per partition (default 16384); a larger value allows bigger batches at the cost of more memory. 3) compression.type: none by default, or gzip, snappy, lz4 or zstd; compression applies to full batches, so better batching typically improves the ratio. 4) buffer.memory (default 33554432 bytes) bounds the records waiting to be sent; when it is full send() blocks for up to max.block.ms. 5) acks: all is the default and the strongest guarantee, acks=1 waits only for the leader's local write, and acks=0 does not wait, so relaxing it can be faster but weakens durability. 6) max.in.flight.requests.per.connection (default 5): allows more unacknowledged requests per connection, and must be 5 or less with idempotence. 7) More partitions let clients write to many brokers at the same time. 8) One producer instance is thread safe and generally faster to share across threads than several instances. If durability matters, keep enable.idempotence=true and acks=all.

Expected key concepts: linger.ms, batch.size, compression.type, lz4, zstd, buffer.memory, acks, max.in.flight.requests.per.connection, partitions, enable.idempotence

How did that feel?

Your own verdict, not the score. It shows up next to this question in the list, so you can come back to the shaky ones.