计算Firebase消息大小 [英] Computing firebase message size

问题描述

我试图计算firebase中消息的大小，以便准确地估计我的应用程序的成本。

我注意到运行时，实时数据库计算器是显示大于预期的数据大小。为了验证这一点，我开始了一个玩具应用程序，它有一个名为测试与数据的裁判：

  {foo ：bar} 
  

回到其他答案，我估计这个数据是在20个字节以下。

使用以下代码检索数据：

  firebase.database ）.ref（test）。once（value，function（snapshot）{
 console.log（snapshot.val（））; 
}）; 
  

这是。

我抓取了ref和console.log的数据。我已经访问了10次这个例子。当我查看玩具应用程序的实时数据库使用情况标签时，它显示了30KB的带宽。

还有哪些数据正在发送，以解决预期数据使用（10 * 20字节= 200字节）与发送的实际30KB？

在初始化应用程序时是否有一些初始开销增加了数据使用？

编辑：

遵循cartant的建议，我记录了从websocket发送的帧。这是我找到的（在此之前，我看到一些约200字节的初始化消息）：

pre code数据长度
{ T： d， d：{ R：22， A： q， b：{ p： /测试， H： }}} 55
{t：d，d：{b：{p：test，d：{foo：bar}} ：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：}}}

所以好像有一个〜200-250字节开销的任何消息。任何人都可以确认吗？这仍然不能完全解释我之前提到的差距（10条消息* 250字节= 2.5 KB，而30 KB记录）。

更新：

目前的带宽使用量高达155 KB。我不确定这个数字是如何与35个观众在这个职位上。为了试图了解这一点（我还不确定带宽是如何计算的），下面是我的想法：

$ $ $ $ $ $ c> 200字节来初始化/连接
每个消息220字节（开销200字节+消息20字节）
发送100次（这可能被高估了，因为这个帖子有35个视图，但是我已经看了10次左右）

（200字节+ 220字节）* 100视图= 42000字节或42 KB。

所以要达到155 KB，要么发送超过100次，要么有一些不明原因的高架。另外，我假设（我不知道）初始化的开销是200字节，并且发送任何消息的开销是200字节。

解决方案我已经运行了一些更多的测试（读取22个字节），并认为在计算带宽中可能存在一个错误。否则，重新加载的带宽速率非常大。这里是我的测试：

 测试1（600个请求22个字节，只有一个初始连接到页面）
 
总计600 KB请求
 83 KB = 83,000字节/ 600请求=每请求138.33字节
数据发送= 22字节
 138.33字节 -  22字节= 116.33字节开销消息发送
  

这是合理和相当不错的（尽管这似乎没有考虑firbase的定价页）。

我在等了一个半小时之后跑了第二个测试，所以实时数据库的使用情况可能会更新。 >测试2包含我认为可能是一个错误︰

 测试2（20页重新发送一个请求）
 
共20页重新加载+ 20次请求总共96 KB 
 96 KB / 20 = 4.8 KB每次重新加载$ ​​b $ b  

我不认为这是正确的，这使我相信实时数据库的数据使用部分存在一个错误。我注意到，刷新时使用的数据将爬上大约2-4kb（我只有22个字节存储）。

我很确定这个用例很容易重现。我不打算把它看作是一个答案，它只是给出了更多的问题，但这正是我在运行这些测试用例时发现的。

谢谢

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.

解决方案

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

这篇关于计算Firebase消息大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！