I would love to use Firebase as my primary cloud storage service for my HTML5 mobile apps, but I'm having trouble figuring out if the limit on simultaneous connections is going to restrict me from having a lot of non-realtime users as well.
At first glance, it looks like I can only have as many users as the connections I am paying for. What happens when 10,000 people download my app? If my app doesn't need real-time synchronization (polling is sometimes totally fine), is Firebase's architecture still going to limit the amount of concurrent users? Should I just go with couchDB and a VPS?
Thanks!
You need many fewer concurrents than your total expected user count. Firebase recommends 1 concurrent for about every 1440 visits, per their pricing FAQ.
So, if you expect to have 10,000 visits, you'll likely see under 10 concurrents most of the time. This keeps you well below the 200 provided by the candle plan.
(Answer copied mostly from comments. Thanks #Kato)
Related
Unfortunately Firebase's Flame plan disappeared and I now have to deal with Blaze plan, which I'm not fan of because of it's "unlimited" budget (but my wallet isn't). Yesterday I was coding and by mistake made a loop that called 3 Cloud Functions, I spotted the loop fast enough to stop the carnage.
In only 15 seconds of execution, I've been able to trigger more than 10K requests, and without errors, that a pretty good performance of Firebase, but it's scary as well! How can I cap this to throttle requests coming from users? I'm pretty confident in my code, but as we all know if someone gets my Firebase config file, I'm done.
I'm a solo developer and it's my first app done on my spare time, I don't want to to become a mess because of triggering reads / writes / Cloud Functions. No one is perfect, everyone makes mistakes, maybe I didn't spot a small bug in my code that'll reveal it's true potential only once in production. I'm not asking Firebase to handle my mistakes, but I'd like to be able to stop the CF and Firebase if I want to.
My only desire is to sleep confident, I don't want to wake up one morning with a 10.000$ bill. I've read that's it's possible to totally disable billing account on a project with CloudFunctions, but what will happen to my Firebase Storage bucket for example (for the storage superior to the Spark plan)? And it doesn't seem easy to do.
Firebase is a great product and I love how easy / fun it is to use, but now that budget locked plans as Flame are gone I feel really trapped now that my application is almost ready to go into production, and I don't think I'm the only one out there.
Ah you've stumbled onto the 'rate-limiting' conundrum. Not to worry, I've spent many nights worrying about this myself.
In order to get a bit more control over your application, you're going to have to link your project to google cloud platform. Then navigate to IAM & Admin>Quotas (once you've selected your firebase project).
Now you might be overwhelmed initially, and confused as to why there are so many Cloud functions API limiters. These quotas should allow you to rate limit your cloud functions API (similar to what twitter does) in a number of ways, including but not limited to:
Read Requests per day
Read requests per 100 seconds
Function invocations per 100 seconds
Function invocations per day
etc
The API that will be listed are the ones you've enabled, so you can set limits for cloud storage as well.
By default, the max number of invocations per second is set to the maximum of 5000 invocations per day on the spark plan. but according to the docs, the absolute maximum is 100,000,000/100 seconds!
Also worth having a look at is the pricing docs, which have a nice example of a typical monthly use case for a successful app. To grossly oversimplify, a single invocation costs $0.0000004, hence 10,000,000 invocations will cost you a whopping $3.20. However don't let that very low cost fool you, if you write some terrible code and it has exponential complexity (like reading every document in a firestore collection every invocation), you could get slapped with an exponential cost. So make sure you set those quotas :)
Remember, server admin is as much a part of the application as the code itself. If your app goes to production, be prepared to spend some time each day going through the Google cloud dashboard and checking limits, analyzing trends, etc. This way you can kind of step up the amount of invocations you can allow per day and sleep well knowing that if you shoot yourself in the foot, you won't bleed too much.
Best of luck with it
Despicable B.
I am using firebase database and my question is, for example how fast can I reach 1GB if i have 100 users each storing worth 10 document pages of microsoft word full of text everyday, for one month?
Word documents would be stored in Firebase Storage, not the realtime database. Realistically, the only way you will be billed anything for using the Firebase platform is if your app gets a significant of usage. I suspect that 99% of firebase apps do not generate any billing whatsoever. ...that's just a hunch.
If you do run into billing issues, that will/would be a good thing.
Although this question is too broad since it lacks various variables like the number of users, size of the files and how this data is presented in the app I will try to give my $0.02 on this in a very generic way which can also be interpreted as how not to end up with a huge bill while using firebase,
Even though Firebase provides a sufficient space to test out the app in production there is a lot of ways in which things can go bad real quick like,
1) since firebase automatically handles the sync this additional read/write call comes out of your quota apart from the call you trigger check-out how one app developers found this out the hard way
2) if you have bad DB schema/design that you have not addressed, then you end up making multiple calls to the server to fetch the data which again bloats up the number of calls you make read about this here
3) Not setting spending limits and alerts, this should be a mandatory step to avoid a lot of the above problems even though the docs clearly gives an indication on how to set this up
These are some of the cases that I have come across I hope this serves as a guideline to set up your app
I just hit a situation which pushed me to ask this question:
I have about 150 active monthly users and I just hit 1k concurrent connections on a single day.
I did research and found many questions on "firebase concurrent connections" topic and those who refers to user-to-concurrent ratio say that on average it's close to 1 concurrent = ~1400 monthly users (like here and here).
I'm now trying to understand if I really did something wrong and if yes, how to fix that?
The questions are:
Is it look ok to get 1k concurrent connections with about 150 active users? Or am I reading it wrong?
Is it possible to profile concurrent connections somehow?
What are the typical "connection leaks" when it comes to chrome extensions and how to avoid them?
So far the architecture of the extension is that all the communication with firebase database is made from the background persistent script which is global to a browser instance.
And as a note, 150 active users is an estimation. For upper boundary I can say that I have 472 user records in total and half of them installed the extension and uninstalled it shortly after that - so they are not using it. And about 20% of the installed instances are also disabled in chrome.
Here is what I get after discussing with the support team:
here are other common use cases that can add up to the number of
connections in your app:
Opening your web app in multiple tabs on your browser (1 connection per tab)
Accessing the Realtime Database dashboard from the Firebase Console (1 connection per tab)
Having Realtime Database triggers
So Realtime Database triggers appeared to be my case.
Further discussion revealed the following:
In the case of uploading 200 data points which each trigger a
function, any number of concurrent connections between 1 and 200 is
possible. It all depends on how Cloud Functions scales. In an extreme
case it could just be one instance that processes all 200 events one
at a time. In another extreme case the Cloud Functions system could
decide to spin up 200 new server instances to handle the incoming
events. There's no guarantee as to what will happen here, Cloud
Functions will try to do the right thing. Each case would cost the
user the same amount on their Cloud Functions bill. What's most likely
in a real application (where it's not a complete cold start) is
something in the middle.
There's no need to worry about the number of concurrent connections
from Cloud Functions to RTDB. Cloud Functions would never spin up
anywhere near 100k server instances. So there's no way Cloud Functions
would eat up the whole concurrency limit. That would only happen if
there are many users on the client app accessing your database
directly from their devices.
So the described behavior in my question seems to be expected and it will not come any close to the limit of 100k connections from server side.
How exactly are concurrent users determined for a Firebase app?
It seems in the analysis panel that there are more peak concurrent users than I have had browser windows open using my app.
I'm a little worried about committing to FB for the future with the 1000 concurrent limit, but perhaps I'm overestimating the popularity of my app and likelihood of ever reaching that limit. :)
A concurrent user is a single client (browser tab, mobile app, Node.js process, etc) connected to Firebase at a time. If you have 3 browser tabs open, you should see 3 concurrent users (note that the stats in our analytics dashboard are a little bit delayed).
In our experience, on average, 1 concurrent user is equivalent to ~1400 visits per month to a website. 1000 is a very large number of concurrent users for most apps, and fewer than 1% of Firebase apps ever reach this.
Note that Firebase is capable of powering apps well beyond 1000 concurrent users, so if you have a bigger app (even a much, much bigger app), it's not a problem.
How exactly are concurrent users determined for a Firebase app?
It seems in the analysis panel that there are more peak concurrent users than I have had browser windows open using my app.
I'm a little worried about committing to FB for the future with the 1000 concurrent limit, but perhaps I'm overestimating the popularity of my app and likelihood of ever reaching that limit. :)
A concurrent user is a single client (browser tab, mobile app, Node.js process, etc) connected to Firebase at a time. If you have 3 browser tabs open, you should see 3 concurrent users (note that the stats in our analytics dashboard are a little bit delayed).
In our experience, on average, 1 concurrent user is equivalent to ~1400 visits per month to a website. 1000 is a very large number of concurrent users for most apps, and fewer than 1% of Firebase apps ever reach this.
Note that Firebase is capable of powering apps well beyond 1000 concurrent users, so if you have a bigger app (even a much, much bigger app), it's not a problem.