Как распознать по кривой «нагрузка—задержка» момент насыщения системы?
Момент насыщения обычно виден как переход от почти стабильной задержки к её непропорционально быстрому росту при небольшом увеличении нагрузки. Это означает, что один или несколько ресурсов начали формировать очередь, а система приблизилась к пределу устойчивой производительности.
Нельзя считать точкой насыщения любую точку роста задержки: нужно сопоставить её с пропускной способностью, ошибками, утилизацией ресурсов и целевым SLA. Практический предел часто выбирают немного раньше резкого изгиба кривой, чтобы оставить запас для вариативности нагрузки.
Нагрузочное тестирование появилось как способ заранее оценивать поведение системы под ожидаемым и повышенным трафиком, а не проверять её только на функциональную корректность. Одной из исходных проблем было отсутствие ответа на практический вопрос: при каком объёме работы система ещё обслуживает запросы предсказуемо, а после какого начинает накапливать ожидание.
Анализ кривой «нагрузка—задержка» помогает перейти от простого вопроса «выдерживает ли система заданный трафик» к оценке области устойчивой работы и запаса производительности.
Система может формально продолжать отвечать на запросы после достижения насыщения, но делать это с растущими очередями и задержками. Из-за этого средняя пропускная способность иногда выглядит приемлемо, тогда как пользовательский опыт и процент запросов, нарушающих SLA, быстро ухудшаются.
Если принять пиковую точку кривой за рабочую ёмкость, небольшой всплеск трафика, изменение состава операций или замедление внешней зависимости может привести к тайм-аутам. Если, наоборот, объявить насыщением первый небольшой рост задержки, можно неоправданно занизить допустимую нагрузку.
Сначала строят зависимость между фактической интенсивностью нагрузки и задержкой, используя несколько устойчивых уровней нагрузки. Для каждого уровня исключают прогрев и переходные периоды, затем сравнивают p95 или p99, пропускную способность, долю ошибок и состояние ключевых ресурсов.
До насыщения увеличение нагрузки часто почти не меняет задержку: свободные ресурсы обслуживают работу сразу. Вблизи предела свободная мощность исчезает, запросы начинают ждать CPU, пул соединений, диск, сеть, внешний сервис или другой ограниченный ресурс. Время ожидания добавляется к времени обработки, поэтому задержка начинает расти быстрее самой нагрузки.
На практике ищут не только визуальный «изгиб», но и согласованность признаков:
Рабочую границу следует определять относительно SLA. Если SLA требует p95 не выше заданного значения, точкой capacity является максимальная устойчивая нагрузка, на которой это условие выполняется в течение всего стабильного интервала, а не кратковременный максимум перед деградацией.
Есть важные ограничения. Изменение кривой может быть вызвано не насыщением, а сменой состава запросов, кэшированием, автоскейлингом, ограничением генератора нагрузки или внешней зависимостью. Поэтому результаты нужно подтверждать телеметрией и повторными прогонами с одинаковой моделью нагрузки.
Сервис проверяли ступенями по 100 операций в секунду. До 600 операций задержка p95 оставалась около 180 миллисекунд, при 700 возрастала до 240, а при 800 — до 900 миллисекунд; одновременно росло ожидание соединения с базой данных.
Рассматривались два варианта. Объявить capacity равной 800 операциям в секунду было бы просто, но это означало бы принять уже нестабильный режим. Выбрать 600 операций в секунду без дополнительной проверки было бы безопаснее, но не показывало бы, есть ли запас между SLA и резким ухудшением.
Команда повторила уровни 600, 650 и 700 операций в секунду с продолжительными стабильными интервалами. При 650 p95 оставалась в SLA, а при 700 периодически нарушала его, поэтому рабочую границу установили на 650 операций в секунду с запасом ниже зоны насыщения. Дополнительно подтвердили, что ограничением был пул соединений к базе данных, а не генератор нагрузки.
1. Дополнительный вопрос: достаточно ли найти визуальный изгиб кривой, чтобы определить capacity?
Нет. Визуальная форма зависит от масштаба графика, выбранного процентиля и длительности измерения. Capacity должна быть связана с явными критериями: SLA, допустимой долей ошибок, устойчивостью пропускной способности и воспроизводимостью результата.
Например, резкий рост p99 при стабильном среднем может означать локальные очереди или редкие блокировки. Поэтому нужно анализировать распределение задержек, а не только среднее значение и форму одной линии.
2. Дополнительный вопрос: почему после точки насыщения пропускная способность не обязательно падает сразу?
Ограниченный ресурс может быть полностью занят, но продолжать обслуживать примерно тот же объём работы. Новые запросы при этом накапливаются в очередях, поэтому пропускная способность плато сохраняется, а задержка растёт.
Падение пропускной способности начинается позже, когда возникают тайм-ауты, повторные попытки, взаимное вытеснение ресурсов или каскадная перегрузка. Следовательно, плато RPS не доказывает, что режим безопасен для пользователей.
3. Дополнительный вопрос: как отличить насыщение системы от ограничения генератора нагрузки?
Нужно проверить, может ли генератор фактически поддерживать требуемую интенсивность, и сопоставить его загрузку с метриками целевой системы. Если CPU, память, сеть или число рабочих потоков генератора исчерпаны, а приложение не показывает признаков роста очередей и задержки обработки, тест не достиг насыщения приложения.
Полезны независимые признаки: фактическая скорость отправки, время планирования операций на генераторе, задержка до отправки запроса и результаты нескольких генераторов. Если увеличение генераторного ресурса позволяет достичь большей нагрузки без изменения поведения приложения, прежний предел относился к тестовой инфраструктуре.