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
Šipek, M., Muharemagić, D., Mihaljević, B., & Radovan, A. (2020). Enhancing performance of cloud-based software applications with GraalVM and quarkus. 2020 43rd International Convention on Information, Communication and Electronic Technology (MIPRO), 1746–1751. https://doi.org/10.23919/MIPRO48935.2020.9245290
Increased complexity of network-based software solutions and the ever-rising number of concurrent users forced a shift of the IT industry to cloud computing. Conventional network software systems commonly based on monolithic application stack running on costly physical single-purpose servers are affected by significant problems of resource management, computing power distribution, and scalability. Such implementation is restricting applications to be reduced to smaller, independent services that can be more easily deployed, managed, and scaled dynamically; therefore, embellishing environmental uniformity across development, testing, and production. Current cloud-based infrastructure frequently runs on containers placed in Kubernetes or Docker-based cluster, and the system configuration is considerably different compared to the environment prevailed with common virtualizations. This paper discusses the usage of GraalVM, a polyglot high-performance virtual machine for JVM-based and other languages, combined with new Kubernetes native Java tailored stacked framework named Quarkus, formed from enhanced Java libraries. Moreover, our research explores GraalVM's creation of native images using Ahead-Of-Time (AOT) compilation and Quarkus' deployment to Kubernetes. Furthermore, we examined the architectures of given systems, various performance variables, and differing memory usage cases within our academic testing environment and presented the comparison results of selected performance measures with other traditional and contemporary solutions.
Notes & Annotations
Color-coded highlighting system used for annotations
📑 Annotations (imported on 2024-05-29#13:15:03)
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.
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].
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.
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.
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.
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.
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.
Are 100 requests enough for a warm-up of the JVM?
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.
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.
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.
In other studies OpenJDK had advantages in comparison with native in terms of throughput. Unfortunately that was not measured here.
Figure 5. Response time in milliseconds obtained from a custom benchmark test (featuring a small RESTful API with basic CRUD operations) in selected frameworks