建设网站jw100,怎么在网上卖东西到国外,网站优化怎么做的,如何留住网站用户这是Java#xff0c;Go和Rust之间的比较。这不是基准测试#xff0c;更多是对可执行文件大小、内存使用率、CPU使用率、运行时要求等的比较#xff0c;当然还有一个小的基准测试#xff0c;可以看到每秒处理的请求数量#xff0c;我将尝试对这些数字进行有意义的解读。为了…这是JavaGo和Rust之间的比较。这不是基准测试更多是对可执行文件大小、内存使用率、CPU使用率、运行时要求等的比较当然还有一个小的基准测试可以看到每秒处理的请求数量我将尝试对这些数字进行有意义的解读。为了尝试将苹果与苹果进行比较(也许是)我在此比较中使用每种语言编写了一个Web服务。Web服务非常简单它提供了三个REST服务端点(endpoint)。Web服务提供的服务端点这三个Web服务的代码仓库托管在github上。编译后的二进制文件尺寸有关如何构建二进制文件的一些信息。对于Java我使用maven-shade-plugin和mvn package命令将所有内容构建到一个大的jar中。对于Go我使用go build。最后我使用了cargo build --release构建Rust服务的二进制文件。每个程序的大小(以兆字节为单位)编译后的文件大小还取决于所选的库/依赖项因此如果依赖项的身躯臃肿则编译后的程序也将难以幸免。在我的特定情况下针对我选择的特定库以上是程序编译后的大小。在后续的一个单独小节中我会把这三个程序都构建并打包为docker镜像并列出它们的大小以显示每种语言所需的运行时开销。下面有更多详细信息。内存使用情况空闲状态每个应用程序在内存空闲时的内存使用情况什么Go和Rust版本显示空闲时内存占用量的条形图在哪里好了它们在那里只有JVM启动的程序在空闲状态时消耗160 MB以上的内存它什么也没做。Go应用程序仅使用0.86 MBRust应用也仅使用了0.36 MB。这是一个巨大的差异在这里Java使用的内存比Go和Rust应用使用的内存高出两个数量级只是空占着内存却什么都不做。那是巨大的资源浪费。服务REST请求让我们使用wrk发起访问API的请求并观察内存和CPU使用情况以及在我的计算机上三个版本程序的每个端点每秒处理的请求数。wrk -t2 -c400 -d30s http://127.0.0.1:8080/hello wrk -t2 -c400 -d30s http://127.0.0.1:8080/greeting/Janewrk -t2 -c400 -d30s http://127.0.0.1:8080/fibonacci/35上面的wrk命令使用两个线程并在连接池中保持400个打开的连接并重复调用GET端点持续30秒。这里我仅使用两个线程因为wrk和被测程序都在同一台计算机上运行所以我不希望它们在可用资源(尤其是CPU)上相互竞争(太多)。每个Web服务都经过单独测试并且在每次运行之间都重新启动了Web服务。以下是该程序的每个版本的三个运行中的最佳结果。/hello该端点返回HelloWorld信息。它分配字符串“ HelloWorld” 并将其序列化并以JSON格式返回。/hello端点的CPU使用率/hello端点的内存使用情况/hello端点处理的每秒请求数/greeting/{name}该端点接受一个段路径参数{name}然后格式化字符串“Hello,{name}!”序列化并以JSON格式的问候消息返回。/greeting端点的CPU使用率/greeting端点的内存使用情况/greeting端点处理的每秒请求数/fibonacci/{number}该端点接受一个段路径参数{number}并返回序列化为JSON格式的斐波纳契数和输入数。对于这个特定的端点我选择以递归形式实现它。我毫不怀疑迭代实现会产生更好的性能结果并且出于生产目的应该选择一种迭代形式但是在生产代码中有些情况下必须使用递归(并非专门用于计算第n个斐波那契数 )。为此我希望该实现涉及大量CPU栈分配。/fibonacci端点的CPU使用率/fibonacci端点的内存使用情况/fibonacci端点处理的每秒请求数在Fibonacci端点测试期间Java是唯一一个有150个请求超时的实现如下面wrk的输出所示。超时时间/fibonacci端点的延迟运行时大小为了模拟现实世界中的云原生应用程序并避免“它仅可以在我的机器上运行”我分别为这三个应用程序创建了一个docker镜像。Docker文件的源代码包含在代码库相应程序文件夹下。作为我使用过的Java应用程序的基础镜像openjdk:8-jre-alpine是已知大小最小的镜像之一但是这附带了一些警告这些警告可能适用于您的应用程序也可能不适用于您的应用程序主要是alpine镜像在处理环境变量名称方面不是posix兼容的因此您不能在Dockerfile中使用ENV中的(点)字符(不过这没什么大不了的)另一个是alpine Linux镜像是使用musl libc而不是glibc编译的这意味着如果您的应用程序依赖于需要glibc它可能无法正常工作。不过在这里alpine镜像工作是正常的。至于应用程序的Go版本和Rust版本我已经对其进行了静态编译这意味着它们不希望在运行时镜像中存在libc(glibcmusl…等)这也意味着它们不需要运行OS的基本镜像。因此我使用了scratch docker镜像这是一个no-op镜像以零开销托管已编译的可执行文件。我使用的Docker镜像的命名约定为{lang}/webservice。该应用程序的JavaGo和Rust版本的镜像大小分别为113、8.68和4.24 MB。最终Docker镜像大小结论三种语言的比较在得出任何结论之前我想指出这三种语言之间的关系。Java和Go都是支持垃圾回收的语言但是Java会提前编译为在JVM上运行的字节码。启动Java应用程序时JIT编译器会被调用以通过将字节码编译为本地代码来优化字节码以提高应用程序的性能。Go和Rust都提前编译为本地代码并且在运行时不会进行进一步的优化。Java和Go都是支持垃圾收集的语言具有**STW(停止世界)**的副作用。这意味着每当垃圾收集器运行时它将停止应用程序进行垃圾收集并在完成后从停止的地方恢复应用程序。大多数垃圾收集器需要停止运行但是有些实现似乎不需要这样做。当Java语言在90年代创建时其最大的卖点之一是一次编写可在任何地方运行。当时这非常好因为市场上没有很多虚拟化解决方案。如今大多数CPU支持虚拟化这种虚拟化抵消了使用某种语言进行开发的诱惑(该语言承诺可以运行在任何平台上)。Docker和其他解决方案以更为低廉的代价提供虚拟化。在整个测试中应用程序的Java版本比Go或Rust对应版本消耗了更多的内存在前两个测试中Java使用的内存大约增加了8000。这意味着对于实际应用程序Java应用程序的运行成本会更高。对于前两个测试Go应用程序使用的CPU比Java少20同时处理比java版多出38的请求。另一方面Rust版本使用的CPU比Go减少了57而处理的请求却增加了13。第三次测试在设计上是占用大量CPU的资源因此我想从中挤出CPU的每一分。Go和Rust都比Java多使用了1的CPU。而且我认为如果wrk不是在同一台计算机上运行那么这三个版本都会使CPU达到100%的上限值。在内存方面Java使用的内存比Go和Rust多2000。Java可以处理的请求比Go多出20而Rust可以处理的请求比Java多出15。在撰写本文时Java编程语言已经存在了将近30年这使得在市场上寻找Java开发人员变得相对容易。另一方面Go和Rust都是相对较新的语言因此与Java相比自然而然的开发人员的数量更少些。不过Go和Rust都拥有很大的吸引力许多开发人员正在将它们用于新项目并且有许多使用Go和Rust的生产中正在运行的项目因为简单地说就资源而言它们比Java更有效。在编写本文的程序时我同时学习了Go和Rust。就我而言Go的学习曲线很短因为它是一种相对容易掌握的语言并且与其他语言相比语法很小。我只用了几天就用Go编写了程序。关于Go需要注意的一件事是编译速度我不得不承认与Java/C/C/Rust等其他语言相比它的速度非常快。该程序的Rust版本花了我大约一个星期的时间来完成我不得不说大部分时间都花在弄清borrow checker向我要什么上。Rust具有严格的所有权规则但是一旦掌握了Rust的所有权和借用概念编译器错误消息就会突然变得更加有意义。违反借阅检查规则时Rust编译器对您大吼的原因是因为编译器希望在编译时证明已分配内存的寿命和所有权。这样做可以保证程序的安全性(例如没有悬挂的指针除非使用了不安全(unsafe)的代码逃离检查)并且在编译时确定了释放位置从而消除了垃圾收集器的需求和运行时成本。当然这是以学习Rust的所有权系统为代价的。在竞争方面我认为Go是Java(通常是JVM语言)的直接竞争对手但不是Rust的竞争对手。另一方面Rust是JavaGoC和C 的重要竞争对手。由于他们的效率我看到了自己将会在Go和Rust中编写更多的程序但是很可能在Rust中编写更多的程序。两者都非常适合Web服务CLI系统程序(…etc)开发。但是Rust比Go具有根本优势。它不是垃圾收集的语言与C和C相比它可以安全地编写代码。例如Go并不是特别适合用于编写OS内核而这里又是Rust的亮点并与C/C 竞争因为它们是使用OS编写的长期存在和事实上的语言。Rust与C/C竞争的另一种方式在嵌入式世界中我将继续进行讨论。
