Computing firebase message size

Question

I am trying to compute the size of messages in firebase in order to accurately estimate the cost of my app.

I noticed when running that the realtime database calculator was showing larger than expected data sizes. To verify this, I started a toy application that has a single ref called "test" with the data:

{"foo": "bar"}

Going on other answers, my estimate is that this data is under 20 bytes.

Retrieving the data with this code:

firebase.database().ref("test").once("value", function(snapshot) {
  console.log(snapshot.val());
});

Here is a jsfiddle showing this toy example.

I grab the ref and console.log the data. I have accessed this example under 10 times. When I look at the toy application's realtime database usage tab, it shows something like 30KB bandwidth used.

What other data is being sent to account for this large gap in expected data usage (10 * 20 bytes = 200 bytes) vs the actual 30KB sent?

Is there some initial overhead when initializing an app that adds to the data usage?

EDIT:

Following cartant's advice, I logged the frames being sent from the websocket. Here is what I found (Before this I see some initialization messages of about 200 bytes):

     Data                                                        Length    
     {"t":"d","d":{"r":22,"a":"q","b":{"p":"/test","h":""}}}     55 
     {"t":"d","d":{"b":{"p":"test","d":{"foo":"bar"}},"a":"d"}}  58 
     {"t":"d","d":{"r":23,"a":"n","b":{"p":"/test"}}}            48 
     {"t":"d","d":{"r":22,"b":{"s":"ok","d":{}}}}                44 
     {"t":"d","d":{"r":23,"b":{"s":"ok","d":""}}}                44

So it seems like there is a ~200-250 byte overhead for any message. Can anyone confirm this? This still does not fully explain the gap I mentioned earlier (10 messages * 250 bytes = 2.5 KB vs the 30 KB recorded).

UPDATE:

The current bandwidth usage is up to 155 KB. I am not sure how this number is possible with 35 viewers on this post. In order to try to get a sense of this (I am still not sure how bandwidth is actually calculated), here are my thoughts:

200 bytes to initialize/connect
220 bytes per message (200 bytes of overhead + 20 bytes in message)
100 times sent (this is probably an overestimate, as there are 35 views on this post, but I have viewed it around 10 times myself)

(200 bytes + 220 bytes) * 100 views = 42000 bytes or 42 KB. 

So to get to 155 KB either this was sent much more than 100 times, or there is some unexplained overhead. Also, I assume (which I do not know) that the overhead to initialize is 200 bytes and the overhead to send any message is 200 bytes.

Answer 1

I've run some more tests (reading 22 bytes) and think there is a possible bug in calculating bandwidth. If not, then the bandwidth rates on reload are very large. Here are my tests:

Test 1 (600 requests of 22 bytes with only one initial connect to the page)

83 KB total for 600 requests
83 KB = 83,000 bytes / 600 requests = 138.33 bytes per request
data sent = 22 bytes
138.33 bytes - 22 bytes = 116.33 bytes overhead per message sent

Which is reasonable and pretty good (although this does not seem to be factored in on firbase's pricing page).

I ran the second test after waiting for an hour and a half so the realtime database usage could update.

Test 2 contains what I think may be a bug:

Test 2 (20 page reloads sending one request) 

96 KB total for 20 page reloads + 20 requests
96 KB / 20 = 4.8 KB per reload

I do not think this can be correct, which leads me to believe that there is a bug in the data usage portion of the realtime database. I noticed when refreshing that the data used would climb by around 2-4kb (I only have 22 bytes stored).

I am pretty sure that this use case is easily reproducible. I am not going to upvote this as its not really an answer, it just gives more questions, but it is what I found when running these test cases.

Thanks