Как провести воспроизводимый бенчмарк приложения: окружение, нагрузка и повторные прогоны

Сначала формулируют вопрос, а потом запускают benchmark

Фраза «проверим, какая версия быстрее» слишком широкая. Непонятно, что именно считается работой системы и при каких условиях две версии должны сравниваться.

Инженерный вопрос лучше сформулировать конкретнее:

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

Например, сравнение двух реализаций обработки одного и того же набора данных — это понятная задача. Сравнение «приложения до оптимизации» и «приложения после оптимизации» без описания workload уже оставляет слишком много неизвестных.

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

Workload должен быть одинаковым по смыслу

Benchmark измеряет не приложение «вообще». Он измеряет выполнение конкретной работы в заданных условиях. Эту работу обычно описывают как workload.

В него могут входить:

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

Если первая версия обрабатывает один набор входных данных, а вторая — другой, результат уже содержит минимум две переменные: изменение приложения и изменение workload.

То же относится к конкурентности. Результат последовательного запуска нельзя напрямую сопоставлять с результатом проверки под параллельной нагрузкой только потому, что измерялась одна и та же функция.

Сравнимость начинается с одинакового вопроса к системе. Если вопрос меняется между прогонами, числовой результат может оставаться корректным для каждого отдельного теста, но сравнение между ними становится слабее.

Окружение тоже является частью бенчмарка

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

Поэтому для сравнительного теста полезно фиксировать:

В документации OpenSearch Benchmark сравнение результатов из разных окружений прямо названо одной из распространённых ошибок performance testing. Там же рекомендуется сохранять характеристики оборудования, версии программного обеспечения и значимые настройки среды.

Это не означает, что benchmark можно запускать только на выделенном сервере. Локальная машина тоже подходит для многих инженерных вопросов. Но результаты нужно интерпретировать в границах того окружения, где они получены.

Warm-up нужен не каждому тесту одинаково

Первые итерации программы могут отличаться от последующих. На результат влияют кэши, JIT-компиляция, инициализация runtime и другие процессы, которые происходят после запуска.

Поэтому benchmark frameworks часто выделяют отдельную фазу warm-up — выполнение workload до начала основного измерения.

Google Benchmark позволяет задать минимальное время прогрева перед тем, как результаты начинают учитываться. BenchmarkDotNet также разделяет warm-up и фактические измерительные итерации.

Но из этого не следует правило «всегда прогревать систему N секунд».

Если инженерный вопрос относится к установившемуся режиму, прогрев помогает не смешивать его с начальными эффектами. Если же исследуется именно cold start, предварительный warm-up уничтожит то состояние, которое требуется измерить. BenchmarkDotNet поэтому отдельно предусматривает стратегию ColdStart.

Получается два разных вопроса:

Warm-up выбирают по смыслу теста, а не потому, что это обязательная строка в шаблоне.

Один прогон почти ничего не говорит о разбросе

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

Поэтому зрелые benchmark frameworks работают не с одним измерением.

Google Benchmark умеет выполнять несколько repetitions и рассчитывать статистические результаты по повторным запускам. BenchmarkDotNet использует несколько стадий выполнения, выполняет измерительные итерации и анализирует свойства полученного распределения.

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

От разработчика требуется другое:

• не делать вывод по одному удачному запуску;
• сохранять результаты повторов;
• смотреть не только на одно итоговое число, но и на разброс;
• не скрывать нестабильность, если она повторяется.

Подготовка теста не должна случайно попадать в измеряемый участок

Есть ещё один источник искажений: benchmark может измерять не только нужную операцию, но и подготовительную работу вокруг неё.

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

подготовка данных + проверяемая операция.

Иногда именно это и требуется. Но если вопрос касается только самой операции, подготовку нужно вынести в соответствующий setup-этап.

Google Benchmark предоставляет отдельные механизмы Setup/Teardown, а BenchmarkDotNet различает setup и измерительные стадии. Это позволяет явно определить границу того, что входит в тестируемый workload.

Перед запуском полезно буквально записать:

«Какой участок работы должен попасть в измерение, а какой нужен только для подготовки условий?»

Фоновые процессы создают шум, но не всякий шум можно убрать

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

Это не означает, что любое локальное измерение бесполезно. Но важно различать две ситуации.

Первая: среда контролируется достаточно хорошо, и две версии проверяются практически в одинаковых условиях.

Вторая: между тестами изменилась сама среда, а её влияние невозможно отделить от изменения приложения.

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

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

Менять между сравниваемыми прогонами лучше как можно меньше

Предположим, между версией A и версией B одновременно поменялись алгоритм, runtime, конфигурация базы и число потоков. Даже если новый результат отличается заметно, определить вклад каждого изменения уже трудно.

Для benchmark это означает простое инженерное правило: между сравниваемыми состояниями следует сохранять как можно больше одинаковых условий.

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

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

Что сохранить вместе с результатом

Таблица с итоговыми значениями полезна только пока рядом существует контекст запуска. Через несколько месяцев строка «версия B быстрее версии A» может оказаться практически непроверяемой.

Минимальный отчёт о benchmark удобно собирать так:

Если framework формирует машиночитаемый отчёт, его стоит сохранять вместе с версией кода и параметрами запуска. Google Benchmark поддерживает структурированный вывод, а BenchmarkDotNet формирует отчёты после измерительных стадий.

Как выглядит минимальная процедура воспроизводимого benchmark

Если убрать детали конкретного языка и framework, процесс можно свести к нескольким шагам.

1. Определить вопрос. Что именно сравнивается между версиями.
2. Зафиксировать состояния. Версии кода, конфигурацию и существенные параметры среды.
3. Описать workload. Одинаковые входные данные, объём работы и конкурентность.
4. Определить режим запуска. Нужен steady state или cold start.
5. Отделить подготовку. В измерение должна попадать именно исследуемая операция.
6. Выполнить повторные измерения. Не строить вывод на одном запуске.
7. Сохранить контекст. Результаты без параметров среды быстро теряют проверяемость.
8. Сравнить только сопоставимые состояния. Если условия существенно различались, это нужно указать отдельно.

Такой benchmark не обещает идеально одинаковых чисел. Он даёт другое: возможность повторить процедуру, увидеть диапазон результатов и понять, какие условия действительно сохранялись между сравниваемыми версиями.

Что важно не перепутать

Baseline описывает состояние системы до изменения. Workload определяет работу, которую получает система. Warm-up отделяет начальную фазу от измерения установившегося режима, если этого требует задача. Repetitions позволяют увидеть вариативность повторных запусков. Окружение задаёт условия, в которых получены результаты.

Ни один из этих элементов по отдельности не делает benchmark воспроизводимым. Воспроизводимость появляется, когда они связаны в одну описанную процедуру и сравниваемые состояния отличаются именно тем, что мы намеревались проверить.

Источники

Технические источники проверены 19 августа 2026 года. Использована официальная документация benchmark frameworks и OpenSearch.

• Google Benchmark — User Guide
• BenchmarkDotNet — официальная документация
• BenchmarkDotNet — How it works
• BenchmarkDotNet — Jobs and run configuration
• OpenSearch Benchmark — Performance testing best practices