ТестированиеНагрузочное тестированиеИнженер по нагрузочному тестированию

Объясните механизм, позволяющий по пропускной способности и средней задержке проверить согласованность заяв...

Объясните механизм, позволяющий по пропускной способности и средней задержке проверить согласованность заявленной одновременности запросов в нагрузочном тесте.

Проходите собеседования с ИИ помощником Hintsage

Краткий ответ

Для проверки используют закон Литтла: среднее число запросов в системе равно произведению средней пропускной способности на среднее время пребывания запроса в системе: L = λ × W. Поэтому заявленная одновременность должна быть примерно согласована с измеренными RPS и средней задержкой, если они относятся к одной границе системы и одному интервалу наблюдения.

Например, при 200 запросах в секунду и средней задержке 0,5 секунды в системе в среднем находится около 100 запросов. Если отчёт заявляет 1000 одновременных запросов при тех же показателях, нужно искать различие в методике измерения, простои виртуальных пользователей или ошибку агрегации.

Исторический контекст

Закон Литтла возник как общий результат теории массового обслуживания для анализа очередей и потоков заявок. Он нужен, чтобы связать три практически наблюдаемые величины: количество объектов внутри системы, скорость их прохождения и среднее время пребывания.

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

Постановка проблемы

Отчёт может одновременно показывать высокую заявленную конкуренцию, низкую задержку и небольшой поток запросов. Такое сочетание не всегда означает ошибку: виртуальные пользователи могут долго ждать между итерациями, часть времени проводить вне измеряемой операции или учитывать не только активные запросы, но и готовые к работе экземпляры.

Неверная интерпретация приводит к ложным выводам о пропускной способности системы. Например, команда может решить, что сервис выдерживает тысячу пользователей, хотя одновременно выполнялось лишь несколько десятков запросов, а остальные пользователи находились в паузах или ожидали генератор нагрузки.

Подробное решение

Сначала нужно определить границы измерения. L — среднее число запросов, находящихся внутри выбранной системы; λ — фактическая скорость завершения запросов; W — среднее время от входа запроса в эту систему до выхода из неё.

Все три величины должны описывать один объект и один период. Нельзя умножать RPS приложения на задержку, измеренную только внутри базы данных, и сравнивать результат с количеством активных пользователей генератора. Также нельзя без оговорок подменять среднюю задержку медианой или p99: закон использует среднее время.

Практическая проверка выполняется так:

  1. взять средний throughput за устойчивый участок теста;
  2. взять среднее время пребывания запроса в той же измеряемой области;
  3. перемножить их и сравнить результат с наблюдаемой средней конкуренцией;
  4. изучить расхождение через границы измерения, паузы пользователей, очереди и незавершённые запросы.

Закон применим при достаточно устойчивом режиме, когда система не только накапливает бесконечную очередь и не находится в переходном периоде запуска или остановки. При коротком тесте, резком разгоне нагрузки или наличии отменённых запросов равенство может нарушаться из-за разных интервалов и правил учёта.

Важно различать конкурентность запросов и число виртуальных пользователей. Пользователь может выполнять запрос, затем ждать заданную паузу; в этот момент он входит в число виртуальных пользователей, но не в число запросов внутри сервиса. Поэтому для проверки закона лучше использовать активные операции на общей границе измерения, а не количество зарегистрированных сценариев.

Ситуация из практики

В отчёте указано 600 виртуальных пользователей, 120 завершённых запросов в секунду и средняя сквозная задержка 0,4 секунды. При применении закона Литтла ожидаемая средняя конкуренция запросов составляет около 48, а не 600.

Рассматривались три объяснения. Можно было объявить отчёт ошибочным, но это не учитывало паузы пользователей. Можно было увеличить интенсивность нагрузки, однако это изменило бы проверяемый профиль и могло скрыть исходную проблему. Наконец, команда разделила метрики на число виртуальных пользователей, активные запросы и время паузы между итерациями.

Выбранный вариант показал, что большинство пользователей находилось в think time, а 48 запросов действительно одновременно проходили измеряемый участок. После этого тест дополнили отдельным контролем целевого RPS и явной публикацией границ метрик. Результат оказался полезнее первоначального вывода о якобы высокой одновременной нагрузке: стало понятно, какую нагрузку фактически выдерживал сервис.

Что кандидаты часто упускают

  1. Можно ли применять закон Литтла к p95 или p99 задержки?

Нет, напрямую нельзя. Закон связывает среднюю конкуренцию со средней скоростью потока и средним временем пребывания. Высокие перцентили полезны для анализа хвоста распределения, но произведение RPS на p99 не даёт среднее число запросов в системе и не должно использоваться как точная проверка закона.

  1. Почему равенство может не сходиться во время разгона нагрузки?

В переходный период число запросов внутри системы меняется: часть заявок уже вошла, но ещё не завершилась, а поток завершений отражает состояние с запаздыванием. Закон лучше проверять на устойчивом участке, где средняя конкуренция и скорость завершения не испытывают существенного систематического дрейфа.

  1. Что означает большое расхождение между расчётной и наблюдаемой конкуренцией?

Это сигнал для проверки методики, а не автоматическое доказательство узкого места. Возможны разные границы измерения, учёт виртуальных пользователей вместо активных запросов, паузы, очереди в генераторе, ретраи, отмены или неодинаковые интервалы агрегации. Если границы согласованы, устойчивый избыток активных запросов обычно указывает на очередь или незавершённую работу, а недостаток — на простои, паузы или неполный учёт потока.