Minimizing cold start time (Firecasts)
HTML-код
- Опубликовано: 3 июл 2024
- In this episode of #Firecasts, and the last in this series about Cloud Functions, @codingdoug covers how to minimize your cold start times through cloud functions for Firebase. Learn about how moving as much global code as possible into the functions that actually need it can help you minimize those cold start times, plus much more!
More info here → bit.ly/2O5VjTU
Understanding Cloud Functions for Firebase Playlist → bit.ly/2HYqscw
Firecasts playlist → bit.ly/2LfjL2z
Keep up with the latest from Firebase, subscribe! → bit.ly/2KUciWJ 
Наука
This guy is great at explaining things, reminds me of the "Engineering Guy" RUclips channel
Great video that answered some of my questions. Thanks !
What an amazing series!
Doug is the man
Thank you sir for this video.. 😊
Indeed a very informative series.Thanks Doug! what's next on your list?
Thanks! We're working on a bunch of new materials (documentation, videos, codelab) to help explain Firebase security rules better. It's one of the least well understood Firebase features, but among the most important!
The real issue that's not being addressed is the cold start time needed to initialize functions and admin init. This needs to be improved
Doug great video! Question - I typically like to build my code taking advantage of ES6 Classes (in Typescript of course), but I'm wondering if I would get a better performance boost if I used smaller self-contained javascript functions? Is there a consensus on your team as to the best approach here? Using javascript classes or functions? Or does this not matter in terms of performance as long as you stick to dynamic import (aka: lazy load) convention?
There are lots of examples, including in the Firebase docs, where people are using Express in their functions to serve up an API. Wouldn't including Express add to the overhead and the time it takes to spin up and serve the function? Why not just write minimal functions? Or does Express not increase the cold-start yet offer additional benefits?
This video would be great if the tips mentioned actually had a significant impact. I've done all things mentioned in the video and still get insane cold start times (I'm talking minutes).
Great videos with very important tips ! Thanks
Is there any github or whatever example about how to split index.js in multiple files holding different "trigger" functions ?
Any upcoming updates for Queries and data modeling?
Is there a way to plot the cold start times as metrics?
Now there is a parameter called "minInstances" which can be set to 1 to keep a server running all time.
this cost money though, i think like 1 dollar per month
How I didnt see this before !
`What a nice guy
If f2 needs admin.initializedApp then you use separate property (is_f2_initialized)?
Firebase team please make a tutorial how to use firebase storage along with cloud function for firestore
Ian Jasper Santos there are literally hundreds, including on the official docs, just look
It was not explained explicitly, but I assume, the cold start time is added to the execution time of a function, if it is the first function to be executed on a new instance for the first time. And this is why we want to optimize cold start time.
Just thinking loud: Would it not be an option to prepare a new instance ahead of time, so the global context is loaded, before actual work load is redirected to it for the first time? Then cold start time would have no impact on new instances.
Cold start time generally refers to the time it takes for an event to be received, a new server instance to get fired up, and deliver that event to the function. The running time of the function is not so much the issue, as that will generally be about the same every time (assuming all networking is running smoothly.
Thanks this is helpful..
I've been waiting for this video to be released hoping that there would be new information here. Sadly there wasn't. It seems that Azure and AWS have the leg up in terms of cold start efficiency right now.
The use of a module cache would greatly improve some of these issues. Plus I would rather pay the price to import a module once on cold start than every time the function is executed.
Also, why is the source for functionA bundled with functionB?
Why doesn't firebase support a JSON or even yaml file in place of index.js allowing for proper context segregation?
Additionally, given a larger project using functions that import many local files, there is no clarification about whether bundling these files together would optimize cold start times
The bundling is just how the Firebase CLI chooses to package and deploy functions. You are obliged to create a single module and export all your functions deploy from that module. It ends up being easier and preferable for most of the target audience most of the time. If you would prefer to deploy your functions with zero context shared between them, your choices are:
1. Use gcloud for that instead, where are you obliged to run a command and target a single js for each function individually. Of course, you are giving up all the other conveniences of TypeScript bindings that the firebase-functions module gives you.
2. Create a different Firebase CLI project workspace for each function, and deploy them all individually from each project workspace.
The overhead of having a bunch of functions deployed together is negligible. If you follow the advice here, each function is only paying the cost of the parsing of each other functions' code, without respect to their requires or imports. That's gonna be like 1-2ms total, unless you write gigantic functions, in which case you might want to look into a solution other than Cloud Functions.
Bundling several JS files into one file is not likely to help much. The cost of the parsing would stay the same.
If you have a feature request about how things could be better, please file that.
firebase.google.com/support/contact/bugs-features
Does it really seem? "Seems" like you're making assumptions without actually doing the benchmarks yourself, or looking at other who have:
mikhail.io/serverless/coldstarts/big3/
Visualization of cold starts: mikhail.io/2019/03/visualizing-cold-starts/
Seems Azure is worst currently
Good
If my index.js imports 2 modules (each one represents a cloud function) and each modules has a couple of imports, will all imports, even of sub-modules, get imported when the index.js get loaded? Or is the cloud function compiler wise enough to only import those sub-modules for the required cloud function?
Yes, all of those imports are part of the global scope that you need to minimize in order to optimize the cold start time for all your functions in that deployment. This is not a matter of a compiler being smart. This is just how JavaScript works. This is exactly the situation that this video is suggesting that is good to optimize.
@@dougstevenson3769 I see :/ it feels a bit like it defeats the cloud function idea. I wish each function simply had it's own file, that this would not be an issue. The cli could easily deal with it.
Hello Doug,
I need a suggestion. I want to write all the firebase read and write functions on firebase cloud servers and call http functions from my android and ios app. Is this a bad idea? Some developers suggesting that it will slow my apps. is it true?
Hi Doug, is there a full example of a script using these methods?
I don't know of any offhand. I have some code that I toy around with, and I know others on the Cloud Functions for Firebase team do the same stuff, but there's nothing published.
Is there a way to measure cold start times?
Log a message at the beginning of your function, invoke it, then look at the time differential between that and the informational log item that indicates when the function started, and the time of the log message. This assumes your function has no warm instances at the time of the invocation.
aw last part of the series :(
👍🏽
How much time does the cold start take in general?
It varies between the types of triggers. HTTP tend to be the fastest on the order of less than 100ms. By my observation, Firestore tends to be the slowest, but it varies. The team is always looking to improve cold start times, and believe one major improvement was made very recently.
@@dougstevenson3769 is there a resource anywhere that shows average expected cold start times of each type?
The word LAST makes me sad :(
What are cloud functions
TLDW; Firebase functions are slow. If you don't like it then go use something else
....
too late, i left away from firebase half a year ago just because of this.
my app was using fb cloud functions and got cold start like 1 minute. and it happened over and over since it was not too many people using it. my functions turned to crap and got complaints. now none of my projects are using fb.
Sorry you've had problems. We've never heard of a true cold start taking a full minute. You may have been using the product when it was in beta, and didn't have any SLA or other guarantees. The case you were observing may have just been due to the event being delivered later than expected. It's also important to terminate your functions correctly in all cases, since they will time out in 60 seconds by default if you don't.
Cloud Functions is now fully released and gives strongly guarantees. Improvements have been made overall, and I've not seen a true cold start (as you might see by the invocation time in the function logs) take more than 5 seconds for any sort of trigger.
I do the same, Yeh they haven't improved this much, it's less than 1-min but can still timeout. Best workaround is to schedule a noop call every 30-secs to keep the function image alive
Same here. I was using cloud functions to run a NextJS site and cold start was exactly 1 min.
@@rustapan seems like their work are too overwhelming to fix it until now.. sorry to hear that.
FIIRST