Intro
In this article on Medium I explored a simple set of steps that we can use to deploy our Java code as AWS lambda function using GraalVM native image. As I mentioned in that article I am excited about all the new features Java is now receiving and was thinking whether it’s already the right time for me to switch Java as a default language for AWS Lambda. Previously the response to such question was - there are much faster languages for Lambdas, because Java was notorious for its long cold start. GraalVM Native Image allows us to resolve this issue by building a native image that does not need JVM to execute java code. So I was curious how short would be the cold start could be in such cases:
- using simple java code in JVM runtime in AWS Lambda
- using java code packaged as a Docker container
- using java code packaged as Native Image produced by GraalVm
Let’s dive into the numbers and see how GraalVM impacts cold start performance.
Prerequisite
All lambdas used in this article are:
- use java 17
- created by
SAM CLI - measurements are based on response time provided by Postman
- code is pretty simple and does the same stuff
Statistics itself as a conclusion
I have conducted a series of experiments and noted those response times:
And here is char to visualise this statistics:
As you can see on the chart lambda that uses Native Image has approximately 2,8 times shorter response time, which is already a great improvement and gives hope for Java to become more attractive option for serverless solutions from now on.
