AWS Lambda GraalVM native: Quarkus vs plain Java
I prefer to use plain Java code for GraalVM native AWS Lambda but my colleagues often ask me why I don’t consider some framework for this.
My first point is that our AWS Lamda code should be simple enough to write without frameworks also I had some concerns about the performance because frameworks are not free and it may increase the cold start time for AWS Lambda.
In this article, we will try to understand if Quarkus framework reduce the perfromance in comparing wit plain Java code + GraalVM native
I selected Quarkus because it’s the most popular and mature Framework for GraalVM native runtime.
We are going to test API-Gateway -> AWS Lambda->DynamoDb flow.
We will test only POST endpoint which will save the book into the DynamoDb table in the known AWS region(us-east-1).
Metrics:
- Native image compilation time and artifacts size
- Start-up/cold start time for 128,256,512 mb setup
- Warm-up execution time for 128,256,512 mb setup
Quarkus and plain java lambdas are using the same dispatcher with a common code. For Dynamodb is used AWS SKD v2 and Apache HTTP client(because in the warm state url-connection client is too slow and Netty client increases cold start)
GraalVM native version is the same in both versions java11–22
All code as usual you can see in my GitHub
Build time comparison
The Git repo has GitHub actions that perform all CI/CD stuff and post-deployment test call. It means for Native image compilation time we just can to check GitHub Actions log.
Cold start comparison
In GitHub action log we see almost the same: Quarkus is slower than plain Java: 1.2s vs 1.9s
Warm state comparison
Summary
To be honest, I’m a bit surprised. I didn’t expect that cold start with Quarkus about 60% slower than without any framework. The same for the warm state, for some reason Quarkus takes in average 130ms, but plain Java + GraalVM take only 14ms.
Here is the bug, that I reported to Quarkus to check this performance issue.
