Команда сохраняет общий RPS, но меняет долю операций чтения и записи. Объясните, почему предел производительности системы может измениться.
Предел производительности может измениться, потому что одинаковый общий RPS не означает одинаковую стоимость нагрузки. Чтения и записи могут по-разному потреблять CPU, память, дисковые операции, блокировки, соединения с базой данных и ресурсы внешних сервисов.
Поэтому реалистичная нагрузочная модель должна учитывать не только общий поток запросов, но и структуру рабочего профиля — доли разных операций и их последовательности.
Ранние упрощённые нагрузочные тесты часто использовали один тип запроса и один показатель интенсивности. Такой подход был удобен для воспроизводимости, но плохо отражал работу реальных систем, где пользовательские сценарии состоят из операций с разной стоимостью.
Модели рабочего профиля появились как способ приблизить тест к реальному распределению действий пользователей. Это позволяет оценивать не абстрактную способность обработать запросы, а поведение системы при характерном сочетании операций.
Предположим, система обрабатывает 1000 запросов в секунду. В одном тесте 90% запросов — чтения, а в другом 50% — записи. Общий RPS одинаков, но записи могут вызывать проверку ограничений, блокировки, журналирование, репликацию и дополнительные обращения к хранилищу.
Если сравнивать такие тесты только по общему RPS, можно ошибочно решить, что производительность изменилась без причины или что система выдерживает одинаковую бизнес-нагрузку. Неверная модель приводит к неправильному выбору узкого места и к риску выпуска системы, которая не выдержит реальный профиль операций.
Каждой операции соответствует собственная потребность в ресурсах и собственный путь выполнения. Чтение может обслуживаться из кэша, а запись — проходить через транзакцию, блокировку, обновление индексов и отправку данных на реплики. Поэтому итоговая нагрузка определяется не только количеством запросов, но и их взвешенным составом.
При изменении долей операций меняется распределение потребления ресурсов. Например, рост доли записей способен раньше исчерпать пропускную способность диска или базы данных, тогда как рост доли тяжёлых чтений может упереться в CPU или сеть.
Корректный анализ включает отдельные показатели по типам операций: интенсивность, задержки, ошибки и насыщение зависимостей. Общий RPS полезен как агрегат, но его недостаточно для сравнения тестов с разными профилями.
Рабочий профиль следует задавать на основе производственных данных или явно описанного бизнес-сценария. Если реальные доли неизвестны, нужно зафиксировать допущения и провести анализ чувствительности: проверить, как меняется результат при разумном увеличении доли наиболее дорогих операций.
Главный компромисс состоит в том, что реалистичная модель сложнее и труднее воспроизводится. Слишком упрощённый профиль проще запускать, но он снижает применимость результатов; слишком детальная модель повышает стоимость подготовки и усложняет поиск причин деградации.
Для интернет-магазина команда проверяла предел в 1200 запросов в секунду. Сначала тест состоял на 90% из чтений каталога и на 10% из записей. Он показал приемлемые задержки, поэтому команда сочла систему готовой к пиковому трафику.
Затем выяснилось, что во время рекламной кампании растёт доля добавлений в корзину и оформления заказов. В повторном тесте общий RPS оставили прежним, но увеличили долю записей. Задержки операций записи резко выросли, а затем начали замедляться и чтения из-за блокировок и исчерпания ресурсов базы данных.
Рассматривались два варианта. Можно было оставить единый усреднённый профиль: это упрощало сравнение запусков, но скрывало поведение системы на пиковом бизнес-сценарии. Другой вариант — использовать несколько профилей: обычный, рекламный и сценарий оформления заказа; он требовал больше тестов, зато позволял связать результат с реальными рисками.
Выбрали второй вариант и отдельно ограничили допустимые задержки для чтений и записей. В результате команда обнаружила, что общий RPS был достаточным показателем только для стабильного профиля, а для рекламного сценария критичным стало соотношение операций и нагрузка на базу данных.
1. Достаточно ли сохранить общий RPS, чтобы сравнить два нагрузочных теста?
Нет. Сравнение корректно только при сопоставимом составе операций, их размере, последовательности и характеристиках данных. При изменении профиля общий RPS становится агрегатом, скрывающим различную стоимость запросов.
Если профиль различается, результаты нужно анализировать раздельно по операциям и ресурсам. Иначе рост задержки может быть ошибочно приписан общей интенсивности, хотя причиной стало изменение состава нагрузки.
2. Может ли одинаковая доля операций давать разную нагрузку на систему?
Да. Стоимость одной и той же операции зависит от размера ответа, количества обрабатываемых записей, распределения данных по кэшу, степени конкуренции и состояния зависимостей. Поэтому фиксировать только доли операций недостаточно: важны также параметры данных и контекст выполнения.
Например, чтение популярного объекта из кэша и чтение редкого объекта из хранилища формально являются одной операцией, но создают разную нагрузку. Реалистичный тест должен учитывать такие варианты или явно фиксировать их как отдельные классы сценариев.
3. Как понять, что изменение результата вызвано именно составом нагрузки, а не случайным фактором?
Нужно провести контролируемое сравнение: оставить неизменными длительность теста, интенсивность, данные, окружение и порядок этапов, изменив только доли операций. Затем следует сопоставить задержки, ошибки и загрузку ресурсов по каждому типу операции.
Убедительным признаком будет согласованное изменение поведения: например, рост доли записей сопровождается увеличением времени ожидания базы данных, блокировок или дисковой активности. Одного общего графика задержки недостаточно, поскольку он показывает следствие, но не подтверждает причинный механизм.