How the Connection is calculated in Firebase

How are the connections are being calculated?

Let's assume that I have a web app which one load sends a message to all connected clients, and let's say I have 5 connected clients. Does it means that as long as the browser tab with the web app is open it will count as 1 connections, which means that I will have 6 concurrent connections and that's count towards what you define as "Connection" in the pricing page?

If not, please explain how you calculate the "Connection". Thanks


Solution 1:

This question was bugging me ever since I ran through the thinkster.io angular+firebase tutorial and I saw my firebase analytics tab showing a peak concurrent of 6 even though I only remember having the one page open. I looked back at the code and thought it could be to do with how the tutorial has you create a new Firebase(url) for each location in your firebase.

I wanted to test the difference between creating a new Firebase(url) vs taking the root reference and then accessing the .child() location. My theory was that new Firebase(url) would create a new connection each time, while .child() would re-use the existing connection.

Setup

  • Created two new firebases each with identical data
  • Setup an angularjs project using yeoman
  • Included angularfire

Code

For simplicity, I just put everything in the main controller of the generated code.

To test out the connections created with new Firebase() I did the following:

$scope.fb_root = $firebase(new Firebase(FBURL_NEW));
$scope.fb_root_apps = $firebase(new Firebase(FBURL_NEW + '/apps'));
$scope.fb_root_someApp = $firebase(new Firebase(FBURL_NEW + '/apps/someApp'));
$scope.fb_root_users = $firebase(new Firebase(FBURL_NEW + '/users'));
$scope.fb_root_mike = $firebase(new Firebase(FBURL_NEW + '/users/mike'));

To test out the connections created with ref.$child() I did the following:

$scope.fb_child = $firebase(new Firebase(FBURL_CHILD));
$scope.fb_child_apps = $scope.fb_child.$child("apps");
$scope.fb_child_someApp = $scope.fb_child_apps.$child("someApp");
$scope.fb_child_users = $scope.fb_child.$child("users");
$scope.fb_child_mike = $scope.fb_child_users.$child("mike");

I then bound these objects in my view so I can see them, and I played around with updating data via my firebase forge and watching the data update live on my app.

Results

I opened up my local app into 17 browser tabs, hoping that a large number of tabs would exaggerate any differences between the connection methods.

What I found is that each tab only opened up one single web socket connection back to firebase for each firebase db. So at the end of the test, both methods resulted in the same peak count of 17 connections.

Conclusion

From this simple test I think it's safe to say that the Firebase JS library does a good job of managing its connection.

Regardless of your code calling new Firebase() a bunch of times, or by referencing child locations via .child(), the library will only create a single connection as far as your metering is concerned. That connection will stay online for as long as your app is open.

So in your example - yes I believe you will see 6 concurrent connections, 1 for the app where someone is sending the message, and 5 for the apps receiving the message.

Update

One other thing worth mentioning is that Firebase measures connections for paid plans based on the 95th percentile of usage during the month. This is listed in the FAQ section of their Pricing page @ https://www.firebase.com/pricing.html

Update 11-Mar-16: Firebase no longer appears to measure connections based on 95th %. Instead, the 101st concurrent connection is denied.

https://www.firebase.com/pricing.html :

All our plans have a hard limit on the number of database connections. Our Free and Spark plans are limited to 100. The limit cannot be raised. All other plans have a courtesy limit of 10,000 database connections. This can be removed to permanently allow Unlimited connections if you email us at [email protected].. The reason we impose this courtesy limit is to prevent abuse and to ensure that we are prepared to handle our largest customers. Please contact us at least 24 hours in advance so we can lift this limit and ensure we have enough capacity available for your needs.