performance-testing - 如果性能下降太多，是否可以使用Benchmark.NET对CI构建进行 "fail"？

Question

我有单元测试。如果其中之一失败，我的构建就会失败。

我想将相同的原理应用于性能。我有一系列针对整个库的热门路径的微基准测试。根据经验，这些方面的放慢对图书馆的整体绩效影响不成比例。

如果有某种方式可以使“性能构建”的某些概念在性能退化过大的情况下失败，那就太好了。

我考虑过不得超过的硬编码阈值。就像是:
Assert.IsTrue(hotPathTestResult.TotalTime <= threshold)
但是将其固定为绝对值取决于硬件和环境，因此很脆弱。

有没有人实现过这样的事情？微软为Kestrel做些什么？

Answer 1

我不会通过单元测试来做到这一点-这是错误的地方。
在构建/测试脚本中执行此操作。您将获得更大的灵活性，并且可以做很多可能需要做的事情。

粗略的轮廓是:

构建

运行单元测试

运行集成测试

运行基准测试

将基准测试结果上传到结果存储区(商业产品，例如“PowerBI”)

用以前的结果检查当前结果

上传工件/部署软件包

在6.上，如果存在回归，则可以使用非零退出代码让构建失败。
BenchmarkDotNet可以将结果导出为JSON等，因此您可以利用它。

关键是如何确定是否发生回归。尤其是在CI构建(带有容器等)上，在不同的基准测试运行中可能会使用不同的硬件，因此结果不是1:1的可比性，您必须考虑到这一点。
就个人而言，在发生可能的回归的情况下，我不会让脚本失败，但是它会发送有关该信息的信息，因此我可以手动检查它是否是真正的回归，或者仅仅是由其他硬件导致的原因。

如果当前结果比最后5个结果的中位数差，则仅检测回归。当然，这是一种粗略的方法，但是有效的方法是，您可以根据需要进行调整。