I have a question regarding the firebase AUTH API. According to firebase you can perform 1000 requests per second / per project. I would like to know what happens if you exceed that limit and have, let's say 2000 users logging in at the same time / second. Will the 1000+ users receive an error? Or will they be queued to the next available slot? The documentation does not say that.
We are on the blaze plan btw.
Thank you for your help!
Related
Introduction
So from the official firebase docs. It states there that:
The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a 429 RESOURCE_EXHAUSTED ("quota exceeded") response. Retry with exponential backoff.
The topic subscription add/remove rate is limited to 3,000 QPS per project.
qps = queries per second.
Now here's the thing. It says "per project". What if an app gets very popular and thousands of users open the app at the same time then click a button that subscribes to a topic or unsubscribe?
Wouldn't hitting the rate limit 3000 queries per second highly possible?
Here's my real question
Does firebase_messaging's subscribeToTopic(..) and unsubscribeFromTopic(..) methods automatically handle retries? (referring to "Retry with exponential backoff" above)
If not, then how would a very popular app handle topic subscriptions from a massive number of users?
Because the plugin does not provide any documentation about this.
Coming from a different platform (Android) for your question on subscribeToTopic() retry?, but possibly both function similarly. On Android it returns a Task where in Flutter it returns Future (Task = Future for Flutter if I understood that correctly), which I presume is a hint that Google gave the responsibility for the retries to the developers.
I'm not sure what your looking for as an answer. The correct way is to implement an exponential backoff as mentioned in the docs. Depending on your use-case, different strategies can be implemented.
e.g. forced subscription -- like a general topic, that runs every app start is easy. One-off subscriptions, you might need some verifications i.e. a way to check if the user actually finished subscribing, retry if not.
Context: I am total Google Cloud begginer and I have just convinced my company headers to use Firestore Realtime Database for pushing transaction status to our mobile application. We have around 4 millions users that will use significantly our application for small money transfers. Now-a-days we use the concept of polling from Android/IOS to our Microservice endpoints and it will replaced by Firebase SDK imported to our Mobile app which will listen/observe to our Firestore Collection following few Firestore Rules. Since all money transfer will be confirmed/denied in short time (from few seconds to 1 or 2 minutes) the idea of replacing polling by a real reactive approach straigh from Firestore sounded and is already ongoing coding.
The issue: Firstly I don't what to compare solutions. It is just my reality: the prodution support operators must look after our internal Dashboard. Isn't allowed to them look at Google Dashboard Console (please accept this for this question). I need get on demand metrics of our FIrestore. It is nothing to do with Google pricing. It is just our demand: they want to see metrics like:
how many users listening at the same time now
how many users took some exception during connection
is there any user holding connection for more than X minute
when was the connection pick this morning
any exception of any type surrounding our Firestore database
I read Code Samples carefully follow the sample step-by-step trying to figure out some idea if there is some API providing the answers I am looking for.
So, my straight question is: is there such type of Google API providing metrics about my Firestore Database? Maybe following the same idea we found in Performance Monitor which works on Mobile side also some similar aproach on Firestore side.
*** Edited
Future readers may find worth read also about a way to get Firestore metrics info striagh from curl/postman
A couple of things: You mentioned both Firestore and Realtime Database; just wanted to make sure that you are aware that those are two different databases offered under the Firebase umbrella.
how many users listening at the same time now
is there any user holding connection for more than X minute
Yes, there's a dashboard: https://support.google.com/firebase/answer/6317517?hl=en. Including lots of options, like users active in the last 30 mins.
how many users took some exception during connection
any exception of any type surrounding our Firestore database
Yes, you can track errors and other logging via Stack Driver logging. These can give you reports on your cloud functions.
https://cloud.google.com/functions/docs/monitoring
Where can I find Stackdriver in Firebase console?
when was the connection pick this morning
For this one, I'm not sure if you mean A. when did somebody log on in the morning, or B. what was the time that there was the peak \ most usage. If B see 1. If A,
Real-time database has the concept of presence, which lets you know if a user is currently logged in or not. See examples here from the official documentation:
https://firebase.google.com/docs/firestore/solutions/presence
and this post
How to make user presence mechanism using Firebase?
Also applies to your
is there any user holding connection for more than X minute
..............
Edit in response to comments: I believe you are experiencing the XY problem https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem where you are focused on a particular solution, even though your problem has other solutions. User metrics, database events, and errors are all accessible through both dashboards and cloud functions. You can cURL cloud functions if you wish, or set up cron functions to auto report, or set up database trigger functions to log errors. So, while the exact way you want this to work may not exist, you just need to connect existing tools to get the result you want.
I am a Google blaze plan user and I have an express server containing a simple endpoint that just pulls from firestore. During high traffic hours, I can retrieve 5000+ simultaneous read requests which eventually throws this error below,
Error: 8 RESOURCE_EXHAUSTED: Quota exceeded.
After I wait a few minutes I am able to read the collection again.
Update:
Unsure why the downvotes without any explainations.. but I also have a Mutex system which I think may be leading to hitting these limits. If fails to lock a document using transactions, it goes down an array of snapshots until a lock is given. If the array becomes empty, it does another read to firebase for another set of N documents, which is only 50 in my case.
So my question is, is there a limit on the amount of transactions or reads per second that we're allowed to do from a single connection (my express server)? I don't think it's stated anywhere in the documents.
It looks like you're reaching one of the read/write/transaction limits stated in this page.
Might be this one Maximum writes per second per database: 10,000 (up to 10 MiB per second) but I'm only guessing...
To answer your question, according to this link, the maximum concurrent connections for mobile/web clients per Firebase database is 1,000,000. Thus, your connections seem to not exceed the limits.
For the Blaze Plan project, the limit for Cloud Firestore Document Read is 50K/day, since free usage from Spark Plan is included in Blaze Plan. The limit is such, unless you have set any budget limit in your Billing account. The usage will be reset at midnight of PST. If you upgrade your plan to Flame Plan, the limit is 250K/day.
Here you may read about the official Cloud Firestore Quotas and limits, such as maximum document reads, maximum size for a document, that can be useful. Furthermore you may monitor your database usage and check your plan's limits from the “Usage” tab in the Firebase console. You can check usage over the current billing period, the last 30 days, or the last 24 hours.
Stackdriver Monitoring is also a practical tool for monitoring document reads/writes/deletes, active connections and snapshot listeners.
A good practice, if you want to avoid unexpected charges on your billing account, would be to create an alerting policy based on the Cloud Firestore metrics, as stated here.
Additionally, you can estimate and verify your monthly costs on the “Blaze Plan” by using this Blaze Plan calculator.
For anyone who runs into this issue in the future, please check your App Engine budget settings under "Application Settings". I set the daily spending limit to avoid unnecessary charges during testing and it slipped my mind. I increased the budget and the error is currently gone.
AWS usually sends me an email when my budget has been exceeded.
I am using google cloud pub/sub for receiving the push notifications of any gmail user by setting a watch on the concerned users mailbox. I am able to do that. I am creating a one topic per user in my google console project and also creating one subscription per topic. As per my knowledge we cannot make more than 10,000 topics and subscriptions in one project(GCP). My question is that can we increase this limit. I want to increase it to 100k or 10 million. Is it possible. If yes kindly suggest some resources or references, where I can read about it.
At this time, the 10,000 topics and subscriptions limit cannot be increased. It is a dimension we'd like to scale up at some point, but for now, this is not a quota for which one can request an increase.
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.