#quarkus
#quarkus
Вопрос:
Я сравниваю одно и то же приложение 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.
Ответ №1:
Время запуска и потребление памяти, безусловно, будут лучше с собственными приложениями quarkus. Это потому, что quarkus расширяет концепцию собственного изображения graalvm.
Из https://www.graalvm.org/reference-manual/native-image /
native-image — это утилита, которая обрабатывает все классы приложения и их зависимости, в том числе из JDK. Он статически анализирует эти данные, чтобы определить, какие классы и методы доступны во время выполнения приложения. Затем он заблаговременно компилирует этот доступный код и данные в собственный исполняемый файл для конкретной операционной системы и архитектуры.
Поскольку приложение обрабатывается с опережающей компиляцией, а используемая JVM (она же Substrate VM) содержит только основную часть, результирующая программа имеет более быстрое время запуска и меньшую нагрузку на память во время выполнения по сравнению с JVM.