So according to the Google Cloud docs:
Max inactivity time for background functions = 30 days
The maximum amount of time that a background function can be kept without any invocation. Functions that are not invoked even once during this time may enter a state in which new events will not trigger them anymore. If this happens, such functions have to be redeployed to start working again. Note: This inactive state is not reflected in the UI, CLI, or API in any way.
I have an application with close to 40 cloud functions and there doesn't seem to be an easy way for me to tell if a function is close to becoming inactive so I know to take action before it happens and I really don't want to filter through the logs in the console with each function every week to see when each was invoked last.
Outside of just doing a redeploy of my functions every month to insure they are fresh is there anyway to easily tell when a function is becoming stale in case it does happen so I only have to deploy said function before it becomes stale?
Also, for any firebase'r that might read this, is there any solutions possibly coming to this in the future?
Thanks in advance.
Sorry, there's no way to tell where your function is during its 30 day idle expiration. The good news is that the Cloud Functions team is working on removing this limitation, but there's no public timeline for that.
EDIT: This problem is resolved now for all newly deployed functions.
Related
When some information is stored in the firestore, each document is storing some specific time in the future, and according to that time, the event should occur in the user's app.
The first way I could find was the Cloud Function pub sub scheduler. However, I could not use this because the time is fixed.
The second method was to use Cloud Function + Cloud Task. I have referenced this.
https://medium.com/firebase-developers/how-to-schedule-a-cloud-function-to-run-in-the-future-in-order-to-build-a-firestore-document-ttl-754f9bf3214a
This perfectly performed the function I really wanted, but there was a fatal drawback in the Cloud Task, because I could only save the event within 30 days. In other words, future time exceeding 30 days did not apply to this.
I want this event to be saved over the long term. And I want it to be somewhat smooth for large traffic.
I`m using Flutter/Firebase, how to implement this requirements above?
thank you for reading happy new year
You could check in the function that gets activated on document creation if the task is due in more than 30 days, and if so, store it somewhere else (maybe another document). Then have another process that checks if the task is now within the 30 days range and then have it do the same as the newly created ones. This second process could be run every week or two weeks.
Apparently some of onCreate/onDelete events our cloud function is triggered by are received more than once!
We've observed them arriving even 3 times a few seconds apart from each other spread between instances of the cloud function. Is it a normal behavior or there is something we've been doing wrong?
Have a look at the content of this "Firebase Google Group" post, that I paste below. It was written in August 2018 but is still fully valid at the time of writing this "copy/paste answer".
Cloud Functions typically
guarantees that your functions are run "at least once", meaning that
it's very possible (but typically rare) that an event may get
delivered to your function more than once. To deal with this, your
functions should be "idempotent", meaning that the receipt of the same
event multiple times should result in no further changes to whatever
it is you need to update. This can be kind of challenging, but it's
one of the properties of serverless systems that needs to be dealt
with, if it's problematic for your app.
https://cloud.google.com/functions/docs/bestpractices/tips#write_idempotent_functions
Hi have 100+ cloud functions and a completed app, control panel and marketing website. When testing, my client said that the site was slow. This was because of the cold start times on all these functions.
I’m not really interested in having a cron job that hits each function every minute as there are a lot, and as other posts suggest, they are not always going to work.
Last night I had an idea. I know it is slightly gross, but I want to know what the consequences (other than not being able to release individual functions) would be of having a single cloud function end point, that switches a parameter with the function name, that then calls the other local functions that are imported. This would mean that the single function would be slow the first time for some users, but then every other function would be fast, as the function would already be warm.
Unfortunately I need to do one of the above to improve performance until firebase release a feature like aws to allow paying to keep functions warm.
It's not possible to entirely eliminate cold start times. They will always exist in serverless environments - that's a matter of fact. The best you can do is organize your code to minimize the cold start times. Without seeing all your code and your specific benchmarks, there is no specific advice we can geive.
The only thing that's in your control is to make sure that each function only loads the minimum amount of code at the global scope to run correctly. So, if your functions all load some code at the global scope that's unused, all those functions will pay an unnecessary cold start cost to load and run the code they don't use.
There are resources out there that will help you do that. Watch this video for more detail.
I tried a couple of my trigger functions as https.onCall and called them after promise return and so far they work really well and faster than the triggers.
What's the catch? Are they also affected by the cold starts too?
If not, then unless it's cron job or lack of support of app language, why should anyone use use a trigger function at all?
All Cloud Functions are affected by cold starts. This is how all serverless function architectures work. In order to scale down to zero (so you pay nothing if you use nothing), all server instances must be able to be decommissioned. Cold start up cost is paid when a new server instance is allocated, so going from zero to one will cost you one cold start.
You haven't defined what a "trigger function" is, so I'll assume you mean a "background function" which triggers in response to events that occur within your project.
Background functions are absolutely required when you want to have some work performed in response to those changes when you can't trust the client to perform that work directly. This is important to maintain data consistency, and also to prevent having to duplicate logic among all your different clients that are all doing the same thing. This also allows you to ship new features and bug fixes without having to ship new client code, which can be difficult and time-consuming.
I am using Firebase's cloud functions to execute triggers when a client adds something to the database, but it seems like these triggers take long time to execute.
For example, I have a trigger that adds a creation date to a post whenever a post is added to the database, and it takes like 10 seconds to complete.
Also, I have larger triggers that take even longer.
Is there like a "best practice" I am missing? Am I doing anything wrong?
I've found that the reason that Cloud Functions sometimes takes time to respond, is because they have a "warm up" period, meaning that the first time you call a cloud function it begins to warm up, and it won't be fully responsive until it is warm.
After it warms up, it will be as responsive as you would expect.
The reason for this behavior is resource resource balancing - If you don't use a function for some time, it will shut down and clear resources so other functions will be more responsive.