Производительность
Batching: тест с выбором ответа
Шесть вопросов поперёк всего юнита. Ни один — не определение для заучивания: каждый отражает решение под нагрузкой — когда батчить, насколько широким делать окно и что ломается, когда happy path заканчивается.
Убедись, что связываешь модель фиксированной цены, окно с двумя триггерами, математику break-even и production-сбои — тот синтез, к которому вели отдельные уроки.
Платёжный сервис пишет одну durable-строку ledger на транзакцию при ~30 записях/с; SLA — 'durable до того, как мы вернём success'. Коллега предлагает COPY-батчи по 50 мс, чтобы снизить нагрузку на БД. Что решает senior и почему?
Система батчинга настроена только на max-size (без таймера max-wait). Ночью трафик падает. Каков failure mode и что чинит добавление таймера?
Для payload'ов 4 КБ, где фиксированная цена вызова ~50 µs, а передача ~40 µs на КБ — даст ли большой батч сильный speedup?
Брокеры Kafka сидят под 20% по диску и сети, но продьюсеры не могут выдать больше доли ёмкости. Продьюсеры на дефолтах Kafka 3.x. Какой первый фикс?
Консьюмер Kafka берёт poll'ом 500 записей; запись 47 бросает на десериализации. Пайплайн ретраит весь батч на любую ошибку. Лаг консьюмера растёт до миллионов и поднимается, но консьюмер выглядит здоровым. Что происходит и каков фикс?
Брокер форсит wire-уровневый max message size, но сжатый батч в 1 МБ OOM-килит его (класс CVE-2023-34455). Какова правильная защита?
Через весь юнит проходит одна последовательность решений: подтверди, что фиксированная цена доминирует над переменной, подтверди, что есть глубина очереди и запас latency, затем размерь окно — max-size для throughput, max-wait для latency, что сработает первым — до наибольшего значения под твоим SLO. Break-even — на элемент при F = V·n. Production затем превращает каждое свойство эффективности в множитель сбоя: poison-элемент убивает N (split-and-retry плюс DLQ), быстрый продьюсер затопляет очередь (ограничь её, выбери block/drop/spill осознанно), а сжатый батч — непрозрачный конверт, который надо валидировать post-decompression и per-item. Повторяющаяся ловушка senior — оптимизировать throughput, который никто не платит, ломая контракт latency или durability.