Честное нагрузочное сравнение: что сломается первым

Сравнивайте не цифры, а одинаковые условия

Один сервис выдержал 800 запросов в секунду, второй — 600. Это ещё не значит, что первый быстрее: у него могли быть другие данные, прогретый кеш или более мощный стенд. Честное сравнение начинается не с запуска генератора нагрузки, а с фиксации условий. Иначе вы измерите разницу между экспериментами, а не между системами.

В теме не указаны конкретный инструмент, фреймворк или версия. Поэтому ниже — методика для HTTP-сервисов без привязки к продукту; команды и API не приводятся. Она помогает выяснить, где возникает первое ограничение: в приложении, базе данных, инфраструктуре или самом тесте.

Сначала задайте вопрос, на который ответит тест

«Сколько запросов выдерживает сервис» — плохая постановка. У неё нет критерия успеха: сервис может продолжать отвечать, но укладываться в секунду вместо нужных 200 миллисекунд. Сформулируйте проверяемое условие: например, выдержать заданную нагрузку при допустимой доле ошибок и приемлемой задержке. Конкретные пороги берите из требований продукта, а не придумывайте ради красивого графика.

Перед запуском зафиксируйте:

• одинаковые версии приложения и конфигурации, кроме параметров, которые вы намеренно сравниваете;
• состав и объём тестовых данных, состояние кешей и способ восстановления базы между прогонами;
• железо, лимиты контейнеров, число экземпляров приложения и настройки базы;
• сценарий запросов: маршруты, долю чтения и записи, размер тел, авторизацию и паузы между действиями;
• критерии результата: пропускную способность, задержки, ошибки и предельную длительность прогона.

Если меняете сразу пул соединений, число экземпляров и кеширование, итоговый выигрыш нельзя связать с одной причиной. Меняйте один фактор за прогон либо заранее планируйте матрицу эксперимента.

Как провести сравнение, не обманувшись

1. Проверьте сценарий на малой нагрузке. Убедитесь, что запросы попадают в нужные обработчики, а ответы содержат ожидаемые данные. Проверка завершена, когда ошибки сценария отделены от ошибок сервиса.
2. Зафиксируйте исходное состояние. Запишите конфигурацию, состояние данных и кешей, фоновые задачи и нагрузку на стенд. Проверка завершена, когда второй участник может восстановить те же условия.
3. Прогрейте систему, если так будет в эксплуатации. Отдельно решите, измеряете ли вы холодный старт или установившийся режим. Не сравнивайте холодный запуск одной версии с прогретой другой.
4. Подавайте нагрузку ступенями. Начните с уровня, который система обрабатывает без перегрузки, затем увеличивайте его и выдерживайте каждую ступень достаточно долго, чтобы проявились очереди и фоновые процессы. Проверка завершена, когда видны не только средние значения, но и поведение на каждой ступени.
5. Повторите прогон. Случайный всплеск соседней нагрузки или шумный стенд может изменить результат. Проверка завершена, когда повторные прогоны дают сопоставимую картину или объяснимое расхождение.
6. Сопоставьте результаты с ресурсами. Одновременно смотрите на задержки, ошибки, CPU, память, диск, сеть, соединения с базой и длину очередей. Проверка завершена, когда у найденного ухудшения есть наблюдаемая причина или сформулирована гипотеза для следующего эксперимента.

Пропускная способность показывает, сколько операций система завершает за единицу времени. Задержка показывает, как долго ждёт отдельный запрос. Высокая пропускная способность не спасает, если хвост распределения задержек выходит за продуктовый предел.

Что обычно ломается первым

Универсального порядка нет: он зависит от архитектуры, сценария и ограничений окружения. Ищите не «типичную причину», а сигнал, который совпал по времени с ухудшением результата.

• Пул соединений. Если запросы ждут свободное соединение, задержка растёт ещё до того, как база исчерпает процессор. Смотрите время ожидания соединения и число активных подключений.
• База данных. Медленные запросы, блокировки или нехватка соединений могут ограничить всё приложение. Сверяйте время запросов и ожиданий с задержками сервиса, а не только с загрузкой CPU базы.
• Очереди и фоновые задачи. Сервис может быстро принять запрос, но накапливать работу, которую завершит позже. Проверяйте длину очереди и возраст самой старой задачи.
• Память и сборка мусора. Рост потребления памяти или частые паузы могут вызывать скачки задержки и перезапуски. Сравнивайте потребление во времени, а не только снимок в конце.
• Сам генератор нагрузки. Если он упёрся в CPU, сеть или число открытых соединений, сервер получит меньше запросов, чем вы думаете. Измеряйте ресурсы генератора отдельно.

Нагрузка доказывает не то, что система выдерживает абстрактное число запросов, а то, что конкретный сценарий проходит на конкретной конфигурации при конкретных ограничениях.

Где сравнение теряет смысл

Тест недостоверен, если генератор и сервер делят ограниченный ресурс, тестовые данные не похожи на рабочие, а фоновые задачи выключены только для одного варианта. То же касается кеша: если один прогон получает повторяющиеся ключи, а другой — случайные, сравнение измеряет разные режимы попадания в кеш.

Смотрите на перцентили задержки, а не только на среднее. Среднее может скрыть небольшую группу очень медленных запросов, которые для пользователей выглядят как зависание. Укажите, какой именно перцентиль вы используете, и сравнивайте его при одинаковом сценарии. Термин «хвост задержки» здесь означает самые медленные запросы в распределении, а не среднее время ответа.

Не называйте короткий прогон доказательством длительной стабильности. Он может не выявить утечку памяти, накопление очереди или исчерпание дискового пространства. Длительность и объём теста должны соответствовать риску, который вы проверяете; универсального времени для всех систем нет.

Что делать дальше

Сохраните вместе с отчётом сценарий, конфигурацию, версии компонентов, состояние данных и графики ресурсов. Затем выберите одно узкое место и повторите тест, изменив только один фактор. Для HTTP-генератора нагрузки сверяйте определения метрик и ограничения сценария с документацией конкретной версии: одинаковое название показателя у разных инструментов не гарантирует одинаковый расчёт.

Следующий полезный шаг после сравнения — проверка на стенде, максимально близком к рабочему, с тем же профилем данных и фоновой работой. В проде наблюдайте за теми же показателями, что использовали в тесте: иначе выявленное ограничение будет сложно сопоставить с реальным поведением.