What is Cold Start?

In the context of serverless computing, a “cold start” refers to the first-time latency or the time it takes for a function to begin processing after it has not been called in a long time.  To illustrate, when a computer is turned on after being shut down, it may need some time to reach its full performance.

Cold starts are fundamental to anyone who is starting with serverless architectures. It influences your application’s performance and usability, especially concerning interactions where timeout durations must be met in the shortest time possible.

Cold starts occur under the following circumstances.

• First Invocation: It has two cases; the first is when a function is called for the initial time after the deployment of the applications or after the update of code.
• Scaling from Zero: When a function expands from having no occurrences and receives calls after a while of non-operation.
• Resource Reallocation: When the cloud provider reallocates resources or the function’s base changes to other hosts, it may lead to cold function instances.
• Timeout or Expiration: If a function instance is at max execution time or has exceeded its idle time, it can be terminated, meaning that if it is invoked again, it will start fresh.

A primary challenge associated with cold starts is the additional latency. This latency can be observed in the form of:

• Delayed Responses: While your app generally provides prompt replies, users may occasionally encounter delays that could affect their experience.
•  Reduced Throughput: Cold starts might necessitate a gradual increase in your application’s ability to handle concurrent requests, especially during periods of heavy usage.
• Performance Variances: The degree to which cold start durations change over time may influence application effectiveness, posing possibilities for both streamlining response times and solidifying constancy.

The duration of a Lambda cold start can vary depending on different factors, such as:

• Function Size and Dependencies: The larger the function is, the more dependencies are involved and the longer the typical cold start takes.
• Runtime Environment: The initial runtime environment selected (for example, Node.js, Python, Java, etc.) necessarily determines a factor such as cold start time because of the differences in the initialization and loading processes.
• Cloud Provider Optimizations: Over time, cloud providers consistently provide optimizations to reduce cold start time as much as possible; however, it isn’t fixed or predictable.

Overall, Lambda’s cold starts can vary between half a second and a few seconds. Thus, to get accurate data and to observe how cold start durations reflect the needs of your functions and environment to gain accurate insights.

Here are some ways you can reduce or at least deal with Lambda’s cold starts:

• Function Optimization:
  • Delete unused code and dependencies to reduce the function size.
  • Tree-shaking or code-splitting methods should be used to reduce the amount of loaded code during initialization.
  • Improve package distribution and package dependency resolved workflows.

• Provisioned Concurrency:

Configure provisioned concurrency to maintain the specific number of function instances active so that the incoming requests do not cause a cold start for those instances.

• Warm-up Requests:

Sometimes, you need to send some dummy requests to your functions so that they are warmed up when the real user requests arrive.

• Asynchronous Processing:

For non-critical operations, it may be better to refactor user requests from functions by introducing other asynchronous patterns so that cold starts have minimal effect.

• Buforowanie:

Introduce appropriate caching mechanisms that store frequently accessed data or pre-computed results to reduce the number of function invocations and thus decrease the occurrences of cold starts.