计算 firebase 消息大小答案

【问题标题】：Computing firebase message size计算 firebase 消息大小
【发布时间】：2017-01-05 11:09:56
【问题描述】：

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

我注意到在运行实时数据库计算器时显示的数据量比预期的要大。为了验证这一点，我启动了一个玩具应用程序，它有一个名为“test”的单个 ref 和数据：

{"foo": "bar"}

继续其他答案，我估计此数据小于 20 字节。

使用此代码检索数据：

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

这是jsfiddle showing this toy example。

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

还发送了哪些其他数据来解决预期数据使用量（10 * 20 字节 = 200 字节）与实际发送的 30KB 之间的巨大差距？

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

编辑：

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

     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

所以似乎任何消息都有 ~200-250 字节的开销。谁能证实这一点？这仍然不能完全解释我之前提到的差距（10 条消息 * 250 字节 = 2.5 KB 与记录的 30 KB）。

更新：

当前带宽使用量高达 155 KB。我不确定这篇文章有 35 位观众怎么可能达到这个数字。为了尝试了解这一点（我仍然不确定带宽的实际计算方式），以下是我的想法：

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.

所以要达到 155 KB，要么发送了超过 100 次，要么存在一些无法解释的开销。另外，我假设（我不知道）初始化的开销是 200 字节，发送任何消息的开销是 200 字节。

【问题讨论】：

如果您使用的是 Chrome，您可以使用开发工具观察实际的 websocket 流量。您可能会发现它很有用。
是的，我们也有同样的问题：stackoverflow.com/questions/41471842/…
这里也有同样的问题：stackoverflow.com/questions/38959321/…

标签： javascript firebase firebase-realtime-database

【解决方案1】：

我进行了更多测试（读取 22 个字节），并认为计算带宽时可能存在错误。如果不是，则重新加载时的带宽速率非常大。这是我的测试：

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

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

我在等待一个半小时后进行了第二次测试，以便实时数据库使用情况可以更新。

测试 2 包含我认为可能存在的错误：

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

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

我很确定这个用例很容易重现。我不会赞成这个，因为它不是一个真正的答案，它只是给出了更多的问题，但这是我在运行这些测试用例时发现的。

谢谢

【讨论】：