微服务go还是java,Java微服务可以和Go一样快吗？(2)

雅库茨克，左溢的照片，全乒乓

负载测试方法

我们使用JMeter进行负载测试。 测试多次调用服务，并收集有关响应时间，吞吐量(每秒事务)和内存使用情况的数据。 对于Go，我们收集常驻集大小;对于Java，我们跟踪本机内存。

在许多测试中，我们将JMeter与被测应用程序在同一台计算机上运行。 如果我们在另一台机器上运行JMeter，结果似乎没有任何干扰或差异，因此可以简化设置。 当我们以后将应用程序部署到Kubernetes中时，JMeter在集群外部的远程计算机上运行。

在进行测量之前，我们使用了1,000次服务调用来预热了应用程序。

应用程序本身的源代码以及负载测试的定义都在以下GitHub存储库中：

https://github.com/markxnelson/go-java-go

第一轮测试

在第一轮中，我们在 小型 计算机上进行了测试，在这种情况下，该计算机是2.5GHz双核Intel Core i7笔记本电脑，具有16GB RAM，运行macOS。

结果如下：

我们宣布Go成为第一轮的获胜者!

以下是我们根据这些结果得出的观察结果：

日志记录似乎是主要的性能问题，尤其是java.util.logging。 因此，我们在进行日志记录和不进行日志记录的情况下都进行了测试。 我们还注意到，日志记录是Go应用程序性能好的重要因素。

Java版本具有显著的更大的内存占用空间，即使对于如此小的简单应用程序也是如此

预热对JVM产生了很大的影响-我们知道JVM在运行时会进行优化，因此这很有意义

在此测试中，我们正在比较不同的执行模型-Go应用程序被编译为本地可执行二进制文件，而Java应用程序被编译为字节代码，然后在虚拟机上运行。

GraalVM本机映像

GraalVM具有本机映像功能，可让您采用Java应用程序并将其本质上编译为本机可执行代码。

该可执行文件包括应用程序类，其依赖项中的类，运行时库类以及JDK中的静态链接本机代码。

这是再次添加GraalVM本机图像测试(使用GraalVM EE 20.1.1-JDK 11构建的本地图像)的第一轮结果：

在这种情况下，与在JVM上运行应用程序相比，使用GraalVM本机映像没有看到吞吐量或响应时间的任何显着改善，但是内存占用空间较小。

以下是一些测试的响应时间的图表：

Response time graphs for round one

请注意，在所有这三种Java变体中，第一个请求的响应时间要长得多(请在与左轴相对的右上方寻找那条蓝线)。

第二轮

接下来，我们决定在更大的计算机上运行测试。

与第一轮一样，我们使用了100个线程，每个线程10,000个循环，10秒的启动时间以及相同版本的Go，Java，Helidon和GraalVM。

结果如下：

我们宣布GraalVM本机映像是第二轮的赢家!

以下是这些测试的响应时间图：

Response times for test runs with logging enabled but no warmup

Response times for test runs with no logging and no warmup