码迷,mamicode.com
首页 > 数据库 > 详细

[转帖]是否值得付费?Oracle,Open JDK等四大JVM性能全面对比

时间:2020-01-17 09:47:26      阅读:81      评论:0      收藏:0      [点我收藏+]

标签:延迟   场景   lease   tor   jar   吞吐量   付费   互联网   color   

是否值得付费?Oracle,Open JDK等四大JVM性能全面对比

https://blog.csdn.net/weixin_45583158/article/details/100143505

不通的jdk的性能是不一样的. 

 



导读:随着Java 11 的发布,Oracle JDK成为收费软件,很多公司转向寻找Oracle JDK的替代品。有很多人都会怀疑,Oracle JDK和其他JDK之间有没有很大的性能差异,本文作者通过多方面测试,给出这个问题的答案,适合Java程序员研读。

 

市面上可供选择的JVM发行版还是有不少的。选择合适的JVM需要考虑不同的因素。性能是其中一个重要的因素。靠谱的性能研究是很困难的。在本文中,我创建了一个测试,在不同的JVM上执行对比测试。测试程序包括Spring Boot REST应用,使用Prometheus监控JVM并使用Grafana可视化。下图是示意图。除了soapui外,所有东西都在docker容器中运行。

 

 


隔离干扰因素

如何确定没有别的因素干扰你的设施。我们可以通过尝试隔离分配给流程的资源来实现。 例如,分配专用CPU和固定数量的内存。 我还进行了几项测试,这些测试将资源限制放在负载均衡器,监控软件和可视化软件上(为这些资源分配不同的CPU和内存)。 为进程分配特定资源(使用docker-compose v2 cpuset和内存参数)似乎不会对单个进程负载和响应时间的度量产生很大影响。 我还比较了启动,负载和无负载情况。 在这些不同情况下,测试结果没有很大变化。

为进程分配特定CPU和内存

使用docker-compose无法为进程配置特定CPU。 docker-compose v3不支持为进程分配特定的CPU,也不支持分配资源约束。 您可以想象在潜在的多主机环境中分配特定CPU并非易事。 因此,我将docker-compose文件迁移回v2,该版本允许分配特定的CPU。 可以用于监控软件,这些CPU和JVM使用的CPU隔离开。 我使用了taskset命令。

同环境测试

您如何确保所有测试都在完全相同的情况下进行? 当我针对JVM运行测试而明天再次运行相同的测试场景时,我的结果会有所不同。 这可能有各种原因,例如不同的CPU会占用工作负载,而且这些CPU也忙于处理其他事情,或者我在主机或客户操作系统中运行不同的后台进程。 即使首次测试单个JVM并在测试之后测试另一个JVM,结果也无法比较。 例如,我正在使用Prometheus收集数据。 在第二次运行期间,Prometheus数据库可能会存储更多数据。 这可能会导致添加新数据的速度变慢,这可能会影响第二个JVM性能指标。 这个例子虽然可能相当牵强,但您可以采取措施排除其他因素。 这是我选择同时执行所有测试的原因。

setup

我的环境包括一个docker-compose文件,它允许我轻松启动4个在不同JVM上运行Spring Boot应用程序。 在4个JDK的之前,我加了一个haproxy实例来进行负载均衡。 这是为了确保不同的测试之间没有时间相关的差异,保证所有JVM都同时处于相同的负载下。

为了监控结果,我使用了Micrometer保证Prometheus能够读取JVM性能指标。 我使用Grafana对数据可视化:https://grafana.com/dashboards/4701

由于GraalVM目前仅作为JDK 8版本提供,因此其他JVM也使用JDK 8。 当容器运行时,可以通过访问执行器url来检查JVM版本:localhost:8080/actuator/env

 

 

或者使用如下命令:


docker exec -it store/oracle/serverjre:8 java -version
使用的JVM版本如下:

GraalVM CE rc9 (8u192)

OpenJDK 8u191

Zulu 8u192

Oracle JDK 8u181


开始测试

可以在这里下载代码,然后运行命令:

sh ./buildjdkcontainers.sh</pre>
<pre class="graf graf--pre">docker-compose -f docker-compose-jdks.yml up
你可以可以访问:

8080端口的haproxy

9090端口的Prometheus

3000端口的Grafana

需要配置Grafana访问Prometheus的数据

 

 

 

接下来配置Grafana中的dashboard:

 

 


接下来,您可以对http://localhost:8080/hello(HTTP GET)执行负载测试,并在Grafana仪表板中查看结果。

操作系统差异

不同Docker镜像之间使用的OS不同。 操作系统可通过以下方式确定:

docker exec -it store/oracle/serverjre:8 cat /etc/*-release
azul/zulu-openjdk:8 used Ubuntu 18.04

oracle/graalvm-ce:1.0.0-rc9 used Oracle Linux Server 7.5

openjdk:8 used Debian GNU/Linux 9

store/oracle/serverjre:8 used Oracle Linux Server 7.5

我认为这不会对JVM运行产生太大的影响。OracleJDK和Graalvm使用相同的操作系统。

测试结果
使用JVM dashboard,可以轻松区分特定的差异区域,以便进一步研究它们。

 

cpu使用

 


GraalVM在测试期间总体CPU使用率最高。 Oracle JDK的CPU使用率最低。


响应时间


整体GraalVM的响应时间最短,OpenJDK最好,紧随Oracle JDK和Zulu。 平均而言,OpenJDK与GraalVM之间的差异约为30%。

 

 

垃圾回收


GraalVM加载了比其他JDK更多的类。 OpenJDK加载最少的类。 GraalVM和OpenJDK之间的差异大约是25%。 尚未确定这是否是GraalVM的固定开销,或者与所使用的类的数量成比例。

 

 

这些额外的类可能会导致垃圾收集期间的延迟(尽管这种相关性可能不一定是因果关系)。 GraalVM的的GC暂停时间确实最长。

下面是GC暂停时间总和的图表。 由于GraalVM中的分配失败导致了最长的GC暂停时间(顶部的一行)。

 

 

内存使用

 

 


JVM内存使用情况很有意思。 如上图所示,OpenJDK JVM使用的内存堆垛。 GraalVM和Zulu的垃圾收集行为似乎相似,但GraalVM具有更高的内存使用率。 Oracle JDK垃圾收集并不频繁。 在查看平均值时,OpenJDK JVM使用最大内存,而Zulu使用最少内存。 在较长时间内衡量时,Oracle JDK和OpenJDK的行为看起来不稳定,而Zulu和GraalVM看起来更稳定。

 

 

总结


在本次测试中,我使用SOAP UI对运行在4个不同JVM上的Spring Boot Rest程序进行了压力测试。我使用Prometheus轮询JVM实例(每5s轮训一次,用Micrometer生成数据),并使用Grafana和Prometheus来显示数据。结果表明GraalVM不适合作为OpenJDK的替代品,因为它的表现更差,使用了更多资源,加载更多类而且垃圾收集时间更长。

GraalVM加载的类更多

GraalVM 上的应用程序响应时间最慢

GraalVM的CPU使用率最高(响应时间最慢)

GraalVM的GC时间最长

Zulu OpenJDK使用的内存最少。与Oracle JDK和OpenJDK相比,Zulu OpenJDK和GraalVM的内存使用更稳定。

当然,由于GraalVM相对较新,Micrometer提供的指标可能无法正确显示实际吞吐量和资源使用情况。也可能是我的设置导致这种差异。我通过查看不同情况下的结果来排除第二个问题。

如果您想使用GraalVM的多语言功能,那么其他JVM无此功能。GraalVM也提供了本地编译选项(我在同一个JAR上执行了测试)。此功能可能会大大提高性能。

原文地址:https://technology.amis.nl/2018/11/23/comparing-jvm-performance-zulu-openjdk-openjdk-oracle-jdk-graalvm-ce/#prettyPhoto

 

本文作者Maarten Smeets,由方圆翻译。转载本文请注明出处,欢迎更多小伙伴加入翻译及投稿文章的行列,详情请戳公众号菜单「联系我们」。GIAC全球互联网架构大会深圳站将于2019年6月举行,届时将有Java专题深入探讨相关话题,敬请期待。

 

参考阅读:

 

为何服务器QPS上不去?Java线程调优权威指南

C++ Python PHP Java NodeJS性能大PK,结果PHP7是最……

一文读懂Java 11的ZGC为何如此高效

JDK 11中将会加入令人惊叹的ZGC(不到2毫秒)

深入解读 Java 9 新特性

Java10来了,来看看它一同发布的全新JIT编译器

Java性能优化指南及唯品会的实战

 

技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。转载请注明来自高可用架构「ArchNotes」微信公众号及包含以下二维码。

 

高可用架构

改变互联网的构建方式


长按二维码 关注「高可用架构」公众号
————————————————
版权声明:本文为CSDN博主「高可用架构」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_45583158/article/details/100143505

[转帖]是否值得付费?Oracle,Open JDK等四大JVM性能全面对比

标签:延迟   场景   lease   tor   jar   吞吐量   付费   互联网   color   

原文地址:https://www.cnblogs.com/jinanxiaolaohu/p/12160356.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!