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.
Related
I am learning web development and I am using Firebase as my backend. I am planning on preventing bots from brute force attacks which will rack up my firestore bill by:
Only allowing logged in users to write to the database with security rules.
Using Firestore & security rules to only allow a certain amount of writes per second per user. If the user goes over this amount they will be banned for a certain time period.
Will these 2 security measures stop most bot attacks?
Also I was looking at the pricing for hosting and I saw it costs $0.15 per 1 GB of data transferred.
My entire web application is only about 5 mb of data, but that means if my web application is loaded 1,000 times then it would cost me 5 mb * 1,000 = 5 GB * $0.15 = $0.75 which I can handle. But let's say someone got a bot to re-load the page 1,000,000 times then it would cost me 5 mb * 1,000,000 = 5,000 GB * $0.15 = $750. Obviously $750 is a lot of money and I can't handle that.
How do I prevent bots from re-loading my page multiple times and racking up my hosting bill? I can't use the listed strategy above because I want users who don't have an account to still be able to view my website.
First, a few clarifiers…
Cost of FB hosting is $0.15 per GB after you have exceeded the free usage of 10GB/month.
Your entire application may be 5MB but that is likely not the amount of data transmitted unless you missed a build step. In a React app, resources are loaded only as needed. Responses are then even further compressed by Firebase to save bandwidth.
Assets are generally cached and not reloaded on subsequent page views. It’s a bit more nuanced with bots but this helps keep data transfer rates down overall.
Now to your question…
Mitigating repeat page visits the way you describe is handled mostly through rate limiting. This limits the number of requests to your site in a given period.
Implementing Google Analytics can also help in detecting bot traffic by reporting unusual bursts of activity.
You could also use a CAPTCHA to reduce bot attempts to log in or submit other form data.
Two-factor auth is another good tool in preventing brute force attacks.
Finally, I would suggest creating budget alerts for your project. This is easy to do and highly customizable. You can even set it for $1 if you wish. It will not stop your project automatically, only send you an email. But if handled quickly, it will save you from getting an even bigger bill.
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.
I've read quite a few posts (including the firebase.com website) on Firebase connections. The website says that one connection is equivalent to approximately 1400 visiting users per month. And this makes sense to me given a scenario where the client makes a quick connection to the Firebase server, pulls down some data, and then closes the connection. However, if I'm using angular bindings (via angularfire), wouldn't each client visit (in the event the user stays on the site for a period of time) be a connection? In this example having 100 users (each of which is making use of firebase angular bindings) connecting to the site at the same time would be 100 connections. If I opted not to use angular bindings, that number could be (in a theoretical sense) 0 if all the clients already made their requests for data and were just idling.
Do I understand this properly?
AngularFire is built on top of Firebase's regular JavaScript/Web SDK. The connection count is fundamentally the same between them: if a 100 users are using your application at the same time and you are synchronizing data for each of them, you will have 100 concurrent connections at that time.
The statement that one concurrent connection is the equivalent of about 1400 visits per month is based on the extensive experience that the Firebase people have with how long the average connection lasts. As Andrew Lee stated in this answer: most developers vastly over-estimate the number of concurrent connections they will have.
As said: AngularFire fundamentally behaves the same as Firebase's JavaScript API (because it is built on top of that). Both libraries keep an open connection for a user, so that they can synchronize any changes that occur between the connected users. You can manually drop such a connection by calling goOffLine and then re-instate it with goOnline. Whether that is a good approach is largely dependent on the type of application you're building.
Two examples:
There recently was someone who was building a word game. He used Firebase to store the final score for each game. In his case explicitly managing the connections makes sense, because the connection is only needed for a relatively short time when compared to the time the application is active.
The "hello world" for Firebase programming is a chat application. In such an application it doesn't make a lot of sense to manage the connections yourself. So briefly connect every 15 seconds and then disconnect again. If you do this, you're essentially reverting to polling for updates. Doing so will lose you one of the bigger benefits of using Firebase: it automatically synchronizes data to connected clients.
So only you can decide whether explicit connection management is best for you application. I'd recommend starting without it (it's simpler) and first testing your application on a smaller scale to see how actual usage holds up to your expectation.
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)
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.