Можно ли использовать Benchmark.NET для «сбоя» сборки CI, если производительность слишком сильно снизилась?

Question

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

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

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

Я рассмотрел жесткие пороги кодирования, которые не должны превышаться.Что-то вроде:

Assert.IsTrue(hotPathTestResult.TotalTime <= threshold)

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

Кто-нибудь реализовал что-то подобное?Что Microsoft делает для Kestrel?

Answer 1

Я бы не делал это через юнит-тесты - это не то место.Сделайте это в build / test-script.Вы получаете больше гибкости и можете делать больше вещей, которые могут понадобиться.

Грубый набросок будет выглядеть так:

1. build
2. запуск юнит-тестов
3. запуск интеграционных тестов
4. запуск тестов производительности
5. загрузка результатов тестирования в хранилище результатов (коммерческий продукт, например, "PowerBI")
6. проверка текущих результатов с предыдущими результатами
7. загрузка артефактов / развертывание пакетов

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

Суть в том, как определить, произошла ли регрессия.Особенно в сборках CI (с контейнерами и тому подобным) может быть разное оборудование на разных тестах, поэтому результаты не сопоставимы 1: 1, и вы должны это учитывать.
Лично я непусть сценарий завершится ошибкой в ​​случае возможной регрессии, но он отправляет информацию об этом, поэтому я могу вручную проверить, является ли это истинной регрессией или просто причиной, вызванной другим оборудованием.

Регрессия просто обнаруживается, если текущаярезультаты хуже, чем медиана последних 5 результатов.Конечно, это грубый, но эффективный метод, и вы можете настроить его под свои нужды.