I know there is already a thread on how the number of concurrent users is calculated in Firebase, but it doesn't answer my question, which is: if a single user has multiple observers to multiple locations in a single Firebase application, does it count as one or several concurrent users?
Multiple observers to multiple location from the same Firebase connection is counted as one concurrent only. Every web page shares a single connection to a given Firebase, but not across iframes or tabs. Every node.js, iOS or Android process will share one connection per Firebase as well.
Related
I know scalability is not an issue in Firebase and supports up to 100k Simultaneous connections(in general).
Based on pricing documentation:
You can create multiple database instances to go beyond the 100K
concurrent limit. See Pricing FAQ for more information.
Question 1: What if there is more than 200k users using simultaneously on the same database? The other half of the users could not query, connect or the request will be placed in queue?
(As a Firebase plan subscriber, I would like to know how Firebase deals with the problem to ensure the quality of the services provided to our customers are always in top-notch)
Since, App globalisation is common nowadays and many companies' practices are to have servers across multiple regions to provide better and stable performance. Online game for example which required low latency.
As for now, the firebase user is required to set the default location when creating the project which is non-editable afterward. Some issues even rises where the users realised they deployed their app to the wrong regions and do not have clues on how to change the regions.
This represents the country/region of your organisation/company. Your
selection also sets the appropriate currency for your revenue
reporting. The selected country does not determine the location of
your data for Firebase features. Google may process and store Customer
Data anywhere Google or its agents maintain facilities.
Question 2: Will or does Firebase provide a solution / tailor-made to such practice which having our database in multiple regions while having a headquartered region and multiple other regions sharing all the databases, functions and auth across the regions?
(For now to have multiple servers location, we have to create different projects and the user and data syncing will be a problem)
Hope the language does not offend, cheers!
It seems like your question (or at least your assumptions) is based on the Firebase Realtime Database, so I'll answer for that below.
Q1) You can create more than 2 databases in a single project, each of which allows 100K connections. So it can scale beyond 200K connections. All of these are hosted in the same region though, so you can't use each database for a separate region.
Q2) For a database solution that handles multiple regions, I'd recommend looking at Cloud Firestore. Also see: Cloud Firestore - selecting region to store data?
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.
Regarding the recent announcement of the multi-database support within a Firebase project, can we add listeners to multiple databases? Or should we connect to maximum one database at a time?
For example, let's say that I have created two databases, DB-1 and DB-2. I want to add a listener for changes in node-A in DB-1 and another listener in node-B in DB-2. Is this possible? I've read the documentation but it's a bit contradicting:
Each app instance only connects to one database at any given moment.
...
If each client needs to connect to multiple databases during a session, you can reduce the number of simultaneous connections to each database instance by connecting to each database instance for only as long as is necessary.
You can certainly connect to multiple databases at the same time, according to the documentation. There may be cases when you want to reduce the active number of active connections your app is making, especially if you have a lot of shards, each with a lot of activity, so the advice stands for those cases, if this applies to you.
We're working on a notifications system that utilizes SignalR. We need every user to be able to "listen" to multiple groups simultaneously.
You can think of it like news alerts. A particular user may be interested in news alerts in "politics", "NBA" and "business". Every time a news alert comes into one of these categories, we want to be able to send a notification to user's browser through SignalR.
Can we simultaneously "listen" to multiple groups for every user in SignalR? If so, is there a limit to the number of groups a user can be member of at any given point?
While there is no hardcoded limit on number of groups in SignalR but you may hit the URL size limit. Take a look at this comment where reconnect requests were failing because the URL was too long due to the client being subscribed to too many groups.
I'm building an app using firebase in Polymer. It is tempting to create a new firebase-collection for each ajax call I might have made in the past. Since firebase.com bills based on the maximum number of simultaneous connections (sessions?), I'm worried that the firebase-element components each count as one connection. Thus, if there are ten firebase-elements in a page it will be counted as 10 connections instead of one.
Do I need to design the page to minimize the number of firebase-elements? How are connections counted when using firebase-elements?
Firebase opens a web socket when a page makes a first connection to its servers. All subsequent data reads/writes for that page happen over the same web socket.
Also see:
Concurrent users and multiple observers
How exactly are concurrent users determined for a Firebase app?