Как отслеживать бенчмарки в CI с помощью Bencher

Большинство результатов бенчмарков являются эфемерными. Они исчезают, как только терминал достигает своего предела прокрутки. Некоторые средства бенчмаркинга позволяют кэшировать результаты, но большинство делает это только локально. Bencher позволяет отслеживать ваши бенчмарки как из локальных, так и из CI запусков и сравнивать результаты, при этом все еще используя ваше любимое средство бенчмаркинга.

Существует два популярных способа сравнения результатов бенчмарков при Непрерывном бенчмаркинге, то есть бенчмаркинге в CI:

• Статистический непрерывный бенчмаркинг
  1. Отслеживание результатов бенчмарков во времени для создания базовой линии
  2. Использование этой базовой линии вместе со Статистическими порогами для создания статистической границы
  3. Сравнение новых результатов с этой статистической границей для выявления регрессии производительности
• Относительный непрерывный бенчмаркинг
  1. Запуск бенчмарков для текущего базового кода
  2. Использование Порогов в процентах для создания границы для базового кода
  3. Переход к новой версии кода
  4. Запуск бенчмарков для новой версии кода
  5. Сравнение результатов новой версии кода с результатами базового кода для выявления регрессии производительности

Статистическое Непрерывное Бенчмаркирование

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

🐰 Убедитесь, что вы создали токен API и установили его в качестве переменной окружения BENCHER_API_TOKEN перед тем, как продолжить!

Сначала нам нужно создать новый Тестовый стенд для представления наших CI-агентов, который будет назван ci-runner.

bencher testbed create \
--name ci-runner \
save-walter-white-1234abcd

1. Используйте подкоманду CLI bencher testbed create. Смотрите документацию по testbed create для получения дополнительных сведений. (например: bencher testbed create)
2. Установите опцию --name с желаемым именем тестового стенда. (например: --name ci-runner)
3. Укажите аргумент проекта как 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

1. Используйте подкоманду CLI bencher threshold create. Смотрите документацию по threshold create для получения дополнительных сведений. (например: bencher threshold create)
2. Установите опцию --branch значением Branch по умолчанию main. (например: --branch main)
3. Установите опцию --testbed значением нового тестового стенда ci-runner. (например: --testbed ci-runner)
4. Установите опцию --measure значением встроенной Меры Latency, которая генерируется bencher mock. Смотрите определение Меры для получения дополнительных сведений. (например: --measure Latency)
5. Установите опцию --test значением Порога t-test. Смотрите Пороги и оповещения для полного обзора. (например: --test t-test)
6. Установите опцию --upper-boundary значением Верхней Границы 0.95. Смотрите Пороги и оповещения для полного обзора. (например: --upper-boundary 0.95)
7. Укажите аргумент проекта как 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

1. Используйте подкоманду CLI bencher run для запуска бенчмарков вашей ветки feature-branch. Смотрите подкоманду CLI bencher run для полного обзора. (например: bencher run)
2. Установите опцию --project значением slug проекта. Смотрите документацию по --project для получения дополнительных сведений. (например: --project save-walter-white-1234abcd)
3. Установите опцию --branch значением имя ветки по умолчанию. Смотрите выбор ветки для полного обзора. (например: --branch main)
4. Установите опцию --testbed значением имя тестового стенда. Смотрите документацию по --tested для получения дополнительных сведений. (например: --testbed ci-runner)
5. Установите опцию --adapter значением желаемого адаптера испытательного стенда. Смотрите адаптеры бенчмаркинга для полного обзора. (например: --adapter json)
6. Установите флаг --err, чтобы команда завершилась с ошибкой в случае генерации Оповещения. Смотрите Пороги и Оповещения для полного обзора. (например: --err)
7. Укажите аргументы команды бенчмаркинга. Смотрите команду бенчмаркинга для полного обзора. (например: 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

1. Используйте подкоманду CLI bencher run для запуска бенчмарков вашей ветки feature-branch. Смотрите подкоманду CLI bencher run для полного обзора. (например: bencher run)
2. Установите опцию --project значением slug проекта. Смотрите документацию по --project для получения дополнительных сведений. (например: --project save-walter-white-1234abcd)
3. Установите опцию --branch значением имя ветки с функцией. Смотрите выбор ветки для полного обзора. (например: --branch feature-branch)
4. Установите опцию --branch-start-point значением начальной точки ветки с функцией. Смотрите выбор ветки для полного обзора. (например: --branch-start-point main)
5. Установите опцию --branch-start-point-hash значением git хеш начальной точки ветки с функцией. Смотрите выбор ветки для полного обзора. (например: --branch-start-point-hash 32ae...dd8b)
6. Установите флаг --branch-reset, чтобы всегда сбрасывать ветку к начальной точке. Это предотвратит дрейф данных бенчмарков. Смотрите выбор ветки для полного обзора. (например: --branch-reset)
7. Установите опцию --testbed значением имя тестового стенда. Смотрите документацию по --tested для получения дополнительных сведений. (например: --testbed ci-runner)
8. Установите опцию --adapter значением желаемого адаптера испытательного стенда. Смотрите адаптеры бенчмаркинга для полного обзора. (например: --adapter json)
9. Установите флаг --err, чтобы команда завершилась с ошибкой в случае генерации Оповещения. Смотрите Пороги и Оповещения для полного обзора. (например: --err)
10. Укажите аргументы команды бенчмаркинга. Смотрите команду бенчмаркинга для полного обзора. (например: 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

1. Используйте подкоманду CLI bencher testbed create. Смотрите документацию testbed create для получения более подробной информации. (например: bencher testbed create)
2. Установите опцию --name в желаемое имя среды тестирования. (например: --name ci-runner)
3. Укажите аргумент проекта как слаг проекта 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

1. Используйте подкоманду CLI bencher run для запуска ваших тестов производительности на ветке main. Смотрите обзор подкоманды CLI bencher run для получения полного описания. (например: bencher run)
2. Установите опцию --project в слаг проекта. Смотрите документацию --project для получения более подробной информации. (например: --project save-walter-white-1234abcd)
3. Установите опцию --branch в имя ветки с новыми функциями. Смотрите выбор ветки для получения полного описания. (например: --branch feature-branch)
4. Установите флаг --branch-reset. Смотрите выбор ветки для получения полного описания. (например: --branch-reset)
5. Установите опцию --testbed в имя среды тестирования. Смотрите документацию --tested для получения более подробной информации. (например: --testbed ci-runner)
6. Установите опцию --adapter в желаемый адаптер для фреймворка тестирования производительности. Смотрите адаптеры фреймворков тестирования производительности для получения полного описания. (например: --adapter json)
7. Укажите аргументы команды тестирования производительности. Смотрите аргумент команды для получения полного описания. (например: 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

1. Используйте подкоманду CLI bencher threshold create. Смотрите документацию threshold create для получения более подробной информации. (например: bencher threshold create)
2. Установите опцию --branch в новую ветку feature-branch. (например: --branch feature-branch)
3. Установите опцию --branch в среду тестирования ci-runner. (например: --testbed ci-runner)
4. Установите опцию --measure во встроенную метрику Latency, которая генерируется командой bencher mock. Смотрите определение Measure для получения более подробной информации. (например: --measure Latency)
5. Установите опцию --test в порог percentage. Смотрите Пороги и уведомления для получения полного описания. (например: --test t-test)
6. Установите опцию --upper-boundary в верхнюю границу 0.25 (т.е. 25%). Смотрите Пороги и уведомления для получения полного описания. (например: --upper-boundary 0.25)
7. Укажите аргумент проекта как слаг проекта 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

1. Используйте подкоманду CLI bencher run для запуска ваших тестов производительности на ветке feature-branch. Смотрите обзор подкоманды CLI bencher run для получения полного описания. (например: bencher run)
2. Установите опцию --project в слаг проекта. Смотрите документацию --project для получения более подробной информации. (например: --project save-walter-white-1234abcd)
3. Установите опцию --branch в имя ветки с новыми функциями. Смотрите выбор ветки для получения полного описания. (например: --branch feature-branch)
4. Установите опцию --testbed в имя среды тестирования. Смотрите документацию --tested для получения более подробной информации. (например: --testbed ci-runner)
5. Установите опцию --adapter в желаемый адаптер для фреймворка тестирования производительности. Смотрите адаптеры фреймворков тестирования производительности для получения полного описания. (например: --adapter json)
6. Установите флаг --err для прекращения выполнения команды, если сгенерировано уведомление. Смотрите Пороги и уведомления для получения полного описания. (например: --err)
7. Укажите аргументы команды тестирования производительности. Смотрите аргумент команды для получения полного описания. (например: bencher mock)

Каждый раз, когда эта команда запускается в CI, она сравнивает результаты из feature-branch только с самыми последними результатами из main.

🐰 Поздравляем! Вы научились отслеживать бенчмарки в CI с помощью Bencher! 🎉

Добавить Bencher в GitHub Actions ➡

Добавить Bencher в GitLab CI/CD ➡