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

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

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

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

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

Продолжая наш разговор после Быстрого Старта и учебников Docker Self-Hosted, давайте добавим Статистическое Непрерывное Бенчмаркинг в наш проект Save Walter White.

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

Сначала нам нужно создать новое Тестовое Окружение для представления наших CI runners, подходящее название 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-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 в ветку по умолчанию main. (например: --branch main)
3. Установите опцию --branch в новое Тестовое Окружение ci-runner. (например: --testbed ci-runner)
4. Установите опцию --measure в встроенную меру Latency, которая генерируется bencher mock. Смотрите определение Measure для деталей. (например: --measure Latency)
5. Установите опцию --test в t-test Порог. Смотрите Пороги & Оповещения для полного обзора. (например: --test t-test)
6. Установите опцию --upper-boundary в Верхнюю Границу 0.95. Смотрите Пороги & Оповещения для полного обзора. (например: --upper-boundary 0.95)
7. Укажите аргумент проекта как слаг проекта Save Walter White. (например: 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 в слаг проекта. Смотрите документацию --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 \
--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. Установите опцию --branch-start-point в точку начала ветки функционала. Смотрите выбор ветки для полного обзора. (например: --branch-start-point main)
5. Установите опцию --branch-start-point-hash в git хеш точки начала ветки функционала. Смотрите выбор ветки для полного обзора. (например: --branch-start-point-hash 32ae...dd8b)
6. Установите опцию --testbed в имя Тестового Окружения. Смотрите документацию --tested для получения дополнительной информации. (например: --testbed ci-runner)
7. Установите опцию --adapter в желаемый адаптер оболочки бенчмарка. Смотрите адаптеры оболочек бенчмарка для полного обзора. (например: --adapter json)
8. Установите флаг --err для завершения команды с ошибкой, если сгенерировано Оповещение. Смотрите Пороги & Оповещения для полного обзора. (например: --err)
9. Укажите аргументы команды бенчмарка. Смотрите команду бенчмарка для полного обзора. (например: 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 ➡