Cloud Functions - Minimum Instances

[Martin Dufort]

Is this property only available for 2nd Gen Cloud Functions. 

I have modified the Minimum Instances value to be 1 for a 1st Gen function.

Save and deploy the new configuration with no error.  

However, looking at the Active Instances graph, it still shows 0 instances running. 

[George (Cloud Platform Support)]

Hello, 

You are right, only second generation Cloud Functions enjoy this feature: to be able to set the minimum instances parameter at deploy time. 

[Martin Dufort]

Ok thanks.

So what's the best way to migrate a 1st gen cloud function to a 2nd gen function using the gcloud cli command line ?

[David Charles Martinez]

Hello. Second generation Cloud Function is still in Preview state. At this time, the best way would be to deploy a new function as second generation.

[Steven Simon]

Hi,

I have tried to do what was suggested. I have deployed my Python HTTP function to Google Cloud as a Gen2 function. I have set the minimum number of instances to 1 (I did that in my deploy script, and the minimum number of 1 shows up under Autoscaling in the Google Console). However, the "Active instances" graph still shows that the number of instances is frequently 0.

What am I doing wrong?

Thank you in advance for your help.

[Steven Simon]

I have determined that there is no possible way to do what we need with Google Cloud Functions -- setting minimum number of instances to 1 may make cold starts less frequent or reduce how long they take, but doesn't eliminate long start-up times, which is the only acceptable option for our user-facing app. (See, for instance, https://issuetracker.google.com/issues/158014637.) Therefore, I am now researching Cloud Run, Compute Engine, and AWS Lambda functions.

[Martin Dufort]

Thanks for pointing me to the Issue Tracker about cold startup times. 

Seems using 1GB instances partly solves the issue but most comments are stating they are moving to Cloud Run. 

Thing is even with 10 minimum instances, a large set of concurrent CF requests would surely move it above 10 and then the cold start issue persists. 

[Tracy Hall]

I'll have to pull up my past Google Firebase contacts - because it seems what we *really* want is NOT a minimum # of instances - but a minimum # of EXTRA instances MORE THAN ARE CURRENTLY RUNNING.

So with minimumExtra=1

If no function is currently running - one "extra" instance is kept warm for a total of 1 instance

if one function is currently running -  one "extra" instance is kept warm for a total of 2 instances

if 10 functions are currently running -  one "extra" instance is kept warm for a total of 11 instances

The goal is not "at least one is warm" - the goal is "at least one is warm and NOT BEING USED" to be ready to pick up the NEXT invocation.

Should be settable from 1 to "n" depending on your systems burst levels, etc.

Tracy Hall

LeadDreamer

[Steven Simon]

There is a further issue: using an instance that is warm. For instance, I can warm up an instance by sending a request, and then send a second request which is sent to a different instance even though there is another one that is warm. That's why keeping an instance warm by pinging doesn't work.

[Tracy Hall]

That depends on your timing.  If you send your second request before the first instance has started, then you have to create a second instance to respond.  Hence the concept of keeping *at least* one more ("extra") warm than you expect to see in bursts.  If you're looking to work with hundreds of requests faster than your instances, even "warm", could respond, then you're looking at an entirely different problem.

Tracy Hall

LeadDreamer

[Steven Simon]

What I saw was that sending a second request after a first request had completed still did not guarantee that the warm instance would be used. It appears that Google Cloud will sometimes start up a new instance in response to a request even if there is an available warm instance.