在您的构建过程中添加微基准测试

介绍

作为一个行业，我们正在采用更高的透明度和更可预测的构建过程，以减少构建软件的风险。持续交付的核心原则之一是通过反馈循环收集反馈。在Dev9中，我们采用了与CD原则相一致的“ 先知道 ”原则，这意味着我们（开发团队）希望首先知道何时出现故障，性能下降或任何与之不符的结果。业务目标。

Maven和其他构建工具为开发人员提供了标准化的工具和生态系统，可在其中建立和交流反馈。尽管单元测试，功能，构建验收，数据库迁移，性能测试和代码分析工具已成为开发流程中的主要内容，但基准测试基本上仍然不在流程之外。这可能是由于缺乏开源的，低成本的工具或轻量级的库，这些库增加了最小的复杂性。

现有工具通常需要将外部工具与运行时工件集成在一起，从而使复杂性更加复杂，并且测试未保存在同一源存储库中，甚至没有存储在源存储库中。本地开发人员无法毫不费力地运行基准测试，因此测试会很快失去其价值。除了主流的解决方案问题外，基准测试通常不是在课堂上讲授的，并且通常在没有必要的隔离才能获得可靠结果的情况下实施。这使得所有有关基准测试结果的博客或帖子成为巨魔的成熟目标。

综上所述，围绕代码库的关键区域进行某种基准覆盖仍然很重要。建立有关代码关键部分的历史知识可以帮助影响优化工作，向团队通报技术欠债，在性能阈值更改已提交时发出警报并比较算法的先前版本或新版本。现在的问题是，如何找到基准并轻松地将基准添加到我的新项目或现有项目中。在此博客中，我们将专注于Java项目（1.7+）。该示例代码将利用Maven，尽管Gradle的工作原理非常相似。我在整个博客中提出了一些建议，这些建议是基于过去项目的经验得出的。

JHM简介

在对基准Java代码进行基准测试时，有很多强大的选择，但是它们大多数都有缺点，包括许可证费用，额外的工具，字节代码操纵和/或Java代理，使用非基于Java的代码概述的测试以及高度复杂的配置设置。我喜欢使测试尽可能接近被测代码，以减少脆性，降低内聚力并减少耦合。我认为我以前使用过的大多数基准测试解决方案太麻烦了，或者运行测试的代码不够孤立（完全集成在代码中），或者包含在远离源代码的辅助解决方案中。

本博客的目的是演示如何在构建管道中添加轻量级基准测试工具，因此我将不详细介绍如何使用JMH，以下博客是学习的绝佳资源：

http://jmhwiki.blogspot.com
http://java-performance.info/jmh/
http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/

基准测试模式

关于模式和评分，我想指出一小部分，因为它们在基本配置的设置中起着重要作用。在基本级别上，JMH有两种主要的度量类型：吞吐量和基于时间的度量。

吞吐量测量

吞吐量是每单位时间可以完成的操作量。随着框架增加测试的负载量，JMH会维护成功和失败操作的集合。注意：确保方法或测试完全隔离，并且诸如测试对象创建之类的依赖项是在方法之外或在设置方法中进行预测试的。使用吞吐量时，该值越高，越好，因为它表明可以在单位时间内运行更多的操作。

基于时间的测量

基于时间的测量是吞吐量的反伙伴。基于时间的测量的目的是确定特定操作每单位时间运行多长时间。

平均时间

最常见的基于时间的度量是“ AverageTime”，用于计算操作的平均时间。 JMH还将产生“ 得分错误 ”，以帮助确定对产生得分的信心。 “ 得分误差 ”通常是置信区间的1/2，表示结果与平均时间的偏离程度。结果越低，越好，因为它表明每次操作的平均运行时间较短。

采样时间

SampleTime与AverageTime相似，但是JMH尝试增加更多的负载并查找会产生失败百分比矩阵的失败。使用AverageTime时，数字越小越好，这些百分比对于确定由于吞吐量和时间长度而导致失败的位置很有用。

SingleShotTime

最后也是最不常用的模式是SingleShotTime。此模式实际上是一次运行，可用于冷测方法或测试您的测试。如果在运行基准测试时作为参数传递SingleShotTime，可能会很有用，但会减少运行测试所需的时间（尽管这样做会减少测试的价值并可能使它们自重）。与其他基于时间的测量一样，该值越低越好。

将JMH添加到Java项目

目标：本部分将展示如何创建可重复使用的工具，该工具可在不增加代码开销或代码重复的情况下添加新测试。注意，这些依赖项在“测试”范围内，以避免将JMH添加到最终工件中。我创建了一个在使用Protobuf替代REST for Microservices时使用JMH的github存储库。可以在这里找到代码： https : //github.com/mike-ensor/protobuf-serialization

1）首先将依赖项添加到项目中：

<dependencies>
<!-- Other libraries left out for brevity -->
<!-- jmh.version is the lastest version of JMH. Find by visitinghttp://search.maven.org --><dependency><groupId>org.openjdk.jmh</groupId><artifactId>jmh-core</artifactId><version>${jmh.version}</version><scope>test</scope></dependency><dependency><groupId>org.openjdk.jmh</groupId><artifactId>jmh-generator-annprocess</artifactId><version>${jmh.version}</version><scope>test</scope></dependency>
<!-- Other libraries left out for brevity -->
</dependencies>

2）JMH建议将基准测试和工件包装在同一uber jar中。有几种方法可以实现uber jar，显式地使用made的“ shade”插件或隐式地使用Spring Boot，Dropwizard或具有类似结果的某些框架。出于本博客文章的目的，我使用了Spring Boot应用程序。

3）添加具有主条目类和全局配置的测试工具。在此步骤中，在项目的测试区域中创建一个入口点（用＃1表示）。目的是避免将基准代码与主要工件打包在一起。

3.1）添加BenchmarkBase文件（在＃2上方指示）。此文件将用作基准测试的入口，并包含测试的所有全局配置。我编写的类正在寻找一个包含配置属性的“ benchmark.properties”文件（上面在＃3中指出）。 JMH可以选择输出文件结果，并且此配置是为JSON设置的。结果与您的持续集成工具一起使用，可以（应该）存储以供历史使用。

此代码段是Maven运行的Benchmark流程的基本工具和入口点（在下面的步骤5中进行设置）。此时，项目应该能够运行基准测试，因此让我们添加一个测试用例。

@SpringBootApplication
public class BenchmarkBase {public static void main(String[] args) throws RunnerException, IOException {Properties properties = PropertiesLoaderUtils.loadAllProperties("benchmark.properties");int warmup = Integer.parseInt(properties.getProperty("benchmark.warmup.iterations", "5"));int iterations = Integer.parseInt(properties.getProperty("benchmark.test.iterations", "5"));int forks = Integer.parseInt(properties.getProperty("benchmark.test.forks", "1"));int threads = Integer.parseInt(properties.getProperty("benchmark.test.threads", "1"));String testClassRegExPattern = properties.getProperty("benchmark.global.testclassregexpattern", ".*Benchmark.*");String resultFilePrefix = properties.getProperty("benchmark.global.resultfileprefix", "jmh-");ResultFormatType resultsFileOutputType = ResultFormatType.JSON;Options opt = new OptionsBuilder().include(testClassRegExPattern).warmupIterations(warmup).measurementIterations(iterations).forks(forks).threads(threads).shouldDoGC(true).shouldFailOnError(true).resultFormat(resultsFileOutputType).result(buildResultsFileName(resultFilePrefix, resultsFileOutputType)).shouldFailOnError(true).jvmArgs("-server").build();new Runner(opt).run();}private static String buildResultsFileName(String resultFilePrefix, ResultFormatType resultType) {LocalDateTime date = LocalDateTime.now();DateTimeFormatter formatter = DateTimeFormatter.ofPattern("mm-dd-yyyy-hh-mm-ss");String suffix;switch (resultType) {case CSV:suffix = ".csv";break;case SCSV:// Semi-colon separated valuessuffix = ".scsv";break;case LATEX:suffix = ".tex";break;case JSON:default:suffix = ".json";break;}return String.format("target/%s%s%s", resultFilePrefix, date.format(formatter), suffix);}}

4）创建一个类来对操作进行基准测试。请记住，基准测试将针对整个方法主体进行，包括日志记录，文件读取，外部资源等。请注意要进行基准测试并减少或删除依赖项，以便隔离主题代码以确保对结果的信心更高。在此示例中，在

@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
public class SerializationBenchmark {private RecipeService service;private Recipe recipe;private byte[] protoRecipe;private String recipeAsJSON;@Setup(Level.Trial)public void setup() {IngredientUsed jalepenoUsed = new IngredientUsed(new Ingredient("Jalepeno", "Spicy Pepper"), MeasurementType.ITEM, 1);IngredientUsed cheeseUsed = new IngredientUsed(new Ingredient("Cheese", "Creamy Cheese"), MeasurementType.OUNCE, 4);recipe = RecipeTestUtil.createRecipe("My Recipe", "Some spicy recipe using a few items", ImmutableList.of(jalepenoUsed, cheeseUsed));service = new RecipeService(new ObjectMapper());protoRecipe = service.recipeAsProto(recipe).toByteArray();recipeAsJSON = service.recipeAsJSON(recipe);}@Benchmarkpublic Messages.Recipe serialize_recipe_object_to_protobuf() {return service.recipeAsProto(recipe);}@Benchmarkpublic String serialize_recipe_object_to_JSON() {return service.recipeAsJSON(recipe);}@Benchmarkpublic Recipe deserialize_protobuf_to_recipe_object() {return service.getRecipe(protoRecipe);}@Benchmarkpublic Recipe deserialize_json_to_recipe_object() {return service.getRecipe(recipeAsJSON);}}

标题：该要点是从Protobuf序列化中提取的示例基准测试用例

现在，当您执行测试jar时，所有* Benchmark * .java测试类都将运行，但这通常并不理想，因为该过程没有隔离，并且对基准测试的时间和方式进行一定的控制对于保持构建时间很重要下。

让我们构建一个Maven配置文件，以控制运行基准测试的时间以及可能启动应用程序的时间。注意，为了显示Maven集成测试启动/停止服务器的目的，我已将此内容包含在博客文章中。我会警告需要启动或停止应用程序服务器，因为这可能会带来资源获取（REST调用）的成本，而这并不是很孤立。

5）概念是创建一个Maven配置文件以独立运行所有基准测试（即，没有单元测试或功能测试）。这将使基准测试可以与其余构建管道并行运行。请注意，该代码使用“ exec”插件并运行uber jar，以查找指向主类的完整类路径路径。此外，可执行文件范围仅限于“测试”源，以避免将基准代码放入最终工件中。

<profile><id>benchmark</id><properties><maven.test.ITests>true</maven.test.ITests></properties><build><plugins><!-- Start application for benchmarks to test against --><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><executions><execution><id>pre-integration-test</id><goals><goal>start</goal></goals></execution><execution><id>post-integration-test</id><goals><goal>stop</goal></goals></execution></executions></plugin><!-- Turn off unit tests --><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-surefire-plugin</artifactId><configuration><excludes><exclude>**/*Tests.java</exclude><exclude>**/*Test.java</exclude></excludes></configuration></plugin><plugin><groupId>org.codehaus.mojo</groupId><artifactId>exec-maven-plugin</artifactId><version>1.5.0</version><executions><execution><goals><goal>exec</goal></goals><phase>integration-test</phase></execution></executions><configuration><executable>java</executable><classpathScope>test</classpathScope><arguments><argument>-classpath</argument><classpath /><argument>com.dev9.benchmark.BenchmarkBase</argument><argument>.*</argument></arguments></configuration></plugin></plugins></build>
</profile>

此代码段显示了一个仅运行基准测试的maven配置文件示例。

6）最后，可选项目是在您的持续集成构建管道中创建一个可运行的构建步骤。为了独立运行基准测试，您或您的CI可以运行：