Как отслеживать бенчмарки в CI с помощью Bencher
Большинство результатов бенчмарков являются эфемерными. Они исчезают, как только терминал достигает своего предела прокрутки. Некоторые средства бенчмаркинга позволяют кэшировать результаты, но большинство делает это только локально. Bencher позволяет отслеживать ваши бенчмарки как из локальных, так и из CI запусков и сравнивать результаты, при этом все еще используя ваше любимое средство бенчмаркинга.
Существует два популярных способа сравнения результатов бенчмарков при Непрерывном бенчмаркинге, то есть бенчмаркинге в CI:
- Статистический непрерывный бенчмаркинг
- Отслеживание результатов бенчмарков во времени для создания базовой линии
- Использование этой базовой линии вместе со Статистическими порогами для создания статистической границы
- Сравнение новых результатов с этой статистической границей для выявления регрессии производительности
- Относительный непрерывный бенчмаркинг
- Запуск бенчмарков для текущего базового кода
- Использование Порогов в процентах для создания границы для базового кода
- Переход к новой версии кода
- Запуск бенчмарков для новой версии кода
- Сравнение результатов новой версии кода с результатами базового кода для выявления регрессии производительности
Статистическое Непрерывное Бенчмаркирование
Продолжая с того места, где мы остановились в
уроках Быстрый старт и Docker для саморазмещения,
давайте добавим Статистическое Непрерывное Бенчмаркирование в наш проект Спасаем Уолтера Уайта
.
🐰 Убедитесь, что вы создали токен API и установили его в качестве переменной окружения
BENCHER_API_TOKEN
перед тем, как продолжить!
Сначала нам нужно создать новый Тестовый стенд для представления наших CI-агентов, который будет назван ci-runner
.
bencher testbed create \--name ci-runner \save-walter-white-1234abcd
- Используйте подкоманду CLI
bencher testbed create
. Смотрите документацию поtestbed create
для получения дополнительных сведений. (например:bencher testbed create
) - Установите опцию
--name
с желаемым именем тестового стенда. (например:--name ci-runner
) - Укажите аргумент проекта как slug проекта
Спасаем Уолтера Уайта
. (например:save-walter-white-1234abcd
)
Далее нам нужно создать новый Порог для нашего тестового стенда ci-runner
:
bencher threshold create \--branch main \--testbed ci-runner \--measure Latency \--test t-test \--upper-boundary 0.95 \save-walter-white-1234abcd
- Используйте подкоманду CLI
bencher threshold create
. Смотрите документацию поthreshold create
для получения дополнительных сведений. (например:bencher threshold create
) - Установите опцию
--branch
значением Branch по умолчаниюmain
. (например:--branch main
) - Установите опцию
--testbed
значением нового тестового стендаci-runner
. (например:--testbed ci-runner
) - Установите опцию
--measure
значением встроенной МерыLatency
, которая генерируетсяbencher mock
. Смотрите определение Меры для получения дополнительных сведений. (например:--measure Latency
) - Установите опцию
--test
значением Порогаt-test
. Смотрите Пороги и оповещения для полного обзора. (например:--test t-test
) - Установите опцию
--upper-boundary
значением Верхней Границы0.95
. Смотрите Пороги и оповещения для полного обзора. (например:--upper-boundary 0.95
) - Укажите аргумент проекта как slug проекта
Спасаем Уолтера Уайта
. (например:save-walter-white-1234abcd
)
Теперь мы готовы запускать наши бенчмарки в CI. Поскольку каждое окружение CI немного отличается, следующий пример больше иллюстративен, чем практичен. Для более конкретных примеров см. Непрерывное Бенчмаркирование в GitHub Actions и Непрерывное Бенчмаркирование в GitLab CI/CD.
Нам нужно создать и поддерживать историческую базу для нашего ветки main
, бенчмаркируя каждое изменение в CI:
bencher run \--project save-walter-white-1234abcd \--branch main \--testbed ci-runner \--adapter json \--err \bencher mock
- Используйте подкоманду CLI
bencher run
для запуска бенчмарков вашей веткиfeature-branch
. Смотрите подкоманду CLIbencher run
для полного обзора. (например:bencher run
) - Установите опцию
--project
значением slug проекта. Смотрите документацию по--project
для получения дополнительных сведений. (например:--project save-walter-white-1234abcd
) - Установите опцию
--branch
значением имя ветки по умолчанию. Смотрите выбор ветки для полного обзора. (например:--branch main
) - Установите опцию
--testbed
значением имя тестового стенда. Смотрите документацию по--tested
для получения дополнительных сведений. (например:--testbed ci-runner
) - Установите опцию
--adapter
значением желаемого адаптера испытательного стенда. Смотрите адаптеры бенчмаркинга для полного обзора. (например:--adapter json
) - Установите флаг
--err
, чтобы команда завершилась с ошибкой в случае генерации Оповещения. Смотрите Пороги и Оповещения для полного обзора. (например:--err
) - Укажите аргументы команды бенчмаркинга.
Смотрите команду бенчмаркинга для полного обзора.
(например:
bencher mock
)
Наконец, мы готовы отлавливать регрессии производительности в CI.
Таким образом мы будем отслеживать производительность новой ветки с функцией, названной feature-branch
, в CI:
bencher run \--project save-walter-white-1234abcd \--branch feature-branch \--branch-start-point main \--branch-start-point-hash 32aea434d751648726097ed3ac760b57107edd8b \--branch-reset \--testbed ci-runner \--adapter json \--err \bencher mock
- Используйте подкоманду CLI
bencher run
для запуска бенчмарков вашей веткиfeature-branch
. Смотрите подкоманду CLIbencher run
для полного обзора. (например:bencher run
) - Установите опцию
--project
значением slug проекта. Смотрите документацию по--project
для получения дополнительных сведений. (например:--project save-walter-white-1234abcd
) - Установите опцию
--branch
значением имя ветки с функцией. Смотрите выбор ветки для полного обзора. (например:--branch feature-branch
) - Установите опцию
--branch-start-point
значением начальной точки ветки с функцией. Смотрите выбор ветки для полного обзора. (например:--branch-start-point main
) - Установите опцию
--branch-start-point-hash
значениемgit
хеш начальной точки ветки с функцией. Смотрите выбор ветки для полного обзора. (например:--branch-start-point-hash 32ae...dd8b
) - Установите флаг
--branch-reset
, чтобы всегда сбрасывать ветку к начальной точке. Это предотвратит дрейф данных бенчмарков. Смотрите выбор ветки для полного обзора. (например:--branch-reset
) - Установите опцию
--testbed
значением имя тестового стенда. Смотрите документацию по--tested
для получения дополнительных сведений. (например:--testbed ci-runner
) - Установите опцию
--adapter
значением желаемого адаптера испытательного стенда. Смотрите адаптеры бенчмаркинга для полного обзора. (например:--adapter json
) - Установите флаг
--err
, чтобы команда завершилась с ошибкой в случае генерации Оповещения. Смотрите Пороги и Оповещения для полного обзора. (например:--err
) - Укажите аргументы команды бенчмаркинга.
Смотрите команду бенчмаркинга для полного обзора.
(например:
bencher mock
)
В первый раз, когда эта команда будет выполнена в CI,
она создаст ветку feature-branch
, так как она еще не существует.
Новая ветка feature-branch
будет использовать ветку main
на хеш-теге 32aea434d751648726097ed3ac760b57107edd8b
в качестве начальной точки.
Это означает, что ветка feature-branch
будет иметь копию всех данных и Порогов
из ветки main
для сравнения результатов bencher mock
для первого и всех последующих запусков.
Относительное непрерывное тестирование производительности
Продолжаем там, где остановились в учебниках
Быстрый старт и Docker Self-Hosted. Давайте добавим относительное непрерывное тестирование производительности в наш проект Save Walter White
.
🐰 Убедитесь, что вы создали токен API и установили его в переменной окружения
BENCHER_API_TOKEN
, перед тем как продолжить!
Сначала нам нужно создать новую среду тестирования для представления наших CI-раннеров, которую мы назовем ci-runner
.
bencher testbed create \--name ci-runner \save-walter-white-1234abcd
- Используйте подкоманду CLI
bencher testbed create
. Смотрите документациюtestbed create
для получения более подробной информации. (например:bencher testbed create
) - Установите опцию
--name
в желаемое имя среды тестирования. (например:--name ci-runner
) - Укажите аргумент проекта как слаг проекта
Save Walter White
. (например:save-walter-white-1234abcd
)
Относительное непрерывное тестирование производительности проводит сравнение двух версий вашего кода.
Это может быть полезно при работе с шумными средами CI/CD,
где доступные ресурсы могут сильно варьироваться между запусками.
В этом примере мы будем сравнивать результаты, полученные из ветки main
,
с результатами из ветки с новыми функциями, названной feature-branch
.
Поскольку каждая среда CI немного отличается,
следующий пример предназначен скорее для иллюстрации, чем для практического использования.
Для более конкретных примеров смотрите Непрерывное тестирование производительности в GitHub Actions
и Непрерывное тестирование производительности в GitLab CI/CD.
Сначала нам нужно переключиться на ветку main
с помощью git
в CI:
git checkout main
Затем нам нужно запустить наши тесты производительности на ветке main
в CI:
bencher run \--project save-walter-white-1234abcd \--branch feature-branch \--branch-reset \--testbed ci-runner \--adapter json \bencher mock
- Используйте подкоманду CLI
bencher run
для запуска ваших тестов производительности на веткеmain
. Смотрите обзор подкоманды CLIbencher run
для получения полного описания. (например:bencher run
) - Установите опцию
--project
в слаг проекта. Смотрите документацию--project
для получения более подробной информации. (например:--project save-walter-white-1234abcd
) - Установите опцию
--branch
в имя ветки с новыми функциями. Смотрите выбор ветки для получения полного описания. (например:--branch feature-branch
) - Установите флаг
--branch-reset
. Смотрите выбор ветки для получения полного описания. (например:--branch-reset
) - Установите опцию
--testbed
в имя среды тестирования. Смотрите документацию--tested
для получения более подробной информации. (например:--testbed ci-runner
) - Установите опцию
--adapter
в желаемый адаптер для фреймворка тестирования производительности. Смотрите адаптеры фреймворков тестирования производительности для получения полного описания. (например:--adapter json
) - Укажите аргументы команды тестирования производительности.
Смотрите аргумент команды для получения полного описания.
(например:
bencher mock
)
Первый раз, когда эта команда будет запущена в CI,
она создаст ветку feature-branch
, поскольку она еще не существует.
Новая ветка feature-branch
не будет иметь точки старта, существующих данных или порогов.
При последующих запусках старая версия feature-branch
будет переименована,
и новая feature-branch
будет создана без точки старта, существующих данных или порогов.
Затем, нам нужно создать новый Порог в CI для нашей новой ветки feature-branch
:
bencher threshold create \--branch feature-branch \--testbed ci-runner \--measure Latency \--test percentage \--upper-boundary 0.25 \save-walter-white-1234abcd
- Используйте подкоманду CLI
bencher threshold create
. Смотрите документациюthreshold create
для получения более подробной информации. (например:bencher threshold create
) - Установите опцию
--branch
в новую веткуfeature-branch
. (например:--branch feature-branch
) - Установите опцию
--branch
в среду тестированияci-runner
. (например:--testbed ci-runner
) - Установите опцию
--measure
во встроенную метрикуLatency
, которая генерируется командойbencher mock
. Смотрите определение Measure для получения более подробной информации. (например:--measure Latency
) - Установите опцию
--test
в порогpercentage
. Смотрите Пороги и уведомления для получения полного описания. (например:--test t-test
) - Установите опцию
--upper-boundary
в верхнюю границу0.25
(т.е.25%
). Смотрите Пороги и уведомления для получения полного описания. (например:--upper-boundary 0.25
) - Укажите аргумент проекта как слаг проекта
Save Walter White
. (например:save-walter-white-1234abcd
)
Затем, нам нужно переключиться на ветку feature-branch
с помощью git
в CI:
git checkout feature-branch
Наконец, мы готовы запустить наши тесты производительности на ветке feature-branch
в CI:
bencher run \--project save-walter-white-1234abcd \--branch feature-branch \--testbed ci-runner \--adapter json \--err \bencher mock
- Используйте подкоманду CLI
bencher run
для запуска ваших тестов производительности на веткеfeature-branch
. Смотрите обзор подкоманды CLIbencher run
для получения полного описания. (например:bencher run
) - Установите опцию
--project
в слаг проекта. Смотрите документацию--project
для получения более подробной информации. (например:--project save-walter-white-1234abcd
) - Установите опцию
--branch
в имя ветки с новыми функциями. Смотрите выбор ветки для получения полного описания. (например:--branch feature-branch
) - Установите опцию
--testbed
в имя среды тестирования. Смотрите документацию--tested
для получения более подробной информации. (например:--testbed ci-runner
) - Установите опцию
--adapter
в желаемый адаптер для фреймворка тестирования производительности. Смотрите адаптеры фреймворков тестирования производительности для получения полного описания. (например:--adapter json
) - Установите флаг
--err
для прекращения выполнения команды, если сгенерировано уведомление. Смотрите Пороги и уведомления для получения полного описания. (например:--err
) - Укажите аргументы команды тестирования производительности.
Смотрите аргумент команды для получения полного описания.
(например:
bencher mock
)
Каждый раз, когда эта команда запускается в CI,
она сравнивает результаты из feature-branch
только с самыми последними результатами из main
.
🐰 Поздравляем! Вы научились отслеживать бенчмарки в CI с помощью Bencher! 🎉