Lambda is a Serverless platform that runs on top of AWS Cloud infrastructure, a Function as a Service (FaaS) that allows developers to keep their focus on what they have to build, the entry point is a single function called handler which runs their source codes depending on certain events.
At the moment, the execution of the code encounters a problem referred to as cold start that adds a latency on top of certain executions which this article intends to improve by using one of the latest AWS updates, the SnapStart option.
The YouTube Channels in both English (En) and French (Fr) are now accessible, feel free to subscribe by clicking here.
SnapStart is a performance optimization option that helps to reduce the initialization time of Lambda functions at no additional costs.
It allows this by creating snapshots of functions at version publishing time and then simply starting these up without having to go through the whole usual initialization process, those cached snapshots are deleted after 14 days of inactivity.
For now, the SnapStart option is launched and available for the Java (11) runtime (Coretto) in the following regions: US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland, Stockholm).
OK! Let’s highlight the power of SnapStart by exemplifying using Java programming language with a Spring-Boot-powered demo available on GitHub.
For that, we will invoke a version of our function without SnapStart and another with SnapStart and see the stats. Of course, the function in question will be powered by Java (11) runtime.
SAM is used to build and deploy the function with simple commands like:
- sam build
- sam deploy –guided: once deployed, it prints the API endpoint in the console that you can use for testing either on your browser or with curl.
More technical information is provided in the README file of the project.
First, let’s highlight the execution of our function with SnapStart disabled, we have pieces of information related to the duration of our function:
To get the cold start duration, we will refer to the Init Duration. This means that in this first execution, we have approximately 9s of initialization time.
Next, with SnapStart enabled the restoration occurs. For this scenario, in the template.yml file, we added that option then we rebuilt and redeployed it to publish a fresh version of the function since SnapStart creates snapshots on published versions as per the screenshot below:
Therefore, the execution summary looks like the following:
We have instead the Restore Duration in place of Init Duration, SnapStart has reduced the cold start duration by 95%, from 9s to 395 ms ✅.
We have just started our journey to build a network of professionals to grow even more our free knowledge-sharing community that will give you a chance to learn interesting things about topics like cloud computing, software development, and software architectures while keeping the door open to more opportunities.
Does this speak to you? If YES, feel free to Join our Discord Server to stay in touch with the community and be part of independently organized events.
In summary, SnapStart brings a benefit to our function during the first executions, even if it happens a few times it’s still worth it.
The project source that we used is hosted on Github, Insofar as you want to make your own tests.