1

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?

enter image description here

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.

vir us
  • 9,920
  • 6
  • 57
  • 66

1 Answers1

2

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.

vir us
  • 9,920
  • 6
  • 57
  • 66