Enhancing performance of cloud-based software applications with GraalVM and quarkus

Status:: 🟩
Links:: Optimization of Java Applications – CPU Usage, Memory Usage, Startup Time, Resource Efficiency

Metadata

Authors:: Šipek, M.; Muharemagić, D.; Mihaljević, B.; Radovan, A.
Title:: Enhancing performance of cloud-based software applications with GraalVM and quarkus
Date:: 2020
URL:: https://ieeexplore.ieee.org/abstract/document/9245290
DOI:: 10.23919/MIPRO48935.2020.9245290

Notes & Annotations

Color-coded highlighting system used for annotations

📑 Annotations (imported on 2024-05-29#13:15:03)

sipek.etal.2020.enhancingperformancecloudbased (pg. 2)

JVM Compiler Interface (JVMCI) is connecting the Graal compiler with the underlying HotSpot VM in order to allow this new compiler written in Java to be used as the just-in-time (JIT) compiler, allowing JVM-based languages such as Java, Scala, Kotlin, Groovy and Clojure to be run, as well as a static, AOT compiler, used for creation of native images. Graal’s modular architecture allows the reusability of common components; furthermore, taking the advantage of straightforwardness and affability of developing a compiler entirely in Java.

sipek.etal.2020.enhancingperformancecloudbased (pg. 3)

Native and serverless environments require additional adaption of containers and native images as larger applications consume more memory thus inducing significantly higher cost. Further enhancement of the Java system is supported by Quarkus, a Kubernetes Native Java stack framework, designed to work both with HotSpot VM and GraalVM. As Quarkus presents cloud-optimized Java libraries, constraints presented with the translation of Java into native images are reduced, thereby benefiting the image creation mechanism [17].

sipek.etal.2020.enhancingperformancecloudbased (pg. 4)

Micronaut is, similarly, a complete polyglot full-stack application framework for any type of application, while being focused on microservices and serverless applications. It uses AOT for all dependency and configuration injections for precomputing annotation metadata during compilation time, consequently removing all the metadata work at runtime. Hence, anything that is framework infrastructure is performed at compilation time to avoid higher memory and startup time at runtime.

sipek.etal.2020.enhancingperformancecloudbased (pg. 4)

For this research we selected the Renaissance benchmark suite, composed of modern, real-world, concurrent, and object-oriented workloads that exercise various concurrency primitives of the JVM. This new opensource suite proposes a representative set of 21 benchmarks that bring into focus concurrency and parallelism paradigms, as well as newer language and JVM features, such as Java Lambdas, invokedynamic, and method handles [18], giving it the advantage over other benchmark suites like DaCapo or SPECjvm200815.

sipek.etal.2020.enhancingperformancecloudbased (pg. 4)

Most commonly, benchmark tests have a warm-up stage, which takes either a certain number of iterations (Renaissance, DaCapo) or execution time (SPECjvm2008) in order for the JVM to stabilize. Only after that criterion is met we can obtain the credible benchmark results from the execution, called the steady-state.

sipek.etal.2020.enhancingperformancecloudbased (pg. 4)

We have also implemented a RESTful API system16 featuring CRUD operations in several modern frameworks, including Spring Boot (release 2.2.4), Quarkus (version 1.1.1), and Micronaut (version 1.2.10). Each of the implementations operate with a MySQL database through the Hibernate framework on a table. The table data was randomly generated and consists of approximately 250 rows.

sipek.etal.2020.enhancingperformancecloudbased (pg. 4)

The REST applications have been hit with 100 requests before collecting the results and calculating the average result of both the Resident Set Size (RSS) and response times.

sipek.etal.2020.enhancingperformancecloudbased (comment) (pg. 4)

Are 100 requests enough for a warm-up of the JVM?

sipek.etal.2020.enhancingperformancecloudbased (pg. 5)

In the scenario of running the movie-lens benchmark test, Graal CE outperforms OpenJDK 13 by as much as 31.22% in terms of the decreased amount of running time.

sipek.etal.2020.enhancingperformancecloudbased (pg. 5)

A standalone executable produced by GraalVM shows an 82.4% decrease in the usage of RSS memory in comparison to the same application implemented in Spring Boot running OpenJDK 13. Likewise, it is interesting to see that Micronaut outperforms Quarkus when running OpenJDK 13 by 22.92% in terms of memory allocation.

sipek.etal.2020.enhancingperformancecloudbased (pg. 5)

Quarkus running as a standalone native image produced by GraalVM runs 81.74% faster than the Spring Boot application with the same implementation. Quarkus implementation running on OpenJDK 13 runs 17.65% faster than the same Spring Boot application. Once again, Micronaut seems to outperform by 16.82% in terms of faster response times when running OpenJDK 13.

sipek.etal.2020.enhancingperformancecloudbased (comment) (pg. 5)

In other studies OpenJDK had advantages in comparison with native in terms of throughput. Unfortunately that was not measured here.

sipek.etal.2020.enhancingperformancecloudbased (image) (pg. 5)

Figure 5. Response time in milliseconds obtained from a custom benchmark test (featuring a small RESTful API with basic CRUD operations) in selected frameworks