Are firebase dev accounts rate-limited? - firebase

We've been developing with Firebase for a couple of months and recently we've seen some long delays in downloading data (e.g. 20 seconds). During those times the "forge" web UI is also tremendously slow to respond.
After a while, it seems to clear up and go back to its lightning-fast self.
Could this be because I'm using a significant portion of the free quota (80 MB / 100MB of storage and 1.6 GB / GB in bandwidth)? Are there undocumented rate limits we're hitting?
The last time this happened we had 6 concurrent users, and our alltime peak so far has been 13.

The short answer is no, dev accounts aren't rate-limited. They're capped on connections, data storage, and monthly data transfer, but there's no rate-limiting.
If you're having performance issues, your best bet would be to email support#firebase.com detailing what you're seeing and the name of your Firebase so that we can investigate. Typically, delays are the result of large data transfers going into or out of your Firebase (e.g. downloading your entire Firebase, which could be accidentally triggered by opening Forge) and there are usually mitigation strategies that we can help you out with.

Related

Lowering Cloud Firestore API Latency

I developed an Android application where I use Firebase as my main service for storing data, authenticating users, storage, and more.
I recently went deeper into the service and wanted to see the API usage in my Google Cloud Platform.
In order to do so, I navigated to https://console.cloud.google.com/ to see what it has to show inside APIs and Services:
And by checking what might cause it I got:
Can someone please explain what is the meaning of "Latency" and what could be the reason that specifically this service has so much higher Latency value compared to the other API's?
Does this value have any impact on my application such as slowing the response or something else? If yes, are there any guidelines to lower this value?
Thank you
Latency is the "delay" until an operation starts. Cloud Functions, in particular, have to actually load and start a container (if they have paused), or at least load from memory (it depends on how often the function is called).
Can this affect your client? Holy heck, yes. but what you can do about it is a significant study in and of itself. For Cloud Functions, the biggest latency comes from starting the "container" (assuming cold-start, which your low Request count suggests) - it will have to load and initialize modules before calling your code. Same issue applies here as for browser code: tight code, minimal module loads, etc.
Some latency is to be expected from Cloud Functions (I'm pretty sure a couple hundred ms is typical). Design your client UX accordingly. Cloud Functions real power isn't instantaneous response; rather it's the compute power available IN PARALLEL with browser operations, and the ability to spin up multiple instances to respond to multiple browser sessions. Use it accordingly.
Listen and Write are long lived streams. In this case a 8 minute latency should be interpreted as a connection that was open for 8 minutes. Individual queries or write operations on those streams will be faster (milliseconds).

Firebase Hosting Deleted Deployments Taking Up Space

I am using Firebase to host a small site (~6 mb), yet I noticed the usage meter is showing a much higher number. I realized that old deployments counted towards storage, so I deleted them. However, the usage meter shows the same amount of storage.
Is there a time period before the old deployments are truly deleted? I can't imagine you are forced to keep consuming storage space.
Thanks.
It turns out it took roughly 24 hours for the changes to take effect.
Others mileage may vary, as this is anecdotal.

Firebase database bandwidth usage growing rapidly even when when the database is not in use

Update: After 9 months of back-and-forth emails (over 40 emails), Google has acknowledged that they have found some bugs that may be responsible for high bandwidth usage, but bandwidth usage is still too high. Resolving this issue does no appear to be a priority for Google/Firebase (it took them 1.5 months to respond to the last email). In light of similar complaints such as: https://news.ycombinator.com/item?id=14356409, and many others, across a wide range of teams/developers, hopefully the situation will improve some day.
I'm just starting a Firebase project and have not accessed the database from any client. I have only created a single tiny test key-value pair in the database (using the console), which uses 23 B of data storage. Surprisingly, the console shows that I have used 215.9 KB (including when I was not touching Firebase at all). This number continues to grow every hour even though I am not using Firebase or even refreshing the data tab in the console!
Here is a screenshot of the console bandwidth usage chart:
Firebase console bandwidth usage screenshot
Others appear to be having the same problem, but there has been no response from Firebase/Google. What's going on? Any help would be greatly appreciated.
The usage chart takes time to update. You may be seeing bandwidth from a few minutes to a few hours ago.
Also, this reminds me of the old Google Analytics referrer issue, the default rules for firebase look something like this:
.read = true;
.write if auth != null;
This means that anyone anywhere can read from your database and that anyone authenticated(even anonymously) can write to it. It is possible since it is a noSQL database with json support that it is probably just crawlers which are the equivalent of Google Analytics referral spam.

Is it bad practice to store information in the cache for long periods of time?

I have a webpage, which takes a while to load because it has to pull information from lots of local databases. For example, if a user searches for person 1 then it will query 20 databases. It can sometimes take 5 minutes to pull all the information needed and apply the business logic. The best solution is to design a data warehouse, which is a long term aim.
If I use data caching it reduces the page load time (of the big records) from five minutes to four seconds. Is it bad practice to store information in the cache for a long period of time i.e. 24 hours? The cache will be refreshed every 24 hours. Alternatively I could store the cached information in a database table.
Every example I find online caches information for seconds e.g. 20 seconds.
Pros:
Faster load times
Less bandwidth usage
Less stress on the server
Cons:
May require high technical expertise to configure it just right
Will not work for content that is constantly being updated
For many system administrators, especially those with the skills to implement a caching system, the pros greatly outweigh the cons. Caching can make your websites run more smoothly for visitors and lessen the burden on your dedicated server.
For more Check this link
Cache is used for global resources, if in your application the data is per user then use Session which is like cache per user.
You can also cache results and connect it to database tables so if a table is being update so does the cache it is called Cache Dependency.
The main concern you need to have is what if the cached information in not up to date, in that case use Cache Dependency.
Don't worry about memory issues in your server, the server is already optimized and knows to clean cache in case of lack in memory.
I hope this helps you.

Limitation of free plan in firebase

What is the meaning of the following?
50 Max Connections, 5 GB Data Transfer, 100 MB Data Storage.
Can anyone explain me? Thanks
EDIT - Generous limits for hobbyists
Firebase has now updated the free plan limits
Now you have
100 max connections
10 GB data transfer
1 GB storage
That means that you can have only 50 active users at once, only 5GB data to be transferred within one month and store only 100 MB of your data.
i.g. you have an online web store: only 50 users can be there at once, only 100 mbytes of data (title, price, image of item) can be stored in DB and only 5 GB of transfer - means that your web site will be available to deliver to users only 5gb of data (i.e. your page is 1 mbyte size and users will be able to attend that page only 50 000 times).
UPD: to verify the size of certain page (to define if 5gb is enough for you) - using google chrome right click anywhere on page - "Inspect Element" and switch to tab "Network". Then refresh the page. In bottom status bar you will amount of transferred data (attached size of current stackoverflow page, which is 25 kbytes)
From the same page where the question was copied/pasted:
What is a concurrent connection?
A connection is a measure of the number of users that are using your
app or site simultaneously. It's any open network connection to our
servers. This isn't the same as the total number of visitors to your
site or the total number of users of your app. In our experience, 1
concurrent corresponds to roughly 1,400 monthly visits.
Our Hacker Plan has a hard limit on the number of connections. All of
the paid Firebases, however, are “burstable”, which means there are no
hard caps on usage. REST API requests don't count towards your
connection limits.
Data transfer refers to the amount of bytes sent back and forth between the client and server. This includes all data sent via listeners--e.g. on('child_added'...)--and read/write ops. This does not include hosted assets like CSS, HTML, and JavaScript files uploaded with firebase deploy
Data storage refers to the amount of persistent data that can live in the database. This also does not include hosted assets like CSS, HTML, and JavaScript files uploaded with firebase deploy
These limits mentioned and discussed in the answers, are per project
The number of free projects is not documented. Since this is an abuse vector, the number of free projects is based on some super secret sauce--i.e. your reputation with Cloud. Somewhere in the range of 5-10 seems to be the norm.
Note also that deleted projects take around a week to be deleted and they continue to count against your quota for that time frame.
Ref

Resources