Блог

Я сравниваю одно и то же приложение Quarkus в разных исполняемых файлах, обычном jar, быстром jar и собственном исполняемом файле. Чтобы иметь возможность сравнивать их, я запускаю один и тот же тест производительности.

Результаты следующие:

• Обычный 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
    

• Быстрая загрузка, начинается. 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
    

• Native, начните 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
    

Количество запросов, обрабатываемых в собственном приложении, примерно на 1 миллион меньше, чем в приложении JVM Quarkus. Однако время запуска, среднее значение и стандартный уровень в собственном приложении лучше, чем у других.

Мне было интересно, почему это происходит, и если собственное приложение лучше, чем одно на JVM.

Время запуска и потребление памяти, безусловно, будут лучше с собственными приложениями quarkus. Это потому, что quarkus расширяет концепцию собственного изображения graalvm.

Из https://www.graalvm.org/reference-manual/native-image /

native-image — это утилита, которая обрабатывает все классы приложения и их зависимости, в том числе из JDK. Он статически анализирует эти данные, чтобы определить, какие классы и методы доступны во время выполнения приложения. Затем он заблаговременно компилирует этот доступный код и данные в собственный исполняемый файл для конкретной операционной системы и архитектуры.

Поскольку приложение обрабатывается с опережающей компиляцией, а используемая JVM (она же Substrate VM) содержит только основную часть, результирующая программа имеет более быстрое время запуска и меньшую нагрузку на память во время выполнения по сравнению с JVM.