Javascript 计算firebase消息大小

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

我在运行实时数据库计算器时注意到，它显示的数据大小超出了预期。为了验证这一点，我启动了一个玩具应用程序，它有一个名为“test”的引用，其中包含以下数据：

{"foo": "bar"}

至于其他答案，我估计这些数据不到20字节

使用以下代码检索数据：

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

这是一本书

我抓取ref和console.log数据。我不到10次访问过这个示例。当我查看toy应用程序的实时数据库使用选项卡时，它显示了使用的30KB带宽

由于预期数据使用量（10*20字节=200字节）与实际发送的30KB之间存在较大差距，正在发送哪些其他数据

初始化增加数据使用量的应用程序时，是否存在初始开销

编辑：

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

因此，似乎任何消息都有大约200-250字节的开销。有人能证实这一点吗？这仍然不能完全解释我前面提到的差距（10条消息*250字节=2.5 KB，而记录的30 KB）

更新：

当前带宽使用率高达155KB。我不知道这个数字怎么可能，因为这篇文章有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. 

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

我已经运行了一些测试（读取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包含我认为可能存在的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

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

我非常确信这个用例很容易复制。我不打算对此进行投票，因为这并不是一个真正的答案，它只是给出了更多的问题，但这正是我在运行这些测试用例时发现的

---

谢谢

如果您使用的是Chrome，您可以使用开发工具观察实际的websocket流量。您可能会发现它很有用。是的，我们有相同的问题：这里也有相同的问题：

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