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