---
title: "Kafka linger.ms: batching latency vs throughput"
description: "What Kafka linger.ms does, its default of 5 ms since Kafka 4.0, and how it works with batch.size to trade latency for throughput. Watch batches form live."
url: https://monedula.dev/kafka-simulator/configs/linger-ms/
---

# linger.ms: how long the producer waits to fill a batch

Producer config · default 5 (milliseconds; 0 before Kafka 4.0) · Apache Kafka 4.3.

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).

## At a glance

- Config: `linger.ms` (producer)
- Default: 5 (milliseconds; 0 before Kafka 4.0)
- Valid values: 0 or more
- Reference: [Apache Kafka documentation](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_linger.ms)

## 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](https://monedula.dev/kafka-simulator/scenarios/linger-and-batch-size/) (linger.ms and batch.size), step 3: linger.ms elapsed · 2-record batch flushed. No more records arrived, so at linger.ms the batch flushed: O1 and O2 append together (LEO 2) as a single request. Time-triggered flush. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=01.2.1&t=2)
- [Tune Kafka throughput: linger.ms, batch.size and zstd](https://monedula.dev/kafka-simulator/scenarios/tune-high-throughput-low-latency/) (Capstone: tune a high-throughput, low-latency pipeline), step 3: One compressed batch flushed - HW climbs. At the linger deadline the whole burst flushes as a SINGLE compressed request (one batch_flush, not the 4+2 that batch.size=4 alone would produce). The DC-A sync ISR commits all six and the high-watermark jumps to 6 - fewer requests, higher throughput. The DC-B observer is still at offset 0. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=12.0.5&t=2)

## Related configs

- [Kafka batch.size: how producer batching works](https://monedula.dev/kafka-simulator/configs/batch-size/)
- [Kafka compression.type: gzip vs snappy vs lz4 vs zstd](https://monedula.dev/kafka-simulator/configs/compression-type/)
- [Kafka acks: 0 vs 1 vs all explained](https://monedula.dev/kafka-simulator/configs/acks/)