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).
- 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.