In particular I would love to see the query size change in the real-time database. This could either be achieved by compressing the JSON response, or by calculating the traffic differently.
As a user of Firebase about a year ago I saw much, much higher egress traffic from the Real-time database than I expected. To be specific, for testing purposes I set up a note-taking app, which (being a test) had the database size of 31kb. But here comes the weird part: by querying the database exactly 10 times, my console was showing 24.5mb of traffic, which is much higher than 31*10=310kb/0.31mb.
Ultimately this caused me to change tracks to an open-source alternative, but if changes would be made on that front I'd be willing to take another dive into Firebase.
Hi, Tom from the Firebase Realtime database team here. To address the difficulties of figuring out where performance issues were, we made a database profiler (https://firebase.google.com/docs/database/web/profile). I expect that would help pinpoint where the issue was. My informed guess would be an index was not setup as you expected and the querying was being done client side, or my next guess would be the client was rapidly connecting and disconnecting. (check clientside with Firebase.database.enableLogging(true)).
The profiler excludes SSL overhead, but you can see usage inclusive of SSL in the webconsole.
I really appreciate the input, however the note taking example mentioned above was just a test project of mine. The actual project needs real-time synchronization, which isn't something I was expecting pouchdb/couchdb to be capable of.
Comments
In particular I would love to see the query size change in the real-time database. This could either be achieved by compressing the JSON response, or by calculating the traffic differently.
As a user of Firebase about a year ago I saw much, much higher egress traffic from the Real-time database than I expected. To be specific, for testing purposes I set up a note-taking app, which (being a test) had the database size of 31kb. But here comes the weird part: by querying the database exactly 10 times, my console was showing 24.5mb of traffic, which is much higher than 31*10=310kb/0.31mb.
Ultimately this caused me to change tracks to an open-source alternative, but if changes would be made on that front I'd be willing to take another dive into Firebase.
Hi, Tom from the Firebase Realtime database team here. To address the difficulties of figuring out where performance issues were, we made a database profiler (https://firebase.google.com/docs/database/web/profile). I expect that would help pinpoint where the issue was. My informed guess would be an index was not setup as you expected and the querying was being done client side, or my next guess would be the client was rapidly connecting and disconnecting. (check clientside with Firebase.database.enableLogging(true)).
The profiler excludes SSL overhead, but you can see usage inclusive of SSL in the webconsole.
It looks like you need an offline-first solution like pouchdb or rxdb. The traffic would have been around 31kb, no mather how much you query.
I really appreciate the input, however the note taking example mentioned above was just a test project of mine. The actual project needs real-time synchronization, which isn't something I was expecting pouchdb/couchdb to be capable of.