Instances of Lambdas are added and removed dynamically. When a new instance handles its first request it will take a while to boot up. This extra time it takes for a function to execute when it hasn’t recently been invoked is called cold start.
Cold starts can be a killer to Lambda’s performance, especially if you’re developing a customer-facing application that needs to operate in real-time. They can lead to problems like unsatisfied customers and lost sales.
In this post, we are discussing approaches that can help to come over this problem.
Identifying the Problem
The first step to address the areas of inefficiency in your application is monitoring your system. This helps you identify which Lambda cold starts are truly problematic, and which can be safely ignored.
Both CloudWatch Logs and X-Ray can help you to identify where and when cold starts are occurring in your application.
Following is a simple CloudWatch Insights query that you can rely on to determine the average cold start duration of one of your Lambda functions:
filter @type = "REPORT" | stats avg(@initDuration)
In order to determine the hourly frequency in which the cold start occurs you can use the following CloudWatch Insights query:
filter @type = "REPORT" | stats count(@type) as allInvokations, count(@initDuration) as coldStarts, coldStarts/allInvokations as coldStartFrequency by bin(1hour)
Battling the Cold Start
When battling the cold start there are two aspects you should consider:
- minimizing the duration of the cold start.
- minimizing the number of times cold starts occur.
Minimizing the Duration of the Cold Start
Let’s discuss some options for minimizing the cold start duration:
Find and Stop the Bottlenecks:
These are the pieces of code that reduce your service’s speed. They can be anything. For example, you may have trouble accessing a program at a certain time because you’re at peak usage hours.
Choose the right language:
Your choice of the programming language will have an effect on the length of the AWS Lambda cold start times. Python, Node.js, and Go took much less time to initialize than Java or .NET.
Choosing higher memory settings for your functions:
This gives your functions more CPU power, but pay attention that it will increase your Lambda cost.
Get Lambdas out of VPC:
Unless it’s really necessary try to get your Lambdas running outside of your VPC, as they have a huge impact on Lambda cold start times.
Minimizing the Cold Starts Frequency
Lambdas are kept warm for a limited time after being invoked. Warm Lambdas will always give you faster execution times. One thing you can do is to ensure that your Lambdas do not become inactive.
This can be achieved by function warming, which is the act of sending scheduled ping events to your functions to keep them alive and idle, ready to serve requests.
The Serverless Framework has a plugin we can use for this purpose Serverless WarmUp Plugin.
When invoked by WarmUp, lambdas will have the event source
serverless-plugin-warmup so we can use this to add an early return call before our lambda logic when this event source is received.
But sadly, the plugin doesn’t support concurrent function warming.
You can check the Lambda pricing here.
If you want to warm 10 functions, each with
memorySize = 1024 and
duration = 10s every 5 minutes:
WarmUp: runs 8640 times per month.
1 warm lambda cost: 1GB×$0.0000206667×10s×8640 = $1.78560288.
10 warm lambdas: $17.8560288.
There are a variety of ways to reduce the impact of cold starts, but unfortunately, none of them can be relied on to completely solve the problem in every situation.
The best advice is to monitor your application and focus most effort only on the cold starts that have a direct effect on user experience or the smooth running of your application.