3

To minimize cold starts, I've set a minimum instance for my Google Cloud Function. I actually do it with the firebase admin SDK like this:

functions.runWith({ minInstances: 1 })

...but I can see it confirmed in Google Cloud Console:

enter image description here

I'm noticing that after every deployment, I still encounter one cold start. I would have assumed that one instance would be primed and ready for the first request, but that doesn't seem to be the case. For example, here are the logs:

enter image description here

You can see that ~16 hours after deployment, the first request comes in. It's a cold start that takes 8139ms. The next request comes in about another hour later, but there's no cold start and the request takes 556ms, significantly faster than the first request.

So is this the expected behaviour? Do we still encounter one cold start even if minimum instances is set? Should I then be priming the cloud function after every deployment with a dummy request to prevent my users from encountering this first cold start?

Johnny Oshika
  • 54,741
  • 40
  • 181
  • 275

2 Answers2

5

Tl;dr: The first execution of a function that has minimum instances set is not technically a cold start, but probably will be slower than later executions of that instance.

Minimum instances of a function will immediately be "warmed up" on deploy and in a warm but idle state, ready to respond to a request. However, the functions we write often need to do extra setup work when they're actually triggered for the first time.

For example, we may use dynamic imports to pull in a library or need to set up a connection to a remote DB. Even though the function instance is warm, the extra work that has to be done on the first execution means that it will probably be slower than later executions.

The benefit of the minimum instances setting is that later executions benefit from all the setup work done by the first execution, and can be much faster than if they were scaled back to zero and had to set themselves up all over again on the next request.

Update: Occasionally, an idle instance may be killed by the Cloud Functions backend. If this happens, another instance will be spun up immediately to meet the required minimum instances setting, but that new instance will need to go through its extra setup work again the first time it is triggered. However, this really shouldn't happen often.

Jeff
  • 2,425
  • 1
  • 18
  • 43
  • 1
    Thanks @Jeff. Confusing the matter is that there doesn't seem to be a guarantee that the instance remains warm. I had a cloud function that was warm last night but when I tried to hit it this morning, it was another `slow` start. There was no deployment done during this period and the min instances is set to 1. Could it be that it's just an `attempt` to keep warm as @DougStevenson suggests and will still be torn down if there's no traffic? – Johnny Oshika Jan 24 '22 at 17:42
  • One way to check would be to log something in the global scope of your function source (outside of an individual trigger), like `functions.logger.log('First execution of this instance!')`. If the instance is kept warm in between invocations, you should only see that log once. – Jeff Jan 24 '22 at 18:22
  • 2
    I spoke with Cloud Functions engineers and learned that, occasionally, an idle instance may be killed by the Cloud Functions backend. If this happens, another instance will be spun up immediately to meet the required minimum instances setting, but that new instance will need to go through its extra setup work again the first time it is triggered. However, this really shouldn't happen often. Would you be up for filing a support case (https://firebase.google.com/support/troubleshooter/report/bugs) so that engineers can look at your specific project/code and get to the root of this? – Jeff Jan 24 '22 at 20:47
  • 1
    Thanks @Jeff for all that info. I'm going to do some more testing to see if my functions are going to sleep. – Johnny Oshika Jan 29 '22 at 06:16
2

The documentation does not make a hard guarantee about the behavior (emphasis mine):

To minimize the impact of cold starts, Cloud Functions attempts to keep function instances idle for an unspecified amount of time after handling a request.

So, there is an attempt (no guarantee), and it kicks in after a handling a request (not after deployment), but you don't know how long that will last. As stated, it sounds like you might want to make a request, along with the expectation that it might still not always work exactly the way you want.

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
  • That line in the docs is describing the "built-in behavior" (when a minimum number of instances is *not set*). – Jeff Jan 24 '22 at 16:27
  • 1
    @Jeff Could the documentation be updated to be more clear what exactly happens when a function is deployed with min instances set? The docs say how to set min instances, but not the specific effects or variation from the norm. All it does is make a suggestion is that it "can further help you avoid cold starts and reduce application latency", and that you're billed for any idle time. – Doug Stevenson Jan 24 '22 at 17:03
  • 1
    @DougStevenson following what Jeff was saying and answering your question: it would probably be good to have the intended min-instances-set behvaior clarified in the documentation, especially in light of the gen 1 / gen 2 functions I have heard about. – Chris Chiasson Mar 07 '22 at 12:05
  • @DougStevenson Is the moral here that it is impossible to COMPLETELY avoid cold starts using Google Cloud? Or are there Google Cloud hosting options other than Cloud Functions that could be used to COMPLETELY avoid cold starts? I've been researching this for months. Any help would be appreciated. – stevehs17 May 04 '22 at 00:42
  • @DougStevenson And to be clear: what I mean by "COMPLETELY avoiding cold starts" is avoiding any latency that would make function execution take substantially longer than it takes if it is immediately executed a second time after a first execution using the same VM. Thank you so much! – stevehs17 May 04 '22 at 00:45
  • @stevehs17 Pay for any of the 24/7 uptime services, such as Google App Engine or Compute engine. Cold starts are a result of the willingness to scale server instances down to 0 (aka "serverless" produts) in order to save costs. Just get dedicated servers instead, and be willing to manage and maintain them. – Doug Stevenson May 04 '22 at 01:51