Shulou(Shulou.com)06/03 Report--

This article mainly explains "whether Go micro-service can be as fast as Java". The content of the article is simple and clear, easy to learn and understand. Please follow the editor's train of thought to study and learn "whether Java micro-service can be as fast as Go".

History of Java

Java was developed by Sun Microsystems and later acquired by Oracle. Version 1. 0 was released in 1996, and the latest version is Java15 in 2020. The main design goals are the portability of Java virtual machines and bytecode and memory management with garbage collection. It is still one of the most popular languages (according to sources such as StackOverflow and TIOBE) and is developed in open source.

Let's talk about the Java problem.

Over the years, Java has had many different garbage collection algorithms, including serial, parallel, concurrent mark / clear, G1, and the new ZGC garbage collector. Modern garbage collectors are designed to minimize the time it takes for garbage collection to "stop the world".

Oracle Labs has developed a new Java virtual machine called GraalVM, which is written in Java with new compilers and exciting new features, such as the ability to convert Java bytecode to a native image that runs without Java VM.

History of Go

Go is created by Robert Griesemer,Rob Pike and Ken Thomson of Google.

Go is influenced by CJR Python javascript and C. It is designed as the best language for high-performance networks and multiprocessing.

When we spoke, StackOverflow had 27872 questions marked with "Go", while Java had 1702730.

Go is a statically typed compiled language.

Go is the preferred language for many CNCF projects, such as Kubernetes,Istio,Prometheus and Grafana are (mostly) written in Go.

It is designed to have fast build time and fast execution.

What are the benefits of Go (compared to Java)-in my experience, this is my personal opinion:

Easy to implement functional patterns, such as composition, pure functions, immutable states.

There is much less boilerplate code (but still too much).

It is still in the early stages of its life cycle, so it does not have the heavy burden of backward compatibility-they can still break the status quo to improve it.

It can be compiled into locally statically linked binaries-no virtual machine layer-binaries have everything you need to run the program, which is very useful for the "FROM scratch" container.

It has the characteristics of small size, fast start and fast execution.

No OOP, inheritance, generics, assertions, pointer arithmetic.

Fewer parentheses, for example

There are no circular dependencies, no unused variables or imports, and no implicit type conversion enforcement.

So, what is the "problem" of Go?

The tool ecosystem is immature, especially dependent on management-there are a variety of options, none of which is perfect, especially for non-open source development

It is very slow to build code with new / update dependencies (such as Maven's famous "download Internet" problem.

The import binds the code to the repository, which makes the code move in a nightmare.

IDE is very suitable for programming, document lookup, automatic completion, etc.

Hands!

There is no Java-style try / catch exception (if erratic = nil is used too frequently, you will eventually write it), there are no functional-style primitives, such as lists, mapping functions, and so on.

Since it is not yet available, you will usually end up implementing some basic algorithms. Recently, I wrote some code in which sloe compares two strings (lists) and converts them. In a functional language, I could have used built-in functions such as map to do this.

No dynamic links! You ask, "who cares?") This can be a real problem if you want to use GPL license code with an "infected" static link code.

There are not many knobs for tuning execution or garbage collection, profile execution or optimization algorithms-Java has hundreds of garbage collection tuning options, while Go has one-enabled or disabled.

Load testing method

We use JMeter for load testing. Test multiple calls to the service and collect data on response time, throughput (transactions per second), and memory usage. For Go, we collect the resident set size; for Java, we track native memory.

In many tests, we ran JMeter on the same computer as the application under test. If we run JMeter on another machine, the result does not seem to be any interference or difference, so the setup can be simplified. When we deploy the application to Kubernetes later, JMeter runs on a remote computer outside the cluster.

Before making the measurement, we used 1000 service calls to warm up the application.

First round of testing

In the first round, we tested it on a "small" computer, which in this case was a 2.5GHz dual-core Intel Core i7 laptop with 16GB RAM and running macOS.

The results are as follows:

We announce Go as the winner of the first round!

Here are our observations based on these results:

Logging seems to be a major performance problem, especially java.util.logging. Therefore, we tested both with and without logging. We also note that logging is an important factor in the performance of Go applications.

The Java version has a significantly larger memory footprint, even for such a small, simple application

Preheating has a big impact on JVM-we know that JVM will be optimized at run time, so it makes sense

In this test, we are comparing different execution models-the Go application is compiled into a local executable binary, while the Java application is compiled into bytecode and then run on the virtual machine.

GraalVM native image

GraalVM has a native image feature that allows you to take a Java application and essentially compile it into native executable code.

The executable includes application classes, classes in their dependencies, runtime library classes, and statically linked native code in JDK.

This is the first round of the result of adding GraalVM native image tests again (local images built using GraalVM EE 20.1.1-JDK 11):

In this case using the GraalVM native image does not see any significant improvement in throughput or response time compared to running the application on JVM but has a smaller memory footprint.

The following is a chart of the response time for some tests:

> Response time graphs for round one

Note that of all three Java variants, the response time for the first request is much longer (look for the blue line at the top right opposite the left axis).

The second round

Next, we decided to run the test on a larger computer.

As in the first round, we used 100 threads, 10000 loops per thread, 10 seconds of startup time, and the same version of Go,Java,Helidon and GraalVM.

The results are as follows:

We announce that the GraalVM native image is the winner of the second round!

The following is the response time diagram for these tests:

> Response times for test runs with logging enabled but no warmup

> Response times for test runs with no logging and no warmup

> Response times for test runs with warmup but no logging

Some observations of the second round:

In this test, the Java variant performs much better, and without logging, its performance is much better than Go

Java seems to be more capable of using multiple cores and execution threads provided by the hardware (compared to Go)-this makes sense, because Go is intended as a system and network programming language, and it is a younger language, so

Interestingly, Java is designed when multi-core processors are not common, while Go is designed when multi-core processors are not universal.

In particular, it seems that Java logging has been successfully offloaded to other threads / kernels and has a much smaller performance impact.

The best performance in this round comes from the GraalVM native image, with an average response time of 0.25ms and processing 82426 transactions per second, while Go's best results are 1.59ms and 39227 tps, but this is at the cost of adding two orders of magnitude of memory!

The response time of the Java variant seems to be more consistent, but there are more peaks-we think this means that Go is doing more, smaller garbage collection.

Round 3-Kubernetes

In the third round, we decided to run the application in a Kubernetes cluster-a more natural runtime environment for microservices, you might say.

In this round, we used a Kubernetes 1.16.8 cluster with three worker nodes, each with two cores (each with two threads of execution), 14GB's RAM and Oracle Linux 7.8. In some tests, we ran one Pod for each variant and 100 Pod in other tests.

Application access is done through the Traefik entry controller, where JMeter runs outside the Kubernetes cluster for some tests, and for others, we use ClusterIP and run JMeter in the cluster.

As in the previous test, we used 100 threads, 10000 loops per thread, and a 10-second startup time.

The following is the container size for each variant:

Continue 11.6MB

Java / Helidon 1.41GB

Java / Helidon JLinked 150MB

Native image 25.2MB

The results are as follows:

Here are some response schedules:

> Response times from Kubernetes tests

In this round, we observed that Go is sometimes faster, while GraalVM local images are sometimes faster, but the difference between the two is small (usually less than 5%)

So what have we learned?

We have reflected on all these tests and results, and here are some conclusions:

Kubernetes doesn't seem to be expanding rapidly.

Java seems to be better at using all available kernels / threads than Go-we found that CPU utilization was higher during Java testing

Java performs better on machines with more cores and memory, and Go performs better on smaller / weaker machines.

Go's performance is generally more consistent-probably due to Java's garbage collection

On "production scale" computers, Java runs as fast as or even faster than Go

Logging seems to be the main bottleneck we encounter in Go and Java

Modern versions of Java and new frameworks such as Helidon have made great strides in eliminating / reducing the pain of some well-known and long-standing problems with Java, such as verbosity, GC performance, startup time, etc.

What's next?

This is a very interesting exercise, and we intend to continue to work hard, especially:

We want to do more with Kubernetes auto-extension-we may need more complex microservices or higher loads to see the difference in performance

We want to study more complex modes of microservices, multiple services, and circuit outages, and observe how the network affects performance and how to adjust the microservice network.

I also want to take a look at the logging problem and see what can be done to eliminate the bottleneck.

We want to look at the target code and compare the actual instructions being executed to see if we can make some further optimizations in the code path.

We wanted to know if JMeter could generate enough load without becoming a bottleneck, but our tests showed that this was not a factor at all and that it could easily keep up with Go and Java implementations.

Want to measure the container startup time, memory usage and so on in more detail.

Thank you for reading, the above is the content of "whether Java micro services can be as fast as Go". After the study of this article, I believe you have a deeper understanding of whether Java micro services can be as fast as Go, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.