I was deploying very small size Cloud Function for testing, there were errors multiple times as I was doing egress network request which were not supported on the Spark plan and some other code related errors.
I upgraded to Blaze plan and was able to deploy the function successfully. Now suddenly my Bandwidth usage under Cloud Storage shot to 412 MB (41% of 1 GB of free tier). Going through other similar questions (will Cloud Function affect Firebase Storage bandwidth usage?) I expected it to increase but is such high increase expected and how do I reduce it?
Also I found here that Cloud Storage also increases for some people: Cloud Storage increasing on deploying Cloud Function. In my case the bytes stored are still 0, can someone explain this to me?
What I am doing is a payment gateway integration on my app and they have asked some code to be run on server side (currently I am doing it on app code itself for testing). I am moving this code to cloud functions. I am just afraid if there was this much increase for this small function and how much I will end up till this goes live?
the storage usage is just for the deployment of the function that is the deployment process. The reason you are seeing 0 storage is because the storage bandwidth is related to deployment (if the function itself does not use storage API), so it will not increase.
you can limit the capacity and quotas for any GCP products by using a budget available in GCP. with that you can set a budget for any Google products by setting an alert. Please refer to this link here: In this way you can set up a limit inturn you can monitor the limits as well.
And also for the Cloud function you can use the above link to set the budget or you can use refer to this link. To estimate the budget for the Cloud Functions.
For the Firebase, Please have a look here for Firebase pricing.Hope this works for you!
Related
I am trying to figure out why firebase storage usage is far above my expectation
I only have few photo files in my Firebase storage, just around 75 photos, 100kb for each photo. but my bytes stored and object counts is way above my expectation as you can see in the image above. in this case, maybe I find the answer from the documentation in here
When you deploy your function's source code to Cloud Functions, that
source is stored in a Cloud Storage bucket. Cloud Build then
automatically builds your code into a container image and pushes that
image to Container Registry. Cloud Functions accesses this image when
it needs to run the container to execute your function.
The process of building the image is entirely automatic and requires
no direct input from you
it is probably because I create a lot of cloud function. thats why the bytes stored and object count in my Firebase Storage is big
now I need to know why storage bandwidth is up to 20.2 GB in a month. I am still developing my app, the user is just me. I don't think I will hit 20.2 GB in a month, because in my Android app, I use cache when showing the image.
I am suspicious, the reason why my storage bandwidth usage is too high is because of cloud function. in August, I perform a lot of firebase deploy to my cloud function. will Cloud Function affect Firebase Storage bandwidth usage ?
I am in Indonesia, my Firebase Storage and Firestore are located in asia-southeast2, but my Cloud Function is located in asia-east2. my cloud function perform some operation to my firestore and images in storage. but still I don't think it will hit 20.2 GB per month
as you can see from the image above, the bandwidth usage is separated into 3 different parts
asia.artifacts.projectID.appspot.com
gcf-sources-5900904-asia-east2
projectID.appspot.com
the asia.artifacts.projectID.appspot.com seems way above the other, it is up to 4.3 GB
thats some information of my problem. so I need to know, will cloud function deployment/operation affect my Firebase Storage Bandwidth usage ?
I need to understand why this is happened, because I am worried that I will have unexpected cost if a lot of users use my app.
I was surprised by the bandwidth usage too.
First, Firebase Changed some policy
After August 17, 2020, each deployment operation will incur small-scale charges for the >storage space used for the function's container. For example, if your functions consume ?>1GB of storage via Container Registry, you'll be billed $0.026 per month. If your >development process depends on deploying functions for testing, you can further minimize >costs by using the Firebase Local Emulator Suite during development.
So the most reasonable explanation is cloud function build during npm install generates bandwidth usage of downloading node_modules and also takes up storage.
I would suggest use local emulator during development as much as possible, but many cases production test is inevitable, so sad.
The part of the documentation you quoted that's relevant here is:
Cloud Functions accesses this image when it needs to run the container to execute your function.
The built images are being accessed by Cloud Functions in order to run your code that's built into the image. Although the documentation doesn't specify, I would guess that every cold start of a function requires a download of the image from the artifacts bucket. This would explain the usage on that bucket.
I deployed a cloud function in firebase but instead of using a local emulator for testing purposes, I redeployed it several times to debug and test. After this, I see that my usage in the cloud storage in firebase is upwards of 500 MB although I have not stored any files in the Cloud Storage. Is this due to the multiple redeployments of the function? If yes, will deleting the cloud function free up this space or is there another way.
Thanks.
Yes, deploying a Cloud Function will take up more space in Cloud Storage. There is a dedicated storage bucket for the build of the server images that get deployed. You can see this for yourself in the Google Cloud Console for your project. You can manually delete the content if you don't want to pay for the storage.
I don't think that deleting the function will also delete the storage, but you can try that for yourself and observe if it works the way you expect.
See also:
How to delete outdated Firebase Cloud function containers from GC Storage?
will Cloud Function affect Firebase Storage bandwidth usage?
Hi I am using firebase and the firebase functions.
1 day ago I received an email from Google Cloud with the following content:
Starting April 20, 2020, Cloud Functions will use Google Cloud Build, Container Registry, and Google Cloud Storage to build and store your source code, and deploy container image(s) before running them on Google Cloud. You must enable the Cloud Build API for your project(s) to ensure your Cloud Function is built and deployed correctly. Once you enable the API, you may incur charges if your Cloud Build, Container Registry, or Cloud Storage usage exceeds the free tier limits for these products. You can find a list of your projects that are using Cloud Functions and may be affected by this change at the bottom of this email.
I tend to avoid tinkering the Google Cloud (or even logging in there) as I am using the Firebase as an all inclusive solution and so far I did not have the need to login there.
Now the question:
Do I need to follow the instructions and take action, or is this something separate from the Firebase Functions?
The "affected" project that is mentioned on the email is the Firebase project
To be able to use cloud functions after April 20, 2020 you must enable the Cloud Build API because this will be a new deployment framework.
You will not be able to use cloud functions if you do not enable the Cloud Build API after this date.
These changes will apply even for Firebase cloud functions.
I believe you will need to do it only if you are going to deploy Cloud Functions in the future, Cloud Functions already deployed will not be affected.
In case you are worried about billing, Cloud Build provides a free tier where only usage above 120 build-minutes/day will be charged. When your usage is within the free tier, you will not be charged for the Cloud Build portion of Cloud Function deployments. See Cloud Build pricing for more information.
Similarly, Cloud Storage and Container Registry share a free tier where only usage above 5GB-months will be charged. ( * Note : free tier only limited to US regions - US-WEST1, US-CENTRAL1, and US-EAST1 and aggregated over all 3 regions ) For example, if you have a large deployment that uses 100GB of storage, you will only be charged an additional $2.47 for storage/month (based on these particular U.S. regional storage prices).
You can monitor your usage and see whether you are getting close to hitting the free quotas.
This is a best effort from Google to communicate information that is necessary to the user’s continued use of the product or that is considered a necessary legal update and keep customers away from having future issues
Using Cloud Build, Container Registry and Cloud Storage provides the following benefits:
Detailed function build logs will be available in the GCP Console, aiding in debugging and increasing visibility.
The ability to get build time that exceeds the current build quota of 120 build-mins/day.
The ability to view a built container image for your function in Container Registry.
After reading the docs on both Cloud Run and Firebase Cloud Functions, I have a few questions I want to clear up:
Does Cloud Run basically act as a container image storage/deploying mechanism? If I have 2 websites and have them as separate containerized images, does Cloud Run just deploy the specified one given the trigger?
Integrating Cloud Run with Firebase Cloud Functions as the trigger, will there be an additional layer of latency? While latency times are never known, FCFs inherently have warm-up times due to cold starts, will there be added latency due to Cloud Run cold-starting the images?
Does the Cloud Run images travel through the FCF to get to the user. Or does FCF merely redirect the user directly to the Cloud Run image?
Basically, is it like
Client -> FCF -> Image -> FCF -> Client
or
Client -> FCF -> Image -> Client
Typically on Stack Overflow one is supposed to limit to one question per post (to avoid being closed as "too broad"), but I'll try here. Please address followup questions as new posts.
Yes, it is just a containerized way of serving HTTP requests.
Cloud Run is not directly related to Cloud Function except where you write code to connect them. If you write a Cloud Function trigger that proxies to Cloud Run, it will incur all the latency costs of both products, as required (not all invocations require a cold start). All "serverless" compute options have a cold start time, since they all scale down to zero (based on current load), and you don't pay for virtual server instances to be allocated and immediately available all the time.
Again, they are not related. You can use either one without the other.
I have an app which uses firebase storage and I am observing an unusual traffic to the storage. The bandwidth usage is unusually high, which shouldn't happen with the usual behavior of the app.
I need to isolate a user or a stored file which causes this unusual bandwidth usage. Is there any way I can get more information about the storage usage, other than the information shown at the Usage tab of firebase console?
Firebase Storage only tracks and shows aggregate data for the usage in your project. It does not tie this usage to specific Firebase Authentication users.
If you need that, consider adding your own tracking for this, for example by logging uploads/downloads to Google Analytics for Firebase.
You can also log to Stack Driver, although it might only be in aggregate there too. For the exact metrics, see the Google Cloud Platform documentation on its storage metrics.
Alternatively you could reach out to Firebase support for personalized help in troubleshooting. But I'm not sure if they have access to the type of data you're looking for.