Quarkus Native Support

Learn how Quarkus builds native applications and their benefits.

Quarkus offers the possibility to build native applications. This means Quarkus will compile our code into an executable that can run directly on our operating system of choice without the need for a Java Virtual Machine (JVM).

GraalVM

GraalVM is a JVM and Java Development Kit created and maintained by Oracle since 2018. It offers different features such as a Just-In-Time (JIT) compiler that offers the possibility of building a native executable and polyglot programmingThe practice of writing code in multiple languages. by shipping different runtimes, such as R, Ruby, Python, and JavaScript.

The creation of a native image in an application for a specific operating system can be done using the command line or a build tool, such as Docker. The method for doing so varies based on the programming language, framework utilized in the application, and the intended target operating system.

Building native images for Windows is a bit more complex, and we can expect some issues. We can take advantage of the images provided by the Redhat team, which makes it easy to build native images directly with Docker.

Note: Some extensions might have specific requirements to be used in the native mode.

Quarkus performance

Compiling the application to a native application can result in improved performance in different aspects. We’ll explore some of the differences between native and JVM applications using the following runtime environment:

  • CPU: 32 x Intel® Xeon® CPU E5-2640 v3 @ 2.60GHz

  • Operating system: Red Hat Enterprise Linux Server release 7.6 (3.10.0-693.25.2.el7.x86_64)

  • Memory: 262GB

  • Ethernet: Solarflare Communications SFC9020 10G Ethernet Controller

Quarkus performance in JVM and native modes

Metric

Native Application

JVM Application

Maximum Throughput (Req/Sec)

44,841

76,488

Response Time (ms)

2.43

0.91

Application Start Time

18 ms

1629 ms

Maximum Memory Usage

122 MB

414 MB

Note: The benchmark is provided by the Quarkus team.

The metrics above show that Quarkus in native mode still lags behind in some metrics, like maximum throughput and response time, because it is still in the early phases. On the other hand, we see great improvement in the application start time and memory usage.

Usually, memory usage is very important (depending on how we pay for our cloud service), which is why reducing memory usage by more than half can make a big difference in the price of the service.

Note: For maximum throughput and response time, the number of concurrent connections is 40.

Comparison to Spring Boot

Spring Boot is considered by many to be the default go-to framework when building Java applications. The question here is how Quarkus compares with Spring Boot based on different metrics.

Comparing the two frameworks is no easy task because there are many factors, such as support for different technologies, the size of communities, and the level of support available. But for this lesson, we’ll focus on performance, especially in native mode.

Here is a summary of the most important metrics:

Note: The metrics below are provided by the Quarkus team.

Spring Boot vs. Quarkus

Metric

Spring Boot JVM

Quarkus JVM

Quarkus Native

Startup Time

~7s

~2s

~0.2s

Docker Image Size

~250MB

~230MB

~80MB

Memory Usage

~600MB

~500MB

~200MB

CPU Usage

~0.5%

~0.5%

~0.1%

The above table shows that Quarkus and Spring Boot are comparable in JVM mode with small differences depending on the extensions we use. Quarkus “wins” in the native mode where it offers better performance.

Note: Spring also offers native support with Spring Boot, but it’s still in the early phases (at the time of writing this article), so it might not be stable.