雅库茨克,左溢的照片,全乒乓
负载测试方法
我们使用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