Сравните открытую и закрытую модели нагрузки: чем принципиально различается поведение системы после достижения её предельной пропускной способности?
В закрытой модели число активных пользователей фиксировано: новый запрос обычно появляется после завершения предыдущего, поэтому замедление системы само снижает интенсивность поступления запросов. В открытой модели запросы поступают с заданной интенсивностью независимо от состояния сервиса, поэтому после достижения предела пропускной способности растут очередь, задержка и, возможно, число ошибок.
Модели нагрузки появились как способ отделить два разных источника поведения системы: активность пользователей и способность сервиса обрабатывать поступающие запросы. Закрытая модель естественно описывает ограниченную популяцию клиентов, а открытая — поток независимых событий, например входящие сообщения или запросы к публичному API.
Без такого различия результаты нагрузочного теста легко интерпретировать неверно: одинаковое число виртуальных пользователей и одинаковая интенсивность поступления запросов создают разные условия для очередей и перегрузки.
Предположим, сервис способен устойчиво обрабатывать только определённую интенсивность запросов. В закрытой модели пользователи, получившие медленный ответ, остаются занятыми, поэтому новые запросы от них временно не поступают. Тест может показать рост задержки, но не воспроизвести реальный внешний поток, который продолжает приходить.
В открытой модели превышение предела обработки приводит к накоплению незавершённых запросов. Если нагрузка сохраняется, очередь может расти без ограничений, тайм-ауты начинают усиливать занятость ресурсов, а система переходит в режим каскадной деградации. Неверный выбор модели способен сделать устойчивый сервис выглядящим перегруженным или, наоборот, скрыть реальную перегрузку.
Закрытая модель задаёт число одновременно действующих клиентов. Клиент отправляет следующий запрос после завершения предыдущего, иногда с учётом времени размышления. При увеличении задержки каждый клиент генерирует запросы реже, поэтому фактический входной поток частично уменьшается.
Открытая модель задаёт интенсивность прибытия запросов независимо от времени ответа. Если сервис обрабатывает запросы медленнее, чем они прибывают, разница накапливается в очереди. После превышения устойчивой пропускной способности задержка обычно растёт нелинейно, а при ограниченных тайм-аутах появляются ошибки и отмены.
Закрытая модель подходит для оценки опыта ограниченного числа пользователей, например рабочих мест корпоративной системы. Открытая модель предпочтительна для проверки API, брокера сообщений или другого сервиса, где входной поток не останавливается только потому, что обработка предыдущих запросов замедлилась.
Выбор модели не означает, что одна из них всегда правильная. В реальной системе могут существовать оба типа клиентов, поэтому иногда нужны отдельные прогоны или смешанная модель. При открытой нагрузке важно контролировать генератор: он должен поддерживать заданный поток даже при росте задержек, иначе тест незаметно превратится в закрытый.
Нельзя считать сам факт роста очереди доказательством дефекта приложения. Очередь может быть ожидаемой частью архитектуры, если её размер ограничен, а задержка и время ожидания соответствуют SLA. Анализируют одновременно интенсивность поступления, интенсивность завершения, длину очереди, задержки, тайм-ауты и ошибки.
Команда тестировала API заказов, который получает независимые запросы от мобильных клиентов. В первом варианте использовали фиксированное число виртуальных пользователей. При замедлении базы данных клиенты дольше ждали ответы, поэтому фактический поток запросов снизился, а очередь на входе почти не росла.
Рассматривались два варианта. Сохранить закрытую модель было проще и ближе к сценарию отдельного пользователя, но она могла скрыть поведение API при непрерывном внешнем потоке. Перейти сразу к очень высокой открытой нагрузке позволяло быстрее обнаружить предел, однако это повышало риск переполнения очередей и затрудняло отделение штатного насыщения от аварийного перегруза.
Выбрали ступенчатую открытую модель с контролируемой интенсивностью и ограниченной длительностью каждой ступени. Параллельно собирали число принятых, завершённых и просроченных запросов, длину очередей и загрузку зависимостей. Такой прогон показал реальную точку, после которой входной поток превышал скорость обработки; закрытый сценарий оставили отдельно для оценки пользовательского опыта.
Ответ: Да. При фиксированном числе клиентов рост времени ответа увеличивает время, в течение которого каждый клиент занят. Поэтому новые запросы начинают поступать реже, хотя уже выполняющиеся операции могут дольше ожидать процессор, базу данных или другой ресурс. Входная очередь при этом не обязана расти: ограничение потока происходит на стороне клиентов модели.
Ответ: Это означает, что в текущем режиме средняя скорость поступления запросов выше устойчивой скорости их завершения. Пока такое соотношение сохраняется, очередь не может стабилизироваться; кратковременное снижение задержки не доказывает восстановление системы. Нужно проверить, не связаны ли запросы с тайм-аутами или отменами: формальное освобождение входной очереди может сопровождаться потерей запросов, а не успешной обработкой.
Ответ: В закрытой модели интенсивность обычно является следствием числа клиентов, задержки и времени размышления. При ухудшении ответа она меняется вместе с состоянием системы. В открытой модели интенсивность задаётся извне и сохраняется независимо от задержки, поэтому та же номинальная величина может привести к накоплению очереди и существенно большей длительности перегруза. Кроме того, распределение интервалов между прибытием запросов влияет на кратковременные пики, поэтому сравнивать нужно не только среднюю интенсивность, но и форму потока.