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.
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.
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)
Recently I was developing an application using Linkedin people-search API. Documentation says that a developer registration has 1 lac API calls per day, but when I have registered this API, and ran a python script, after some 300 calls it says throttle limit exceeds.
Did anyone face such kind of issue using Linkedin API, comments are appreciated.
Thanks in advance.
It's been a while but the stats suggest people still look at this and I'm experimenting with the LinkedIn API and can provide some more detail.
The typical throttles are stated as both a max (e.g. 100K) and a per-user-token number (e.g. 500). Those numbers together mean you can get up to a maximum of 100,000 calls per day to the API but even as a developer a single user token means a maximum of 500 per day.
I ran into this, and after setting up a barebones app and getting some users I can confirm a daily throttle of several thousands of API calls. [Deleted discussion of what was probably, upon further consideration, an accidental back door in the LinkedIn API.]
As per the Throttle Limits published by LinkedIn:
LinkedIn API keys are throttled by default. The throttles are designed
to ensure maximum performance for all developers and to protect the
user experience of all users on LinkedIn.
There are three types of throttles applied to all API keys:
Application throttles: These throttles limit the number of each API call your application can make using its API key.
User throttles: These throttles limit the number of calls for any individual user of your application. User-level throttles serve
several purposes, but in general are implemented where there is a
significant potential impact to the user experience for LinkedIn
users.
Developer throttles: For people listed as developers on their API keys, they will see user throttles that are approximately four times
higher than the user throttles for most calls. This gives you extra
capacity to build and test your application. Be aware that the
developer throttles give you higher throttle limits as a developer of
your application. But your users will experience the User throttle
limits, which are lower. Take care to make sure that your application
functions correctly with the User throttle limits, not just for the
throttle limits for your usage as a developer.
Note: To view current API usage of your application and to ensure you haven't hit any throttle limits, visit
https://www.linkedin.com/developer/apps and click on "Usage & Limits".
The throttle limit for individual users of People Search is 100, with 400 being the limit for the person that is associated with the Application as the developer:
https://developer.linkedin.com/documents/throttle-limits
When you run into a limit, view the api usage for the application on the application page to see which throttle you are hitting.