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