0

我在不同的可执行文件、常规 jar、fast-jar 和本机可执行文件中比较相同的 Quarkus 应用程序。为了能够比较它们，我进行了相同的性能测试。

结果如下：

  • 普通 Jar，以0.904s. 关于性能，结果如下：

    Running 1m test @ http://localhost:8080/hello
2 threads and 10 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
  Latency   361.86us    4.48ms 155.85ms   99.73%
  Req/Sec    29.86k     4.72k   37.60k    87.83%
3565393 requests in 1.00m, 282.22MB read
Requests/sec:  59324.15
Transfer/sec:      4.70MB

  • Fast-Jar，开始于0.590s. 关于性能，结果如下：

    Running 1m test @ http://localhost:8080/hello
2 threads and 10 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
  Latency   344.38us    3.89ms 142.71ms   99.74%
  Req/Sec    27.21k     6.52k   40.67k    73.48%
3246932 requests in 1.00m, 257.01MB read
Requests/sec:  54025.50
Transfer/sec:      4.28MB

  • 本机，从0.011s. 关于性能，结果如下：

    Running 1m test @ http://localhost:8080/hello
2 threads and 10 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
  Latency   303.72us  471.86us  29.00ms   98.05%
  Req/Sec    19.03k     3.21k   30.19k    78.75%
2272236 requests in 1.00m, 179.86MB read
Requests/sec:  37867.20
Transfer/sec:      3.00MB

在本机应用程序中处理的请求数大约比 JVM Quarkus 应用程序少 100 万。但是，原生应用程序中的启动时间、Avg 和 Stdev 比其他应用程序要好。

我想知道为什么会发生这种情况，以及本机应用程序是否比 JVM 更好。

4

1 回答 1

2

原生 quarkus 应用程序的启动时间和内存消耗肯定会更好。这是因为 quarkus 扩展了 graalvm 的原生图像概念。

来自https://www.graalvm.org/reference-manual/native-image/

native-image 是一个实用程序，它处理应用程序的所有类及其依赖项，包括来自 JDK 的那些。它静态分析这些数据以确定在应用程序执行期间可以访问哪些类和方法。然后它提前将可访问的代码和数据编译为特定操作系统和架构的本机可执行文件。

由于应用程序是通过提前编译处理的，并且使用的 JVM（也称为 Substrate VM）只包含基本部分，因此与 JVM 相比，生成的程序具有更快的启动时间和更低的运行时内存开销。

于 2021-04-01T11:52:24.837 回答