linger.ms
performancedefault: 0
type: long (milliseconds)
linger.ms tells the producer to wait up to N milliseconds for more records before sending an incomplete batch. Default 0 sends batches immediately (lowest latency, lower throughput). Increasing linger.ms allows the producer to accumulate more records into fewer, larger batches – improving throughput and compression ratio at the cost of added latency.
Details
linger.ms is a deliberate artificial delay. It mirrors TCP's Nagle algorithm concept: wait a bit to aggregate small writes into larger chunks.
With linger.ms=0 (default): Every record is sent as soon as it is produced (or when batch.size is reached). Lowest per-record latency. Potentially many small batches if records arrive one at a time.
With linger.ms=5: Producer waits up to 5ms for more records to accumulate in the batch. Records produced within that 5ms window are batched together. Better throughput, 5ms added latency maximum.
Practical guidance: linger.ms=0: REST APIs, user-facing event tracking where per-event latency matters linger.ms=5–20: microservice event buses where throughput matters more linger.ms=100+: log aggregation, analytics pipelines, batch ETL
With compression: linger.ms and batch.size work synergistically with compression. Larger batches compress better (more repetition to exploit). A pipeline using linger.ms=100 + compression.type=lz4 + batch.size=1MB can achieve 5–10x better throughput than defaults.
Note: linger.ms adds to end-to-end latency even when records are waiting at the producer. For real-time streaming applications sensitive to end-to-end latency, keep linger.ms=0.
Recommended values
| Scenario | Value |
|---|---|
| Real-time, low latency required | linger.ms=0 (default) |
| Throughput-first pipelines | linger.ms=10–50 |
| Batch/analytics with compression | linger.ms=100–500 |