Java微服务可以和Go一样快吗?

我们想进行实验,看看Java微服务是否可以像Go微服务一样快速运行。 业界普遍认为Java是"老的","慢的"和"无聊的"。 Go是"快速","新"和"酷"。 但是我们想知道这些特性是否得到实际性能数据的保证或支持。

为松山等地区用户提供了全套网页设计制作服务,及松山网站建设行业解决方案。主营业务为做网站、网站制作、松山网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!

我们想要一个公平的测试,所以我们创建了一个非常简单的微服务,没有外部依赖项(例如数据库),并且代码路径非常短(仅处理字符串)。 我们确实包含了指标和日志记录,因为它们似乎总是包含在任何实际的微服务中。 我们使用了小型轻量级的框架(Helidon for Java和Go-Kit for Go),并且还尝试了Java的纯JAX-RS。 我们尝试了不同版本的Java和不同的JVM。 我们对堆大小和垃圾收集器进行了一些基本调整。 我们在测试运行之前对微服务进行了预热。

Java的历史

Java由Sun Microsystems开发,后来被Oracle收购。 其1.0版本于1996年发布,最新版本是2020年的Java15。主要设计目标是Java虚拟机和字节码的可移植性以及带有垃圾回收的内存管理。 它仍然是最流行的语言之一(根据StackOverflow和TIOBE之类的来源),它是在开源中开发的。

让我们谈谈" Java问题"。

多年来,Java有许多不同的垃圾收集算法,包括串行,并行,并发标记/清除,G1和新的ZGC垃圾收集器。 现代垃圾收集器旨在最大程度地减少垃圾收集"停止世界"暂停的时间。

Oracle实验室开发了一种新的名为GraalVM的Java虚拟机,该Java虚拟机用Java编写,具有新的编译器和一些令人兴奋的新功能,例如能够将Java字节码转换为无需Java VM即可运行的本机映像。

Go的历史

Go由Google的Robert Griesemer,Rob Pike和Ken Thomson创建。

Go受C,Python,Javascript和C的影响。 它被设计为用于高性能网络和多处理的最佳语言。

在我们演讲时,StackOverflow有27,872个被" Go"标记的问题,而Java则为1,702,730。

Go是一种静态类型的编译语言。

Go是许多CNCF项目的首选语言,例如Kubernetes,Istio,Prometheus和Grafana都(大部分)用Go编写。

它旨在具有快速的构建时间和快速的执行。

Go(与Java相比)有什么好处-根据我的经验,这是我的个人看法:

  • 容易实现功能模式,例如合成,纯函数,不可变状态。
  • 样板代码少得多(但仍然太多)。
  • 它仍然处于生命周期的早期,因此它不具有向后兼容的沉重负担-他们仍然可以打破现状来改进它。
  • 它可以编译成本地静态链接的二进制文件-无虚拟机层-二进制文件具有运行程序所需的一切,这对于" FROM scratch"容器非常有用。
  • 它具有体积小,启动快和执行快的特点。
  • 没有OOP,继承,泛型,断言,指针算术。
  • 括号较少,例如
  • 没有循环依赖性,没有未使用的变量或导入,没有隐式类型转换的强制。

那么,Go的"问题"是什么?

  • 工具生态系统还不成熟,尤其是依赖管理-有多种选择,没有一个是完美的,特别是对于非开源开发而言;
  • 建立具有新/更新依赖关系的代码非常慢(例如Maven著名的"下载Internet"问题。
  • 导入会将代码绑定到存储库,这使代码在噩梦中移动。
  • IDE非常适合编程,文档查找,自动完成等。
  • 指针!
  • 没有Java风格的try / catch异常(如果err!= nil的使用频率太高,您最终会写出来),没有功能风格的原语,例如列表,映射函数等。
  • 由于它尚不可用,您通常会最终实现一些基本算法。 最近,我写了一些代码,由sloe进行了两个字符串(列表)的比较,并进行了转换。 用一种功能语言,我本可以使用诸如map这样的内置函数来做到这一点。
  • 没有动态链接! (您问"谁在乎?"。)如果您要使用带有"感染"静态链接代码的GPL许可证的代码,这可能是一个真正的问题。
  • 调节执行或垃圾收集,配置文件执行或优化算法的旋钮并不多-Java具有数百种垃圾收集调整选项,而Go具有一个-启用或禁用。

负载测试方法

我们使用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

> Response times for test runs with warmup but no logging

第二轮的一些观察:

  • 在此测试中,Java变体的性能要好得多,并且在不使用日志记录的情况下,其性能要比Go好很多
  • Java似乎更有能力使用硬件提供的多个内核和执行线程(与Go相比)–这是有一定道理的,因为Go旨在作为一种系统和网络编程语言,并且它是一种较年轻的语言,因此
  • 有趣的是,Java是在多核处理器不常见的时候设计的,而Go是在多核处理器不是通用的时候设计的。
  • 特别是,似乎Java日志记录已成功卸载到其他线程/内核,并且对性能的影响要小得多。
  • 这一轮的最佳性能来自GraalVM本机映像,平均响应时间为0.25毫秒,每秒处理82,426个事务,而Go的最佳结果为1.59毫秒和39,227 tps,但这是以增加两个数量级的内存为代价的用法!
  • Java变体的响应时间似乎更加一致,但是出现了更多的峰值-我们认为这意味着Go在做更多,更小的垃圾回收

第三轮-Kubernetes

在第三轮中,我们决定在Kubernetes集群中运行应用程序—您可能会说,这是微服务的更自然的运行时环境。

在这一轮中,我们使用了具有三个工作节点的Kubernetes 1.16.8集群,每个工作节点都有两个内核(每个都有两个执行线程),14GB的RAM和Oracle Linux 7.8。 在某些测试中,我们为每个变体运行了一个Pod,在其他测试中运行了100个Pod。

应用程序访问是通过Traefik入口控制器进行的,其中JMeter在Kubernetes集群外部运行,以进行某些测试,对于其他测试,我们使用ClusterIP并在集群中运行JMeter。

与之前的测试一样,我们使用了100个线程,每个线程10,000个循环,以及10秒的启动时间。

以下是每个变体的容器大小:

  • 继续11.6MB
  • Java / Helidon 1.41GB
  • Java / Helidon JLinked 150MB
  • 本机图像25.2MB

结果如下:

以下是一些响应时间表:

> Response times from Kubernetes tests

在这一轮中,我们观察到Go有时会更快,而GraalVM本地映像有时会更快,但是两者之间的差异很小(通常小于5%)

那我们学到了什么?

我们对所有这些测试和结果进行了反思,以下是一些结论:

  • Kubernetes似乎没有迅速扩展
  • Java似乎比Go更擅长使用所有可用的内核/线程-我们发现Java测试期间CPU利用率更高
  • 在具有更多内核和内存的机器上,Java性能更好;在较小/功能较弱的机器上,Go性能更好。
  • Go的性能总体上更加一致-可能是由于Java的垃圾回收
  • 在"生产规模"的计算机上,Java的运行速度与Go一样快,甚至更快
  • 日志记录似乎是我们在Go和Java中遇到的主要瓶颈
  • Java的现代版本以及诸如Helidon之类的新框架在消除/减少Java的一些众所周知且长期存在的问题(例如冗长程度,GC性能,启动时间等)的痛苦方面取得了长足的进步。

接下来是什么?

这是一个非常有趣的练习,我们打算继续努力,特别是:

  • 我们想通过Kubernetes自动扩展做更多的工作-我们可能需要更复杂的微服务或更高的负载才能看到性能上的差异
  • 我们希望研究更复杂的微服务,多种服务以及电路中断等模式,并观察网络如何影响性能以及如何调整微服务网络
  • 还想看一下日志记录问题,看看该怎么做才能消除瓶颈
  • 我们想看一下目标代码并比较正在执行的实际指令,看看是否可以在代码路径中做一些进一步的优化。
  • 我们想知道JMeter是否可以在不成为瓶颈的情况下产生足够的负载,但是我们的测试表明这根本不是一个因素,它可以轻松跟上Go和Java实现。
  • 想要对容器启动时间,内存占用量等进行更详细的测量。

新闻标题:Java微服务可以和Go一样快吗?
网页路径:http://www.shufengxianlan.com/qtweb/news25/268525.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联