{"id":3062,"date":"2018-02-07T00:00:00","date_gmt":"2018-02-07T08:00:00","guid":{"rendered":"https:\/\/azure.microsoft.com\/blog\/understanding-serverless-cold-start"},"modified":"2025-06-27T08:21:55","modified_gmt":"2025-06-27T15:21:55","slug":"understanding-serverless-cold-start","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/understanding-serverless-cold-start\/","title":{"rendered":"Understanding serverless cold start"},"content":{"rendered":"\n

Update June 2019: <\/strong>Cold start mitigations for dynamic scaling functions are now available in the Premium plan. Read more here<\/a>.<\/p>\n\n\n\n

Cold start is a large discussion point for serverless architectures and is a point of ambiguity for many users of Azure Functions. The goal of this post is to help you understand what cold start is, why it happens, and how you can architect your solutions around it. To provide this explanation, we\u2019ll be going deep into some technical details of how Azure Functions works behind the scenes.<\/p>\n\n\n\n

Consumption plan vs. dedicated plan<\/h2>\n\n\n\n

Azure Functions comes in two main flavors, consumption and dedicated. The difference between the two is important, choosing one over the other not only dictates the behavior of your application but also how you\u2019re billed. The consumption plan is our \u201cserverless\u201d model, your code reacts to events, effectively scales out to meet whatever load you\u2019re seeing, scales down when code isn\u2019t running, and you\u2019re billed only for what you use. Plus, all of this happens without you thinking about what Microsoft Azure is doing behind the scenes. The dedicated plan on the other hand, involves renting control of a virtual machine. This control means you can do whatever you like on that machine. It\u2019s always available and might make more sense financially if you have a function which needs to run 24\/7. If you\u2019re curious and want a more detailed explanation, check out our documentation<\/a>.<\/p>\n\n\n\n

What is cold start?<\/h2>\n\n\n\n

Broadly speaking, cold start is a term used to describe the phenomenon that applications which haven\u2019t been used take longer to start up. In the context of Azure Functions, latency is the total time a user must wait for their function. From when an event happens to start up a function until that function completes responding to the event. So more precisely, a cold start is an increase in latency for Functions which haven\u2019t been called recently. When using Azure Functions in the dedicated plan, the Functions host is always running, which means that cold start isn\u2019t really an issue. So, our scope is narrowed to Functions running the serverless consumption model. Let\u2019s go deeper.<\/p>\n\n\n\n

What happens when I write a function?<\/h2>\n\n\n\n

Suppose you\u2019re writing your first function. You\u2019ve provisioned a function app, created your function based on one of our templates, and are modifying it to fit your business needs. You save, and now wait for your specified trigger to initiate your function. Later, your function triggers. When this process begins, since you haven\u2019t yet executed anything, all your code and config exist only as files in Azure Storage. Let\u2019s pause and think through broadly what still needs to happen for your code to run:<\/p>\n\n\n\n

    \n

  1. Azure must allocate your application to a server with capacity.<\/p><\/li>\n\n\n\n

  2. The Functions runtime must then start up on that server.<\/p><\/li>\n\n\n\n

  3. Your code then needs to execute.<\/p><\/li>\n<\/ol>\n\n\n\n

    Steps 1 and 2, if done unintelligently can take a while, spinning up and configuring a server takes time. To make this experience better for users, instead of starting from scratch every time, we\u2019ve implemented a way to keep a pool of servers warm and draw workers from that pool. What this means is that at any point in time there are idle workers that have been preconfigured with the Functions runtime up and running. Making these \u201cpre-warmed sites\u201d happen has given us measurable \u202fimprovements on our cold start times. Things are now on the order of three to four times faster. Now, let\u2019s go back and walk through a more detailed view of what happens when you trigger the execution of a function when resources haven\u2019t yet been allocated.<\/p>\n\n\n\n

    What happens during a cold start<\/h2>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
      \n

    1. 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.<\/p><\/li>\n\n\n\n

    2. 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:\n