8

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?

sqwerty
  • 1,773
  • 2
  • 14
  • 14
  • I've noticed this too. – camden_kid Jan 16 '18 at 11:32
  • Please show the code of the function. It could just be taking a long time naturally, regardless of any cold start issue. If the function performs any blocking or async work, those delays would be factored into the overall time. – Doug Stevenson Jan 16 '18 at 18:35
  • The function takes 16 seconds on first call and 1 second per call for a while after. This tells me the difference (15 seconds) is roughly the cold start time. This delay is fairly consistent across all endpoints. – sqwerty Jan 18 '18 at 10:36
  • Note - you can only do so much. There is a Severity 1, Priority 1 BUG on cold starts by firebase that has been sitting open for almost 3 years. https://issuetracker.google.com/issues/158014637 They issue an article with tips and tricks and then just go on to say "maybe just don't use cloud functions if you need speed" at the end, effectively. Wish they lead with that in their marketing material. – David Jun 16 '21 at 14:35

2 Answers2

6

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

Matthew Rideout
  • 7,330
  • 2
  • 42
  • 61
  • 1
    Could you elaborate a bit on this? It seems interesting from our side (not for firebase I guess..). So for each function you developed (f1, f2, ...), you create another function (ping_f1, ping_f2, ..) that will be called by the scheduler every minute such that the actual function, when it received the "ping" argument, just read a cloud firestore document and return a 200 status? is this correct & enough to keep your functions "alive"? – Arno Mar 29 '18 at 10:34
  • 1
    At the same time, if you have many functions that could largely increase the number of "document read" which is how the billing procedure for firebase is computed. Let's assume: 100 functions, "pinged" every minute, with 1 document read per ping => that's around 4.320.000 document read per month without actually doing anything EDIT: which is about 2-3$ per month just for the ping... maybe that's not too much in the end of the day – Arno Mar 29 '18 at 10:42
  • 2
    The cost was also a consideration of mine as well, and the pinging cost much less than purchasing a compute engine virtual server and setting up always on resources. I just wish firebase would let you just pay more to keep the functions awake or something. Arno, yes, that's correct. Each separate deployed function has its own "ping" function that can receive an argument and perform a simple operation to keep it warm. It's within the same https trigger, but a conditional query string parameter just activates the ping function. – Matthew Rideout Mar 30 '18 at 19:11
  • @MatthewRideout How do you trigger background function `auth.user().onCreate trigger` or (any bg function) via http ping? Do you create a test user everytime when a certain http function is called? – hkchakladar Dec 18 '18 at 10:12
  • @hkchakladar - yes I had a workflow to create a user, then delete the user. I have found since forcing Node 8 that this whole practice is no longer necessary (warmup times have been greatly improved). I have also moved my time-dependant onCreate methods to a client-side function since I didn't like the logistics of waiting for and continuously checking for onCreate to have finished its processes. – Matthew Rideout Dec 18 '18 at 16:52
  • "However, there is also a new cron method available that may keep them warm more easily." - NOTE that it can only solve for one request. If there is another concurrent request, it is subjected to cold start again! – Ayyappa May 27 '20 at 15:22
0

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.

Zubeyir
  • 11
  • 6
  • 2
    16 seconds seems too long. Also in the link I posted a firebase developer mentions cold starts should not be noticeable. – sqwerty Jan 16 '18 at 18:18