Java项目预热,为什么Java 8的预热要慢一些

在我们努力从

Java 6(u39)迁移到

Java 8(u51)的过程中,我们面临的问题是,与8相比,Java 8的预热时间更长.

我们注意到这一点都是作为Java程序运行的性能测试,以及使用Java 8启动Tomcat 7(u35)时的初始请求.

我们在Linux Redhat 64位系统上运行.

对不起,我没有任何孤立的测试用例.

关于性能测试程序,我发现Java 6在10次迭代中接近稳态性能约215毫秒,而Java 8在10次迭代后需要800毫秒,并且需要70次迭代才能达到215 ms.

当我们在重新启动Java 6之后立即在我们的tomcat webapp(使用Spring 2.5,jackson,xerces XML解析器,jedis等)上以并发10运行JMeter测试时花了不到一分钟的时间来提供稳定的状态性能而Java 8占用了大约5-6分钟,然后缓慢几个数量级.

使用-XX关闭分层编译：-TieredCompilation VM 8中的HotSpot选项修复了性能测试程序的预热问题,而稳态性能没有变化.这是令人惊讶的,因为分层编译实际上应该给予更快的热身.

但是,关闭分层编译并没有给Tomcat服务器的预热时间带来类似的改进.

我欢迎任何解决此问题的建议,因为在实时环境中部署新版本可能会成为一个长时间预热的麻烦.

谢谢,

苏雷什

最佳答案

This is surprising since Tiered Compilation is actually supposed to give faster warm up.

您会混淆时间峰值性能和初始化/响应时间应用程序.

分层

>口译员(第0层) – > C1(第1-3层) – > C2(第4层)

>重C2工作延迟到以后的某个时间点

>在C1编译代码中花费更多时间意味着应用程序启动后的类型配置文件可能更清晰,从而允许更好的优化和更少的C2中的解压缩

>应用程序可以更快地满足其第一个请求/更快地完成用户交互/短期java执行

-Tiered

>口译员 – > C2

>热门代码可能会更快达到最佳性能

>初始化和仅温暖的代码可能需要更长时间

>在某些情况下,用于分析的时间减少可能导致代码略微不理想

另一件事是编译器线程的数量(CICompilerCount).性能权衡是复杂的,因此简单地对各种设置进行基准测试可能会有所帮助.