Сервис стабильно получает 200 запросов в секунду при средней задержке 300 мс. Как оценить число запросов, одновременно находящихся в системе?
Оценка выполняется по закону Литтла: среднее число запросов в системе равно интенсивности поступления, умноженной на среднее время пребывания. В данном случае это примерно 200 × 0,3 = 60 запросов одновременно.
Эта величина включает запросы, находящиеся в обработке, ожидающие свободного ресурса или стоящие во внутренних очередях. Она не равна напрямую числу процессов, потоков или серверов.
Закон Литтла возник в теории массового обслуживания как способ связать поток заявок, время их пребывания и средний размер очереди. Для системного проектирования он полезен тем, что позволяет оценить требуемую степень параллелизма даже при неполных сведениях о внутренней реализации.
Подход особенно важен при переходе от пользовательского показателя задержки к инфраструктурному: число одновременных запросов влияет на потребление памяти, соединений с базой, рабочих потоков и других ограниченных ресурсов.
Одного значения RPS недостаточно для оценки нагрузки. Два сервиса с одинаковыми 200 запросами в секунду могут иметь принципиально разное число одновременных запросов: при задержке 20 мс — около 4, а при задержке 2 секунды — около 400.
Если игнорировать задержку, можно недооценить число соединений и размер очередей. Это приводит к исчерпанию пулов, росту тайм-аутов и каскадному ухудшению задержки. Обратная ошибка тоже возможна: расчёт по редкому пиковому периоду без учёта фактической загрузки приводит к избыточному резервированию.
Закон Литтла записывается как N = λ × R, где N — среднее число запросов в системе, λ — средняя интенсивность поступления, а R — среднее время пребывания запроса в системе.
Для заданных значений:
Полученные 60 — это среднее число запросов «в полёте». Если запрос проводит часть времени в очереди, а часть — выполняется, обе части входят в R. Поэтому нельзя автоматически утверждать, что сервису нужны ровно 60 рабочих потоков: один поток может не обслуживать запрос во время ожидания ввода-вывода, а модель обработки может быть асинхронной.
Для расчёта ёмкости нужно использовать согласованные периоды измерения. Если взять пиковый RPS и среднюю задержку, измеренную в другом режиме, оценка будет неточной. На практике отдельно анализируют среднее, высокие перцентили задержки, длину очередей, долю ошибок и ограничивающие ресурсы.
Закон описывает среднее состояние, а не хвост распределения. Например, средняя задержка 300 мс может скрывать редкие задержки в несколько секунд. Поэтому для настройки тайм-аутов и пулов соединений нужны также перцентили и запас по ёмкости.
API получает 200 запросов в секунду, средняя задержка составляет 300 мс, а каждый запрос обращается к базе данных. Команда решила создать ровно 60 рабочих потоков, считая это прямым следствием расчёта.
Рассматривались два варианта. Увеличение числа потоков могло повысить пропускную способность при ожидании ввода-вывода, но одновременно увеличивало потребление памяти и конкуренцию за соединения с базой. Ограничение числа потоков уменьшало риск перегрузки базы, но при слишком малом пуле создавало очередь и повышало задержку.
Выбрали расчёт по закону Литтла как начальную оценку, а затем проверили её нагрузочным тестом с контролем пула соединений, длины очереди и перцентилей задержки. В результате размер рабочих пулов и число соединений настроили по фактическому узкому месту, а не приравняли механически к 60. Это позволило избежать ложного вывода, что оценка конкуренции автоматически определяет конфигурацию сервиса.
Если входной поток устойчиво превышает способность обработки, задержка растёт, а число запросов в системе увеличивается. Закон Литтла по-прежнему связывает измеренные средние величины, но фиксированная оценка 60 перестаёт быть прогнозом устойчивого рабочего состояния: она была получена из прежних значений RPS и задержки, которые уже меняются.
Следовательно, нужно не просто увеличить параллелизм, а найти ограничивающий ресурс и применить управление нагрузкой: ограничить очередь, ввести обратное давление, отклонять лишние запросы или масштабировать узкое место. Иначе рост очереди будет продолжать увеличивать задержку.
Нет, это не даст строгое среднее число запросов в системе. Закон Литтла использует согласованные средние значения, тогда как p95 описывает только границу, ниже которой находятся примерно 95% наблюдений.
P95 полезен для оценки сценария, в котором важен хвост задержки, но результат будет эвристическим верхним ориентиром, а не точным средним количеством запросов. Для оценки ресурсов дополнительно измеряют распределение задержек и моделируют нагрузку по нужному перцентилю.
Нужно отдельно наблюдать входной RPS, полную задержку запроса, время ожидания в очередях и задержку каждой зависимости. При неизменном RPS рост задержки увеличивает число запросов в системе по закону Литтла, поэтому увеличение конкуренции в таком случае указывает на ухудшение обработки или зависимой системы.
Если одновременно растут RPS и задержка, причины могут сочетаться. Разбиение задержки по этапам и сравнение метрик во времени помогают определить, вызван ли рост конкуренции входным потоком, медленной базой, исчерпанием пула или внутренней очередью.