Serverless Cold Starts
Serverless Cold Starts
A potential issue with serverless computing can be the latency before an application responds if it has been unloaded from memory (or on first use).
For example, in the case of Azure functions running on the consumption plan, Microsoft document in Understanding serverless cold start that the process is:
- Azure allocates a preconfigured server from the pool of warm workers to your app. This server already has the Functions runtime running on it, but it is unspecialized.
- This worker becomes specialized by configuring the Functions runtime in ways that are specific to your app. A few things happen to do this specialization, including: - The Azure Functions infrastructure mounts your Azure Files content to the worker you’ve been assigned - App settings specific to your function app are applied to the worker
- The Functions runtime resets, and any required extensions are loaded onto the worker. To figure out which extensions to load, the runtime reads the function.json files of any function in the function app. For instance, this happens if you’re using Durable Functions, or if you have input or output bindings.
- The Functions themselves are loaded into memory by language providers. This will take a varying amount of time based on the size of your application.
- Your code runs.