Firebase 功能冷启动时间慢

Question

I read here endpoint spin-up is supposed to be transparent, which I assume means cold start times should not differ from regular execution times. Is this still the case? We are getting extremely slow and unusable cold start times - around 16 seconds - across all endpoints.

Cold start: Function execution took 16172 ms, finished with status code: 200 After: Function execution took 1002 ms, finished with status code: 304

Is this expected behaviour and what could be causing it?

Answer 1

UPDATE: The cold start times seem to no longer be an issue with node 8, at least for me. I'll leave my answer below for any individuals curious about keeping their functions warm with a cron task via App Engine. However, there is also a new cron method available that may keep them warm more easily. See the firebase blog for more details about cron and Firebase .

---

My cold start times have been ridiculous, to the point where the browser will timeout waiting for a request. (like if it's waiting for a Firestore API to complete).

Example A function that creates a new user account ( auth.user().onCreate trigger ), then sets up a user profile in firestore.

• First Start After Deploy : consistently between 30 and 60 seconds, frequently gives me a "connection error" on the first try when cold (this is after waiting several seconds once Firebase CLI says "Deploy Complete!"
• Cold Start : 10 - 20 seconds
• When Warm : All of this completes in approximately 400ms.

As you can imagine, not many users will sit around waiting more than a few seconds for an account to be setup. I can't just let this happen in the background either, because it's part of an application process that needs a profile setup to store input data.

My solution was to add "ping" function to all of my API's, and create a cron-like scheduler task to ping each of my functions every minute, using app engine.

Ensure the ping function does something, like access a firestore document, or setup a new user account, and not just respond to the http request.

See this tutorial for app engine scheduling: https://cloud.google.com/appengine/docs/flexible/nodejs/scheduling-jobs-with-cron-yaml

Answer 2

Well it is about resource usage of Cloud Functions I guess, I was there too. While your functions are idle, Cloud Functions also releases its resources, at first call it reassignes those resources and at second call you are fine. I cannot say it is good or not, but that is the case.

Answer 3

if you try to return a value from an async function there won't be any variables in the main function definition (functions.https.onCall) and GCP will think that the function has finished and try to remove resources from it.

Previous breaking code (taking 16 + seconds):

functions.https.onCall((data, context) => {
  return asyncFunction()
});

After returning a promise in the function definition the function times are a lot faster (milliseconds) as the function waits for the promise to resolve before removing resources.

functions.https.onCall((data, context) => {
  return new Promise((resolve) => {
    asyncFunction()
        .then((message) => {
          resolve(message);
        }).catch((error) => {
          resolve(error);
        });
  });
});