Окно батчинга: размер и время ожидания

Вы поднимаете linger.ms у Kafka-продюсера с 0 до 10 — и throughput взлетает в 10 раз ценой всего 10мс лишней латентности. Apache сделал тот же выбор за всех: в Kafka 4.0 (март 2025) дефолт linger.ms сменили с 0 на 5мс после многих лет на нуле. Аргумент команды был жёстким — погоня за немедленностью на стороне отправителя не даёт глобально низкую латентность. Крошечная искусственная задержка покупает эффективность батчинга, которая часто снижает сквозную латентность. Чтобы понять, почему задержка в 5мс делает систему быстрее, нужно разобрать двумерное окно под капотом.

Два триггера, а не одна ручка

У любой системы батчинга, которую вы будете тюнить, ровно два лимита: max-size (байты или число записей) и max-wait (таймер). Элементы копятся в буфере. Батч сбрасывается в тот миг, когда сработал любой из лимитов — буфер дорос до max-size или таймер дошёл до max-wait. Это OR, а не AND. В Kafka это batch.size и linger.ms; в Redis-пайплайнинге — буфер клиента и то, сколько вы даёте ему наполняться; в bulk-insert БД — строк на запрос и интервал сброса. Везде одна и та же форма.

Наивный инстинкт — выдать одну ручку («просто задай размер батча»), и каждый сеньор видел, как этот инстинкт поднимал кого-то в 3 ночи. Нужны обе, потому что у каждой в одиночку есть провал, который закрывает другая.

Почему один размер застревает, а одно время переполняет

Убери max-wait, оставь только max-size: теперь медленный продюсер берёт батч в заложники. Трафик проседает в 2 ночи, элементы капают, батч никогда не дорастает до batch.size и потому не сбрасывается. Первое сообщение полупустого батча может лежать секундами — неограниченная латентность, которая растёт обратно пропорционально нагрузке. Это классический head-of-line stall: лекарство — таймер, который говорит «шли что есть».

Убери max-size, оставь только max-wait: теперь быстрый продюсер собирает монстра. Прилетает Чёрная пятница, элементы хлынули, и за окно в 50мс буфер раздувается до того, что downstream не проглотит — запрос больше брокерского message.max.bytes, пакет фрагментируется, транзакция разносит WAL, массив роняет консьюмер по OOM. Лекарство — лимит размера, который говорит «шли, пока не разросся». Нужны обе, потому что они ломаются в противоположные стороны: размер защищает throughput, время защищает латентность, и убрав любую, вы возвращаете тот баг, который другая и закрывала.

Математика ускорения, по шагам

Смоделируем любую операцию на элемент как фиксированную стоимость F (накладные на вызов — syscall, сетевой round-trip, begin/commit транзакции) плюс переменную стоимость V*n (работа пропорционально payload размера n). N элементов по отдельности стоят:

N * (F + V*n)

Те же элементы одним батчем платят фиксированную стоимость один раз и ту же переменную работу:

F + V*(N*n)

Ускорение — это отношение:

speedup = (N*F + N*V*n) / (F + V*N*n)

Смотрим на две крайности. Когда доминирует фиксированная стоимость — F > V*n, то есть маленькие payload, где накладные на вызов и есть вся история — член N*F забивает всё и speedup → N. Сбатчили 100 элементов — стали быстрее в ~100 раз. Когда доминирует переменная — F < V*n, большие payload, где вы и так платите в основном за байты — член V*N*n забивает всё и speedup → 1: батчинг не даёт ничего, потому что не было фиксированной стоимости для амортизации. Перелом, точка безубыточности — это F = V*n: когда переменная стоимость одного элемента равна фиксированным накладным, батчинг начинает окупаться.

Конкретное число

Возьмём сетевую операцию: пакеты по 1КБ, round-trip 50мкс на вызов как фиксированная стоимость и батч из 100 элементов. По одному round-trip’ы стоят 100 * 50мкс = 5мс. Батчем вы платите round-trip один раз плюс байты — пусть ~150мкс всего. Это 5мс до 150мкс, ~33x ускорение, потому что здесь F (RTT 50мкс) сильно перевешивает V*n (время передачи на КБ). Ровно в этом режиме живёт Redis-пайплайнинг: опубликованный бенчмарк шлёт 10 000 PING за 1.185с без пайплайна и за 0.250с с пайплайном — ~5x — и разрыв растёт по мере роста RTT относительно работы на команду. Версия с syscall-ами та же по духу: syscall стоит ~1–5мкс, поэтому схлопывание 300k syscall-ов в ~4k через большие буферизованные записи делает накладные на вызов фактически нулевыми.

Нагрузка решает, какой триггер главный

Поведение окна не статично — оно смещается с трафиком. При высокой нагрузке элементы хлынули, и буфер достигает max-size задолго до таймера; размер — доминирующий триггер, вы упёрлись в throughput. При низкой нагрузке ручеёк не наполняет буфер, поэтому таймер срабатывает первым; доминирует время, вы упёрлись в латентность. Практическая диагностика: смотрите средний размер батча против заданного max-size. Если батчи стабильно сбрасываются у max-size — побеждает размер, поднимайте его. Если сбрасываются мелкими и по таймеру — побеждает время, и поднимать linger.ms помогает только пока батч не начнёт наполняться раньше истечения таймера.

Разбор живой системы: max-size 10000 байт, max-wait 5мс, и вы видите батчи в среднем 8000 байт каждые 4мс. Таймер срабатывает первым (4ms < 5ms), но буфер не полон (8000 < 10000) — умеренная нагрузка, доминирует время. Поднятие max-wait увеличит батчи и throughput, но только до точки, где буфер наполняется раньше таймера.

Разумные дефолты и как реально тюнить

Разумные стартовые точки — max-wait 10–100мс и max-size 64КБ–1МБ; high-throughput-рецепт Kafka — batch.size 64КБ–256КБ с linger.ms 20–100мс, а сбалансированный продакшен-конфиг вроде batch.size=32768, linger.ms=10, compression.type=lz4, acks=1 даёт ~25k msg/s при латентности под 20мс. Но дефолты — стартовая линия, а не ответ. Сеньорский ход — выводить ожидание из SLO латентности, а не из жажды максимального throughput: берите наибольший linger.ms, который терпит ваш бюджет p99, затем подбирайте буфер так, чтобы он наполнялся у этого таймера на пиковой ожидаемой нагрузке. Дальше — проверяйте так, как нельзя на доске: проигрывайте реальный продакшен-трафик в staging, прогоняйте обе ручки и читайте фактическое распределение размеров батча и хвостовую латентность. Синтетическая равномерная нагрузка врёт; продакшен бёрстовый, и только реплей покажет, какой триггер доминирует на вашей реальной форме трафика.