<p>All container services and Function-As-a-Service services of the big cloud providers, such as Amazon ECS, Lambda and Azure cloud functions run on actual virtual machines of these providers. Normally they only take a small number of milliseconds to start up, but when your container or function has not run for a certain amount of time, they will take a couple of seconds to actually start up the virtualization environment for your container or function. These startup times improve all the time, but you still get better startup time results by calling your functions or a request in your container in regular intervals.</p>

<p>A typical interval could be every minute, so that you can be sure that the virtual environment the container or function runs on has likely not been shut down, as it just was in use in the past 60 seconds.</p>

<p>In relation to an auto scaling group, I would say that "warm up" is a bit of a mis-nomer. Either there are enough instances provisioned to handle the traffic you expect, or you may need to make a 'scheduled change' to the number of instances, but there is actually nothing to warm the instances up.</p>

<p>One edge-case would be if instances have disk contents restored from backup. On AWS, there is some delay in getting the contents on these disk from snapshot and the disk can be warmed up by reading all blocks on it</p>

CC BY-SA 4.0
2018-10-13T06:13:48.400Z
interesting, merci!
Pierre.Vriens
CC BY-SA 4.0
2018-10-13T04:13:04.130Z
2018-10-13T04:13:04.130Z
jdog
<p>In the Google App Engine PaaS context, standard environment apps using automatic scaling can use warmup requests to keep request latency/response time down even during traffic peaks requiring new instances to be started. From <a href="https://cloud.google.com/appengine/docs/standard/python/how-instances-are-managed#warmup_requests" rel="nofollow noreferrer">Warmup requests</a>:</p>

<blockquote>
  <p>Warmup requests are a specific type of loading request that load
  application code into an instance ahead of time, before any live
  requests are made. Manual or basic scaling instances do not receive an
  <code>/_ah/warmup</code> request.</p>
  
  <p>To learn more about how to use warmup requests, see <a href="https://cloud.google.com/appengine/docs/standard/python/warmup-requests/configuring" rel="nofollow noreferrer">Configuring
  warmup requests</a>.</p>
</blockquote>

<p>Without warmup requests configured instances would be started only in response to actual/live requests which are already routed to the new instance (which isn't yet ready). Meaning that the response time for those requests would be increased with the actual instance startup time. </p>

<p>With warmup requests configured the live requests keep being handled by instances already running while the new instances are being started (by the warmup requests). Only after the new instance is up and running (indicated by successful handling the warmup request) the scheduler will start routing live requests to it.</p>

CC BY-SA 4.0
2018-10-13T06:16:34.310Z
So funny ... yet another concept which seems to be derived from good old big iron, aka mainframe ... merci! Maybe I should start a series of (self answered) questions like "What's the mainframe equivalent of DevOps concept XYZ?" ... possibly [here](https://area51.stackexchange.com/proposals/118484/mainframes?referrer=pEca7qCyNI2pmq-iyVlkZQ2)
Pierre.Vriens
CC BY-SA 4.0
2018-10-13T05:29:20.973Z
2018-10-13T05:29:20.973Z
Dan Cornilescu
<p>There are a few questions that mention something about <strong><em>warm up</em></strong>, such as:</p>

<ul>
<li><p><a href="https://devops.stackexchange.com/q/4851/40">How to filter out system-generated calls in monitoring of Azure Webapps?</a></p>

<blockquote>
  <p>... to keep the container instance/VM <strong><em>warmed up</em></strong>.</p>
</blockquote></li>
<li><p><a href="https://devops.stackexchange.com/q/1269/40">What is the ec2 cli command to modify the minimum number of nodes in a scaling group?</a></p>

<blockquote>
  <p>... to <strong><em>warm up</em></strong> the autoscaling group to run jobs.</p>
</blockquote></li>
</ul>

<p>What is this <strong><em>warm up</em></strong> thing? Is it something similar to "being ready when some request comes in (e.g.  to preload things in memory, to prevent some sort of I/O operations)"? If not what could be a good comparison to explain it to a novice?</p>

CC BY-SA 4.0
2018-10-12T19:24:54.343Z
Don't think they put it into a toaster.. Scnr.. But seriously, containers etc indeed need some time to launch.. And warm up shared infrastructure in return.
Ta Mu
<terminology>
What is warm(ing) up?
Pierre.Vriens
# What is warm(ing) up?

(Asked by: username_0 on 2018-10-12)

There are a few questions that mention something about ***warm up***, such as:

* [How to filter out system-generated calls in monitoring of Azure Webapps?](https://devops.stackexchange.com/q/4851/40)

  > ... to keep the container instance/VM ***warmed up***.
* [What is the ec2 cli command to modify the minimum number of nodes in a scaling group?](https://devops.stackexchange.com/q/1269/40)

  > ... to ***warm up*** the autoscaling group to run jobs.

What is this ***warm up*** thing? Is it something similar to "being ready when some request comes in (e.g. to preload things in memory, to prevent some sort of I/O operations)"? If not what could be a good comparison to explain it to a novice?

**Tags:** terminology

> **Comments:**
> **username_1**: Don't think they put it into a toaster.. Scnr.. But seriously, containers etc indeed need some time to launch.. And warm up shared infrastructure in return.  

---

## 2 answers

### Answer by username_2 on 2018-10-13. Score: 2

All container services and Function-As-a-Service services of the big cloud providers, such as Amazon ECS, Lambda and Azure cloud functions run on actual virtual machines of these providers. Normally they only take a small number of milliseconds to start up, but when your container or function has not run for a certain amount of time, they will take a couple of seconds to actually start up the virtualization environment for your container or function. These startup times improve all the time, but you still get better startup time results by calling your functions or a request in your container in regular intervals.

A typical interval could be every minute, so that you can be sure that the virtual environment the container or function runs on has likely not been shut down, as it just was in use in the past 60 seconds.

In relation to an auto scaling group, I would say that "warm up" is a bit of a mis-nomer. Either there are enough instances provisioned to handle the traffic you expect, or you may need to make a 'scheduled change' to the number of instances, but there is actually nothing to warm the instances up.

One edge-case would be if instances have disk contents restored from backup. On AWS, there is some delay in getting the contents on these disk from snapshot and the disk can be warmed up by reading all blocks on it

> **Comments:**
> **username_0**: interesting, merci!  

---

### Answer by username_3 on 2018-10-13. Score: 2

In the Google App Engine PaaS context, standard environment apps using automatic scaling can use warmup requests to keep request latency/response time down even during traffic peaks requiring new instances to be started. From [Warmup requests](https://cloud.google.com/appengine/docs/standard/python/how-instances-are-managed#warmup_requests):

> Warmup requests are a specific type of loading request that load
> application code into an instance ahead of time, before any live
> requests are made. Manual or basic scaling instances do not receive an
> `/_ah/warmup` request.
>
> To learn more about how to use warmup requests, see [Configuring
> warmup requests](https://cloud.google.com/appengine/docs/standard/python/warmup-requests/configuring).

Without warmup requests configured instances would be started only in response to actual/live requests which are already routed to the new instance (which isn't yet ready). Meaning that the response time for those requests would be increased with the actual instance startup time.

With warmup requests configured the live requests keep being handled by instances already running while the new instances are being started (by the warmup requests). Only after the new instance is up and running (indicated by successful handling the warmup request) the scheduler will start routing live requests to it.

> **Comments:**
> **username_0**: So funny ... yet another concept which seems to be derived from good old big iron, aka mainframe ... merci! Maybe I should start a series of (self answered) questions like "What's the mainframe equivalent of DevOps concept XYZ?" ... possibly [here](https://area51.stackexchange.com/proposals/118484/mainframes?referrer=pEca7qCyNI2pmq-iyVlkZQ2)  

---

