Как считать capacity для очереди задач, а не угадывать

Вопрос звучит просто: «сколько воркеров нужно поставить под эту очередь». На деле проверяют, умеете ли вы связать пропускную способность, время обработки одной задачи и допустимую задержку в одну формулу — а не называете число из головы.

Базовая модель: throughput = workers / avg_processing_time. Если задача в среднем обрабатывается 200 мс, один воркер даёт 5 задач в секунду. Нужно 500 задач в секунду — минимум 100 воркеров, при идеальной утилизации.

Идеальной утилизации не бывает. Нужен запас под пики, под GC-паузы, под то, что часть задач зависает дольше среднего. На практике закладывают буфер в 1.5–2x от расчётного минимума — иначе при малейшем росте нагрузки очередь начинает копиться, а не обрабатываться.

Глубина самой очереди — отдельный параметр, не равный числу воркеров. Буфер должен выдержать всплеск трафика на время, пока автоскейлинг поднимет новые воркеры. Если скейлинг занимает 2 минуты, а пиковый прирост — 1000 задач в секунду, буфер должен держать хотя бы 120 000 задач, иначе продюсер начнёт получать отказы раньше, чем подоспеет новая мощность.

int workers = (int) Math.ceil( targetThroughput * avgProcessingSec ); int bufferedCapacity = workers

• scaleUpTimeSec
• burstFactor;

На собесе после расчёта почти всегда спрашивают: а что если avg_processing_time — это среднее, а у вас 5% задач висят в 10 раз дольше? Правильный ответ — считать не по среднему, а по p95 или p99 времени обработки, иначе буфер окажется рассчитан на оптимистичный случай и не выдержит реальный хвост распределения.

Число воркеров без формулы — это угадайка. С формулой — это расчёт, который можно пересчитать, когда нагрузка изменится.

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки