Kafka producer config
linger.ms: how long the producer waits to fill a batch
linger.ms is how long the Kafka producer waits for more records before it sends a batch that is not full yet. A batch goes out when it reaches batch.size or when linger.ms runs out, whichever comes first. The default is 5 ms since Kafka 4.0 (it was 0 before).
- Config
linger.(producer)ms - Default
- 5 (milliseconds; 0 before Kafka 4.0)
- Valid values
- 0 or more
What it does
The producer collects records per partition into batches and sends each batch as part of a produce request. With linger.ms at 0 a batch is sent as soon as the sender thread is free, so batching happens only under load. A small delay lets more records join each batch, so the same data goes out in fewer, larger requests that also compress better.
The trade-off
A higher linger.ms adds up to that much latency to a record that arrives when traffic is light, in exchange for fewer requests, less broker CPU and better compression. Under heavy load batches fill to batch.size before linger.ms runs out, so the delay costs nothing there. A lower value cuts latency at light load and sends more, smaller requests.
Advice
- For throughput, try 10 to 100 ms together with a larger batch.size and compression, and measure end-to-end latency, not only throughput.
- For latency-sensitive traffic the default of 5 ms is already a good compromise; 0 gives back at most those few milliseconds.
- Keep delivery.timeout.ms at least request.timeout.ms plus linger.ms.
See it in the simulator
- Kafka linger.ms vs batch.size: when the producer sends (linger.ms and batch.size) Step 3: linger.ms elapsed · 2-record batch flushed Open at this step: Kafka linger.ms vs batch.size: when the producer sends
- Tune Kafka throughput: linger.ms, batch.size and zstd (Capstone: tune a high-throughput, low-latency pipeline) Step 3: One compressed batch flushed - HW climbs Open at this step: Tune Kafka throughput: linger.ms, batch.size and zstd