Serverless is a crucial component in cloud computing.

Due to its flexibility and cost-effectiveness, it has become a favorite among developers. However, Serverless is not a perfect silver bullet, and when discussing Serverless, one cannot avoid the topic of cold starts.

What is Cold Start?

When a Serverless function is triggered, the cloud platform needs to allocate resources, start the runtime environment, and load necessary dependencies because there is no pre-existing environment. This process can cause significant delays, affecting the function’s response time. This phenomenon is known as the cold start problem.

In contrast, a warm start occurs when the function is already in a pre-warmed state, allowing it to execute immediately without the need to recreate the environment or allocate resources.

Why is the Cold Start Problem Unavoidable?

The cold start problem stems from the core characteristics of Serverless computing: on-demand resource allocation and highly elastic scaling capabilities. These very traits lead to the cold start problem.

In simple terms, the delay caused by cold starts primarily arises from the following factors:

On-Demand Resource Allocation

Unlike traditional server models, Serverless functions do not run continuously on fixed servers, but instead start the appropriate runtime environment when a request comes in. As a result, the cloud service provider must dynamically allocate computing resources (such as CPU, memory, and storage) for the function when it is called.

This process involves multiple steps, including provisioning computing resources, loading the operating system, and configuring the network environment, each of which takes time.

Runtime Environment Initialization

Serverless functions run in managed environments, usually containers or virtual machines. When a function is invoked, the cloud platform needs to initialize these environments, including starting the operating system, loading the runtime (e.g., JVM for Java, V8 engine for Node.js), and setting environment variables.

Different programming languages and runtimes have varying initialization requirements. For instance, the Java runtime requires starting the virtual machine and loading libraries, which usually takes more time. In contrast, scripting languages like Python and Node.js have lighter runtimes with fewer initialization steps, resulting in faster startups.

File Loading

When a Serverless function starts, it needs to load various files, such as Docker images and function dependencies (e.g., third-party libraries, SDKs). For complex functions, the number of files and dependencies to load can be quite large, which increases the loading time.

Security Initialization

In a multi-tenant cloud environment, security is a critical concern. Before the function starts, the cloud service provider typically needs to perform a series of security checks and configurations, such as obtaining and verifying security credentials and setting security group rules. These security-related initialization steps can also add to the cold start time.

Network Speed and Latency

The cloud service provider’s infrastructure may be distributed across different regions globally, and network latency between these regions can affect the speed of resource allocation and initialization. Additionally, the function’s code is usually stored in remote object storage systems, and the speed of retrieving this data can impact the cold start time.

The Conflict Between Cold Starts and Pay-as-You-Go

One of the core advantages of Serverless is its Pay-as-you-go billing model, where users only pay for the actual execution time of the function.

To achieve this, cloud service providers reduce the actual running cost of the function by allocating resources on demand, which in turn leads to the cold start problem.

The increase in cold start time not only affects user experience but can also impact business operations. Reducing cold start time without increasing costs has become a key focus in Serverless computing.

How to Optimize Cold Start Times

Based on the sources of cold start problems mentioned above, we can optimize cold start times from the following perspectives:

Choose the Right Programming Language

Different languages/runtimes have vastly different cold start performances. According to Bilgic’s case study, Java has the longest cold start time, being 7x slower than the second slowest one, .NET.

Choosing runtimes with faster startup times, such as Node.js or Python, can help reduce cold start latency.

Simplify Functions and Their Dependencies

According to Lumigo’s case study, the size of the package has a significant impact on cold start time.

Simplifying function code and reducing dependencies can effectively speed up startup time by minimizing the amount of content that needs to be loaded during initialization.

Invoke Functions Regularly

Regularly invoking functions (e.g., pinging the function’s HTTP endpoint) to keep them in a warm state can reduce the frequency of cold starts.

Maintain a Certain Number of Instances

Some cloud service providers offer configurations that can enforce a certain number of function instances to remain pre-warmed, reducing the occurrence of cold starts.

For example, AWS Lambda’s Provisioned Concurrency and Google Cloud Run’s Min Instances. However, this might incur additional costs.

Increase Memory Allocation

Increasing a function’s memory allocation can provide it with more computing resources, speeding up machine processing during cold starts.

Fun fact: increasing memory allocation might actually save money.

Try Leapcell

Tired of manually optimizing cold start times?

Leapcell automatically optimizes cold start times through special strategies, regardless of the language or size of the project, aiming to provide the best possible cold start experience. At the same time, it continues to bill accurately to the second, ensuring no money is wasted.

Click here to try Leapcell. All features are currently available for FREE!