AWS Lambda SnapStart is a new feature which helps reduce the startup latency for lambda functions running on Amazon Corretto Java 11 runtime. This helps reduce the cold starts that often come when lambdas are required to download reference data from S3 or initialize a framework such as Java Spring Boot.
Our findings indicate that ColdStart Lambda times can be reduced by over 92% and run 13 — 15 times faster!
AWS Lambda SnapStart
How it works
When SnapStart is enabled, function code is initialized once when a function version is published. Lambda takes a snapshot of memory and disk state of the initialized execution environment and this snapshot is cached. This snapshot is implemented with a Firecracker MicroVM Snapshot . When a lambda is first invoked or subsequently scaled Lambda resumes new execution environments from this persisted snapshot instead of initializing from scratch.
In our demonstration we will deploy a Serverless Spring Boot 2 project to our AWS environment with the code located at https://github.com/awslabs/aws-serverless-java-container/tree/main/samples/springboot2/pet-store
We will first deploy the function url with our “sam deploy –guided command”
We are provided an endpoint for testing out SnapStart which can be tested out. For our example, we are going to test out how SnapStart can improve a Lambda that is exposed via a Function Url (released in April 2022). Function Urls are a simpler way to expose a Lambda rather than including other services such as API Gateway.
We create a Function Url for this Lambda within the console
We can just test it out the Function url(ensure that the /pets is added to the url) and you should see the following:
Establishing non-SnapStart performance baseline
Now we want to establish a baseline of how cold starts and warm starts perform for this function url. For our demonstration we will use Apache Bench to load test 1000 requests with 50 concurrent clients to simulate a relatively high load.
We then verify the cold start and warm start baseline in CloudWatch Logs Insights.
When we look at the initial results we see that for 99.9% of the cold starts they are within 6.99717 seconds and warm starts are within 33.1569 milliseconds. For 50% of the cold starts are within 6.57769 seconds and warm starts are completed within 3.3481 milliseconds. This is our baseline before enabling SnapStart.
Enabling SnapStart for the Lambda function
We can then enable SnapStart for function urls within the console by
(a) Configuring the Lambda for SnapStart
(b) Publish a new version of the Lambda with SnapStart enabled
(c ) Create a new Alias based off of this new Lambda version
(d) Create a new Function URL based off of this Alias
(e) Confirm that this new Function URL works as we tested previously (not forgetting the /pets)
Verifying SnapStart performance enhancements
We then can remove our existing CloudWatch Log Groups and perform our load test(1000 requests with 50 concurrent clients) again.
We then collect the findings for this in CloudWatch Log Insights as was done previously.
When we look at the initial results we see that for 99.9% of the cold starts they are within 0.5243 seconds and warm starts are within 32.4033 milliseconds. For 50% of the cold starts are within 0.41532 seconds and warm starts are completed within 3.5373 seconds. We now can compare the results to assess the benefits of enabling the SnapStart feature on Lambdas.
Reviewing the findings
First of all we can see a great benefit when we compare the cold start times. 99.9% of lambda invocations without SnapStart are completed within 6.99717 seconds. When SnapStart is enabled, this number drops to 0.5243 seconds! This means that SnapStart Cold Start times ran 13.15 times faster! This means that the SnapStart Cold Start times decreased by 92.507%.
Looking at Cold Start times for 50% of the lambda invocations(p50) we see that the invocation times drop from 6.57769 seconds to .41532 seconds which means that it ran 15.84 times and that the SnapStart Cold times were decreased by 93.69%
Warm Start times remain similar in performance. When comparing 99.9% of the invocation times, we see that performance went from 33.1569 milliseconds to 32.4033 milliseconds. This is a very slight improvement of being 1.023 times faster or 2.27% faster. When comparing some of the other statistical bands such as p50, p90, etc. the results are a little mixed but more or less statistically the same.
The main finding here is that SnapStart improves Cold Start performance by executing 13–15 times faster!
As stated earlier, SnapStart will greatly improve Lambda cold start performance for those lambdas which have longer Cold Start invocation times.
Some additional testing was done on some Lambdas that had smaller Cold Start times(less than a second) and performance remained similar. This can also be seen when looking at SnapStart for warm starts. This means you should be able to apply SnapStart across all of your Lambdas rather than targeting certain Lambdas for SnapStart.
This demonstration has illustrated the performance and cost benefits that lie in the use of the newly released SnapStart feature for Lambdas.
This should lead to significant savings and performance improvements for Lambdas in the AWS environment. Do not hesitate to reach out to us at Xerris.com for more information about your organization’s needs.