У команды есть сервис с пропускной способностью 200 запросов в секунду и средней задержкой 500 мс. Как изменится среднее число запросов в системе, если задержку снизить до 100 мс при сохранении той же пропускной способности?
Среднее число запросов в системе уменьшится со 100 до 20. Это следует из закона Литтла: среднее число находящихся в системе запросов равно произведению пропускной способности на среднее время пребывания запроса.
Расчёт: 200 запросов/с × 0,5 с = 100 запросов; после оптимизации: 200 запросов/с × 0,1 с = 20 запросов. Уменьшится именно количество запросов «в полёте», а не обязательно число физических потоков или экземпляров.
В теории массового обслуживания требовалась простая связь между потоком заявок, временем их обработки и количеством заявок внутри системы. Закон Литтла стал универсальным инструментом для анализа очередей, вычислительных систем, сетей и производительности сервисов.
Он полезен тем, что не требует знать внутреннее распределение задержек: при устойчивом режиме достаточно средних значений пропускной способности и времени пребывания.
Большое количество запросов в системе увеличивает конкуренцию за CPU, память, соединения с базой данных и другие ограниченные ресурсы. Поэтому даже при неизменном входном потоке высокая задержка может привести к росту числа одновременно обрабатываемых запросов и усилить перегрузку.
В исходном случае среднее число запросов равно 100. После снижения задержки до 100 мс оно станет равным 20, если 200 запросов в секунду действительно продолжат проходить через систему и измеряется полный интервал от поступления до завершения запроса.
Нельзя автоматически заключать, что снижение задержки увеличит пропускную способность ровно в пять раз. Пропускная способность может ограничиваться базой данных, внешней зависимостью, лимитом соединений или входным трафиком.
Формула закона Литтла: L = λ × W, где L — среднее число запросов в системе, λ — средняя пропускная способность, а W — среднее время пребывания запроса.
Для исходных условий:
После оптимизации:
Время пребывания должно включать не только собственно обработку, но и ожидание в очередях, получение соединения, обращения к зависимостям и передачу ответа. Если измерять только CPU-время, закон применят к другой, более узкой системе и получат неверный вывод о её загрузке.
Закон описывает средние значения, а не гарантирует поведение каждого запроса. Он также предполагает устойчивый режим: система не должна постоянно накапливать очередь или работать в переходном состоянии после резкого изменения нагрузки. При потере запросов нужно явно определить, считается ли пропускная способность по принятым, завершённым или успешно обработанным запросам.
Снижение задержки уменьшает необходимую конкурентность. Это может освободить память и соединения, сократить ожидание и уменьшить вероятность таймаутов. Однако если узкое место находится за пределами оптимизируемого компонента, задержка всего сервиса может не измениться.
Сервис получает 200 запросов в секунду. Профилирование показало, что в среднем 400 мс из 500 мс запрос проводит в ожидании ответа базы данных. Вариант с добавлением экземпляров приложения почти не помог бы: каждый экземпляр продолжал бы конкурировать за тот же ограниченный ресурс базы.
Рассматривались три подхода. Увеличение размера пула соединений могло повысить параллелизм, но также усилить конкуренцию за базу и увеличить задержку. Кэширование уменьшало бы число чтений, но требовало анализа актуальности данных и поведения при промахах. Оптимизация запроса и подходящего индекса снижала задержку без расширения пула, но требовала проверки влияния на запись и другие запросы.
Выбранным решением стала оптимизация запроса с последующим измерением задержки и нагрузки на базу. Если средняя задержка действительно снизилась до 100 мс при тех же 200 завершённых запросах в секунду, среднее число запросов в системе уменьшилось с 100 до 20. Это снизило конкуренцию за ресурсы, но не отменило необходимость отдельно контролировать хвостовые задержки и пиковую нагрузку.
Да. Важно только определить границы системы. Если в неё входят очередь и обработчик, то время пребывания включает ожидание, а число запросов включает ожидающие и выполняющиеся запросы. Для одного обработчика можно получить одну пару значений, для всего сервиса — другую. Нельзя смешивать длину только очереди со сквозной задержкой всего запроса.
Тогда нужно пересчитать результат с новым значением λ. Например, если после оптимизации поток завершённых запросов вырос до 300 запросов в секунду, а задержка стала 100 мс, среднее число запросов будет 300 × 0,1 = 30. Поэтому уменьшение задержки само по себе не определяет итоговую конкурентность: она зависит одновременно от задержки и фактического потока.
Непосредственно — нет. Формула оценивает среднее число запросов в выбранной системе, но не знает производительность одного экземпляра, распределение нагрузки, лимиты CPU, соединений и памяти. Для расчёта числа экземпляров нужны нагрузочный тест, целевая загрузка ресурсов, требования к отказоустойчивости и запас мощности. Закон Литтла помогает проверить согласованность измерений и оценить конкурентность, но не заменяет модель ёмкости.