ITPub博客

首页 > IT基础架构 > 网络通信/物联网 > 如果你想写自己的Benchmark框架

如果你想写自己的Benchmark框架

原创 网络通信/物联网 作者:pubian877 时间:2020-07-11 12:12:40 0 删除 编辑

  简介


  使用过JMH的同学一定会惊叹它的神奇。JMH作为一个优秀的Benchmark框架带给了我们无数的欢乐。作为一个有极客精神的程序员,那么有没有想过去自己实现一个Benchmark框架呢?


  在实现Benchmark框架的时候有需要注意些什么问题呢?快来一起看看吧。


  八条军规


  这里叫军规实际上不合适,只是借用一下军规的来彰显一下气势!大家不要太介意。


  第一条军规


  工欲善其事,必先利其器。想写好一个JMH当然需要深入了解JVM的运行原理,包括JIT,C1,C2编译器和他们的分层编译原理,JIT运行时的编译优化,包括Loop unrolling,Inlining,Dead Code Elimination,


  Escape analysis,Intrinsics,Branch prediction等等。


  当然,最好是参考一下大牛们写过的JMH框架,找点灵感。


  最后大家要了解,Benchmark框架不是万能的。它只是在特定的环境中JVM的表现。


  因为在Benchmark中我们肯定是要做循环的,一般来说就是某某方法运行多少次,这种比较简单的循环。实际上,JVM运行的代码是非常复杂的。Benchmark远远不能代表JVM的全部。


  但是,见微知著,使用Benchmark还是可以一窥JVM的秘密的。


  第二条军规


  在JMH中,我们一般需要设置warmup和measurement的次数:


   Warmup(iterations=10,time=1,timeUnit=TimeUnit.SECONDS)


   Measurement(iterations=5,time=1,timeUnit=TimeUnit.SECONDS)


  这是为什么呢?我们知道JIT中的代码是动态编译成为机器码的,并且是需要一定的时间的。


  只有JIT检测到你这是热点代码,才会对其进行优化。


  我们检测代码的性能,一般是指代码在稳定运行的环境中的情形。而不是指第一次或者前几次运行的时候,因为这个时候,这些代码可能并没有被编译成机器码。这样的出来的结果往往是和实际不相符的。


  第三条军规


  在编写Benchmark的同时,一定要开启JVM的日志。例如:-XX:+PrintCompilation,-verbose:gc等。


  为什么呢?


  大家想想benchmark是做什么的呢?就是统计时间的。


  我们希望在运行benchmark的时候,JVM不要做任何不属于运行代码的任何事情,否则就可能会影响到benchmark的准确性。


  所以开启JVM的日志就是为了做校验。不要在做benchmark的时候有其他操作。


  第四条军规


  注意JIT的分层编译。


  因为Client VM和Server VM的出现,所以在JIT中出现了两种不同的编译器,C1 for Client VM,C2 for Server VM。


  因为javac的编译只能做少量的优化,其实大量的动态优化是在JIT中做的。C2相对于C1,其优化的程度更深,更加激进。


  为了更好的提升编译效率,JVM在JDK7中引入了分层编译Tiered compilation的概念。


  对于JIT本身来说,动态编译是需要占用用户内存空间的,有可能会造成较高的延迟。


  对于Server服务器来说,因为代码要服务很多个client,所以磨刀不误砍柴工,短暂的延迟带来永久的收益,听起来是可以接受的。


  Server端的JIT编译也不是立马进行的,它可能需要收集到足够多的信息之后,才进行编译。


  而对于Client来说,延迟带来的性能影响就需要进行考虑了。和Server相比,它只进行了简单的机器码的编译。


  为了满足不同层次的编译需求,于是引入了分层编译的概念。


  大概来说分层编译可以分为三层:


  第一层就是禁用C1和C2编译器,这个时候没有JIT进行。


  第二层就是只开启C1编译器,因为C1编译器只会进行一些简单的JIT优化,所以这个可以应对常规情况。


  第三层就是同时开启C1和C2编译器。


  在JDK7中,你可以使用下面的命令来开启分层编译:


  -XX:+TieredCompilation


  而在JDK8之后,恭喜你,分层编译已经是默认的选项了,不用再手动开启。


  Client编译和Server编译,甚至是OSR都是不同的。大家在写Benchmark的时候一定要注意。


  第五条军规


  注意初始化对性能的影响。


  如果需要加载类,一定要在warmup的阶段进行加载,除非你是想去测试加载的时间。否则会对测试结果有影响。


  同时也不要计算第一次print的时间,因为print也会加载和初始化一些类。


  第六条军规


  要注意反优化和重编译的影响。


  JIT在下面的几个特殊的情况下,需要对代码进行返优化:


  有些特殊的情况下面,确实是需要进行反优化的。


  下面是比较常见的情况:


  需要调试的情况


  如果代码正在进行单个步骤的调试,那么之前被编译成为机器码的代码需要反优化回来,从而能够调试。


  代码废弃的情况


  当一个被编译过的方法,因为种种原因不可用了,这个时候就需要将其反优化。


  优化之前编译的代码


  有可能出现之前优化过的代码可能不够完美,需要重新优化的情况,这种情况下同样也需要进行反优化。


  重编译是指JIT可能会重新优化代码,导致重新编译。


  所以这条规则要求我们warmup的时间要尽可能的长。以便让JIT充分优化。


  第七条军规


  在使用benchMark得出结论之前,一定要去认真的理解JVM的底层代码(Assembly code),找到其现象的本质。


  千万不要冲动的下结论。最好是使用可视化的工具来分析。比如说jitwatch。


  最后一条军规


  在测试的时候一定要避免其他程序的影响。


  比如说两次测试,第一次测试是单机运行,第二次测试是在有其他服务正在运行的情况下进行的。


  很显然这两次的结果是不能做比较的。我们需要多运行,剔除噪音结果。


  总结


  掌握上面几条规则,相信大家也能够写出属于自己的Benchmarks。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69976867/viewspace-2703874/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2020-07-11

  • 博文量
    18
  • 访问量
    207663