Shulou(Shulou.com)05/31 Report--

This article will explain in detail the example analysis of Oracle,Open JDK and other four major JVM performance comparisons. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

There are still many JVM distributions available on the market. Different factors need to be considered in choosing the right JVM. Performance is one of the important factors. It is difficult to study reliable performance. In this article, I created a test to run comparison tests on different JVM. The test program includes Spring Boot REST applications, monitoring JVM using Prometheus and visualization using Grafana. The following picture is a schematic diagram. Everything except soapui runs in the docker container.

Isolate interference factors

How to make sure there are no other factors interfering with your facility. We can do this by trying to isolate the resources allocated to the process. For example, allocate dedicated CPU and a fixed amount of memory. I also conducted several tests that limited resources to load balancers, monitoring software, and visualization software (allocating different CPU and memory for these resources). Allocating specific resources to a process (using docker-compose v2 cpuset and memory parameters) does not seem to have a significant impact on the measurement of load and response time for a single process. I also compared startup, load and no load. In these different cases, the test results did not change much.

Allocate specific CPU and memory to the process

You cannot configure a specific CPU for a process using docker-compose. Docker-compose v3 does not support the allocation of specific CPU to processes, nor does it support the allocation of resource constraints. You can imagine that allocating a specific CPU in a potential multi-host environment is not easy. Therefore, I migrated the docker-compose file back to v2, which allows the allocation of specific CPU. Can be used for monitoring software, these CPU and JVM use CPU separation. I used the taskset command.

Same environment test

How do you ensure that all tests are conducted in exactly the same situation? When I run the test against JVM and run the same test scenario again tomorrow, my results will be different. There may be a variety of reasons for this, such as different CPU consuming workloads, and these CPU are busy with other things, or I run different background processes on the host or guest operating system. Even if * tests a single JVM and tests another JVM after the test, the results cannot be compared. For example, I am using Prometheus to collect data. During the second run, the Prometheus database may store more data. This may cause new data to be added more slowly, which may affect the second JVM performance metric. Although this example may be quite far-fetched, you can take steps to exclude other factors. This is why I chose to run all tests at the same time.

Setup

My environment includes a docker-compose file that allows me to easily launch four Spring Boot applications running on different JVM. Before 4 JDK, I added a haproxy instance for load balancing. This is to ensure that there are no time-related differences between different tests and that all JVM are under the same load at the same time.

To monitor the results, I used Micrometer to ensure that Prometheus can read JVM performance metrics. I use Grafana to visualize the data: https://grafana.com/dashboards/4701

Since GraalVM is currently only available as a version of JDK 8, other JVM also use JDK 8. When the container is running, you can check the JVM version: localhost:8080/actuator/env by accessing the executor url

Or use the following command:

Docker exec-it store/oracle/serverjre:8 java-version

The version of JVM used is as follows:

GraalVM CE rc9 (8u192)

OpenJDK 8u191

Zulu 8u192

Oracle JDK 8u181

Start testing.

You can download the code here and run the command:

Sh. / buildjdkcontainers.sh

Docker-compose- f docker-compose-jdks.yml up

You can visit:

Haproxy on port 8080

Prometheus on port 9090

Grafana on port 3000

Need to configure Grafana to access Prometheus's data

Next, configure dashboard in Grafana:

Next, you can perform a load test on http://localhost:8080/hello(HTTP GET) and view the results in the Grafana dashboard.

Operating system difference

Different Docker images use different OS. The operating system can be determined in the following ways:

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

I don't think this will have much impact on the operation of JVM. OracleJDK and Graalvm use the same operating system.

Test result

With JVM dashboard, you can easily distinguish specific areas of difference for further study.

Cpu usage

The overall CPU utilization of GraalVM during the test period. CPU utilization of Oracle JDK *.

Response time

The overall GraalVM has the shortest response time, with OpenJDK***, following Oracle JDK and Zulu. On average, the difference between OpenJDK and GraalVM is about 30 per cent.

Garbage collection

GraalVM loads more classes than any other JDK. OpenJDK loads the least number of classes. The difference between GraalVM and OpenJDK is about 25%. It has not been determined whether this is a fixed cost for GraalVM or is proportional to the number of classes used.

These additional classes may cause delays during garbage collection (although this correlation may not necessarily be causal). GraalVM does have the longest GC pause.

The following is a chart of the sum of GC pause times. The longest GC pause time (the top line) was caused by an allocation failure in GraalVM.

Memory usage

JVM memory usage is interesting. As shown in the figure above, the memory stack used by OpenJDK JVM. The garbage collection behavior of GraalVM and Zulu seems to be similar, but GraalVM has higher memory usage. Oracle JDK garbage collection is infrequent. When viewing averages, OpenJDK JVM uses * memory, while Zulu uses the least memory. When measured over a long period of time, the behavior of Oracle JDK and OpenJDK looks unstable, while Zulu and GraalVM look more stable.

Summary

In this test, I used SOAP UI to stress test Spring Boot Rest programs running on four different JVM. I use Prometheus to poll the JVM instance (every 5s round robin, using Micrometer to generate data), and use Grafana and Prometheus to display the data. The results show that GraalVM is not suitable as a substitute for OpenJDK because it performs worse, uses more resources, loads more classes, and takes longer to collect garbage.

GraalVM loads more classes

Applications on GraalVM have the slowest response time

CPU utilization of GraalVM * (slowest response time)

GraalVM has the longest GC time.

Zulu OpenJDK uses the least memory. Compared with Oracle JDK and OpenJDK, Zulu OpenJDK and GraalVM have more stable memory usage.

Of course, because GraalVM is relatively new, the metrics provided by Micrometer may not correctly show the actual throughput and resource usage. It could also be my settings that cause the difference. I rule out the second problem by looking at the results in different situations.

If you want to use the multilingual functionality of GraalVM, other JVM does not have this feature. GraalVM also provides local compilation options (I ran tests on the same JAR). This feature may greatly improve performance.

This is the end of this article on "example Analysis of Oracle,Open JDK and other four JVM performance comparisons". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.