Switch to GraalVM — is worth it?

The initial setup 

I have a serverless container built with Java and Micronaut framework. It has one HTTPS endpoint for calculating the loan amortization schedule. 

When there are no requests — the container is down and no resources are consumed. When the request comes the container is initialized. It takes time to start the application, and JVM is not warmed up. These kinds of things really impact the request latency. 

Take a look at the screenshot of the dashboard:


As you can see the request latency is 5-10 seconds. This is a very long time to wait for a user. 

I've been considering different ways to improve this situation — from migrating to a VM instance that will be up all the time, so there will be no time spent to start a container for every request, to switching to another technology.  But since the service is not used much it is a bit overkill to keep the service up all the time. I wanted to save the serverless setup. 

Trying GraalVM

One of the solutions that came into my mind is to build a native image using GraalVM. 
Native image compiles Java code into a native executable. This could help me to speed up my application. But how hard it would be to do, and will it introduce new bugs?

I started with the official guide for Micronaut and GraalVM. 
There are a few steps that need to be done. It didn't take much time. After a couple hours, I put the new build into the environment! 
When I made a few requests I couldn't believe the result I got. This difference in request latency is enormous! 

Look at the dashboard: 


Now the requests take 200-300 ms to complete. 
I think this is a great result. 

I'll test the setup a bit more time, but no bugs were found so far. 

There are more complex projects which now I want to try to migrate to GraalVM, but that might be more difficult. 

The results of the switch are quite interesting — enormous speed up at relatively small costs. 
What do you think? 

Comments

Post a Comment

Popular posts from this blog

The Operation Result Pattern in Java

Image
Introduction Throughout my career as a Java developer, I've frequently implemented a particular pattern across numerous projects. This pattern, known as the operation result pattern , encapsulates the outcome of an operation along with its return object, enhancing code clarity. It distinctly categorizes function call outcomes into success or failure, each requiring appropriate handling by the developer. In contrast, certain languages, such as Kotlin, integrate this pattern within their standard libraries, or like Golang, facilitate the return of additional information to indicate the operation's outcome. Unfortunately, Java lacks such a built-in solution, prompting the need for a standardized approach. Motivated by this gap, I created a library that implements the result pattern in the JResult , a library aimed at brining the operation result pattern in Java applications. Java's Built-in Error Handling Mechanisms Java's conventional approach to managing errors reli...
Read more

Bringing the Operation Result Pattern into Java

Image
Throughout my journey in various Java projects, I've consistently encountered the need to reimplement a specific pattern — one that encapsulates the results of operations without resorting to exceptions, such as during input validation.  This pattern, known as the Operation Result Pattern, may not be universally recognized as a formal design pattern, but in my experience, it's an incredibly useful approach for handling operation outcomes. I thought it would be nice to have it in a form of a simple library that can be easily integrated in the Java projects. After dedicating a few weeks to development, I'm excited to announce the release of the first version of this library, which I've named JResult.  It's designed to be lightweight, easy to use, and flexible enough to accommodate various project needs. You can explore JResult and its documentation on GitHub: https://github.com/ArtyomPanfutov/jresult Stay tuned for updates, and don't hesitate to contribute or reac...
Read more

SQLDelight database class generating problem

Image
Recently, I have been struggling with generating a database class for the SQLDelight schema and couldn't find a relevant answer to my problem. So this post might help someone who faces similar errors. First, I had this nasty error while I tried to generate a class for the database schema with a Gradle task( generateSqlDelightInterface ): Unable to find method ''void kotlin.jvm.internal.FunctionReferenceImpl.<init>(int, java.lang.Class, java.lang.String, java.lang.String, int)'' 'void kotlin.jvm.internal.FunctionReferenceImpl.<init>(int, java.lang.Class, java.lang.String, java.lang.String, int)' The solution was simple - upgrade Gradle Version to 6.8-milestone-2 in Project Structure/Project. It seems there was some bug in the older version. Second, I had a problem with generating the actual class for the schema. This mechanism is pretty cranky to the directories configuration. You have to be watchful and put the schema file to the directory corres...
Read more