Cold Start Optimization Practices

The serverless architecture features pay-per-use, auto scaling, and complexity shielding, making it a new paradigm of next-generation cloud computing. However, in real-time scenarios, cold start poses a significant challenge. When building web services with serverless, if the cold start and initialization time exceed 5 seconds, it can greatly impact user experience. Therefore, accelerating cold start and improving the user experience is a pressing issue when constructing serverless architectures.

The lifecycle of a serverless instance consists of three phases:

Initialization: FunctionGraph attempts to reuse a previous execution environment, or if none is available, it creates resources, downloads function code, initializes extensions and runtime, and runs initialization code (non-main program code).
Execution: In this phase, the instance starts to execute the function after receiving an event, and waits for the next event after the function completes.
Shutdown: This phase starts if the function does not receive any calls within a period of time. In this phase, FunctionGraph closes the runtime, then sends a shutdown event to each extension, and deletes the environment.

When FunctionGraph is triggered, if no activated function instance is available, the function code is downloaded and an execution environment is created. The period from the time when a function is triggered to the time when a new FunctionGraph environment is created is called cold start. In the serverless architecture, the cold start cannot be avoided.

Currently, FunctionGraph has optimized the cold start on the system side. For details about the cold start on the user side, see the following solutions.

Memory

Given a fixed level of request concurrency, higher function memory leads to better cold start performance with more CPU resources allocated.

Cold Start with Snapshot

Cold start is quite prominent in Java applications. Huawei Cloud FunctionGraph has proposed a process snapshot–based cold start acceleration solution, which helps you break through the performance bottleneck while involving zero or few code changes. In this solution, the execution environment is restored from a snapshot captured after initialization, avoiding complex framework startup and service initialization. The startup latency of Java applications is significantly reduced, and the performance is improved by over 90%.

You can use a Java function to enable snapshot-based cold start. For details, see Configuring Snapshot-based Cold Start. FunctionGraph executes the initialization code of the function, captures a snapshot of the initialization context, and then caches the snapshot after encryption. When the function is invoked and a cold start is triggered for scale-out, the execution environment is restored from the snapshot instead of an initialization process.

Code Simplification and Image Downsizing

FunctionGraph downloads function code during cold start, but larger code packages or custom images can prolong download and cold start time. Optimize your application by removing unnecessary code (using commands like npm prune in Node.js and autoflake in Python) and third-party library dependencies (test case source code, useless binary files, and data files) to speed up the download and decompression process.

Public Dependencies

When developing applications, especially in Python, third-party libraries are often included. Large dependencies can slow down cold start as they need to be downloaded. FunctionGraph offers both public and private dependency modes. Public dependencies are recommended because they are pre-downloaded to execution nodes to save time.

Warming

When an event triggers a function, if a function instance in an active state can be called, cold start can be avoided, and a response time can be reduced. You can use either of the following warming methods: