Oracle,Open JDK等四大JVM性能對比的示例分析

這篇文章將為大家詳細講解有關Oracle,Open JDK等四大JVM性能對比的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

市面上可供選擇的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

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上執行了測試)。此功能可能會大大提高性能。

關于“Oracle,Open JDK等四大JVM性能對比的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。