Microservices and serverless architectures are being implemented, or are a part of the roadmap, in most modern solution stacks. Given that Java is still the dominant language for business applications, the need for reducing the startup time for Java is becoming more important. Serverless architectures are one such area that needs faster startup times, and applications hosted on container platforms such as Red Hat Openshift can benefit from both fast Java startup time and a smaller Docker image size.
Let’s see how GraalVM can be beneficial for Java-based programs in terms of speed and size improvements. Surely, these gains are not bound to containers or serverless architectures and can be applied to a variety of use cases.
GraalVM allows you to compile a program ahead of time into a native executable. The resulting program does not run on the Java HotSpot VM, but instead uses necessary components such as memory management and thread scheduling from a different implementation of a virtual machine called Substrate VM. Substrate VM is written in Java and compiled into the native executable. The resulting program has faster startup time and less runtime memory overhead compared to a Java VM. (This definition is referenced from the Graal website).
This article compares the following metrics:
- JVM startup time with GraalVM RC4 versus OpenJDK 10
- The bare minimum Docker image sizes needed for running the uberjar versus the native binary
The complete code for this exercise is available in this repository. The Netty-related part of this repository is made available by Codrut Stancu via his excellent blog.
This project uses the following tools:
Let’s first compare the startup time.
Startup time
The startup time is measured as the time difference between the program start and when the program is ready to take requests. It is very encouraging to see that the native compiled image brings us an average startup time of ~17 milliseconds compared to an average of ~850 milliseconds with the JVM.
This improvement warrants using the Graal native image for applications that need fast startup times, for example, serverless architectures and containers. However, the native compilation has some specific restrictions, especially around the use of reflection and dynamic class loading. This makes it harder (at least for now) to move all applications to native binaries, but with every release of Graal, compatibility is improving.
The other notable metric is that the size of the native image is almost double the size of the uberjar. The uberjar is about 7.0MB while the native binary is approximately 15MB. Keep in mind that the uberjar needs the Java runtime to be operational, as you shall see in the "Container size" section below, while with the native image, the size of the Docker container is smaller than that with the uberjar container.
Setup
If you want to run this application locally, make sure that the MONGO_IP (which defines the IP address of the MongoDB database) and DIE environment variables are set. If DIE is set to any value, this application will terminate as soon as it starts completely. To run the application, you need to unset this variable. If the DIE variable is unset, the application will start and take requests. The application can be accessed via http://localhost:8080/.
To run the application locally, do the following:
$ git clone https://github.com/masoodfaisal/need4speed.git $ cd netty-mongo-native $ mvn clean install $ export MONGO_IP=127.0.0.1 $ export DIE=true #or unset DIE if you want the application to stay alive $ time java -jar target/netty-mongo-native-full.jar
The full binary of the application is made available via the following command. Make sure that Graal is available on your local machine.
native-image -jar target/netty-mongo-native-full.jar \ -H:ReflectionConfigurationResources=netty_reflection_config.json \ -H:Name=netty-svm-http-server \ -H:+ReportUnsupportedElementsAtRuntime
The startup time is measured with the new JVM compiler interface (JVMCI) options available from JDK 9. The measured time reported here is recorded with the following JVM flags:
-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCI
Note that no measurements have been captured via ahead-of-time compilation (AOTC), and it would be interesting to see what changes AOTC brings to the mix.
Container size
The Docker image for the natively compiled artifact is less than half the size of the container with the JRE. Native compilation provides great savings in the Docker image size, and this could be a big win for container environments such as Kubernetes.
Setup
The fedora-minimal base image is being used as the runtime for the JVM and native images. The sizes shown in the metrics above are the from SIZE column of the docker images command.
All Docker files are available in the source repository. Build the images using following commands:
$ docker build -t fedora-minimal:jvm --file DockerfileFedoraMinimalJVM . $ docker build -t fedora-minimal:native --file DockerfileFedoraMinimalNative . $ docker build -t fedora:jvm --file DockerfileFedoraJVM . $ docker images
Application response times
Response times indicate the median response time for each execution. This exercise is not intended to measure the application performance, and the code provided in the repo is not optimized for performance. Instead, the focus is on finding whether native compilation introduces any overhead to the average response times. From the numbers below, it can be seen that the native image is not adding any specific overhead to the overall performance. This test was executed for less than a minute and as Hotspot comes into play, the JDK response times probably would start to more closely match the native response time.
Setup
Vegeta, an HTTP load testing tool, is used to put a load on the application for 60 seconds.
The test used vegeta with the following parameters:
$ echo "GET http://localhost:8080/" | \ ./vegeta attack -duration=60s -rate=200 -keepalive=false | \ tee results.bin | \ ./vegeta report
Everything is running on a laptop with an Intel Core i7 processor and 16GB of RAM. MongoDB is also running locally and no tuning has been performed on any specific parameter.
Conclusion
Serverless architectures can benefit from faster startup times. The configuration demonstrated in this article shows how GraalVM can reduce startup time and Docker image size for Java-based programs.
For your Java applications that are hosted on container platforms such as Red Hat OpenShift, try natively compiling them using GraalVM and its AOTC capability to see how they can benefit from faster Java startup time and a smaller Docker image size.
Last updated: September 10, 2018