【问题标题】:Do Firebase streaming REST connections count against the concurrent connection limit?Firebase 流式传输 REST 连接是否计入并发连接限制?
【发布时间】:2015-03-30 01:42:08
【问题描述】:

recent question 中,有人指出Firebase pricing documentation 声明:

REST API 请求不计入您的连接限制

我理解(并赞赏)此声明的含义:针对 REST API 的 GET、PUT、POST 和 DELETE 请求通常用于对数据的非实时操作,例如下载数据备份或批量计算。这些通常是不常见的、相对短暂的操作,通常应该会使实时数据连接的数量相形见绌。

但当我们查看Firebase's REST streaming API 时,情况就不同了。与 REST API 的其余部分不同,流式传输显然是为实时数据连接而设计的。

根据上面引用的文档,这些连接不应计入连接限制。但是根据comment by a Firebase developer on Google Groups

并发 [连接] 是实时客户端或流式 REST

我强调的部分似乎表明使用流式 REST API 的客户端确实计入连接限制。

为了测试,我编写了一个小型 C# 客户端,它使用 Firebase REST 流 API 来监控节点:

var url = "https://<my>.firebaseio.com/clock/.json";

var client = new WebClient();
client.Headers["Accept"] = "text/event-stream";
using (var stream = client.OpenRead(url)) {
    using (var reader = new StreamReader(stream)) {
        string line = null;
        while (null != (line = reader.ReadLine())) {
            (DateTime.Now.ToShortTimeString() + line).Dump();
        }
    }
}

在启动此程序后大约 15 分钟,我的 Firebase 仪表板中的并发连接确实增加了 1。运行第二个实例,仪表板中的并发连接数再次增加。

因此,此测试似乎证实了 Google 网上论坛上的暗示:REST 流式客户端算作并发连接。有人可以确认这一点或发现我的测试中的缺陷吗?

【问题讨论】:

    标签: c# rest firebase firebase-realtime-database


    【解决方案1】:

    您在这里的假设是正确的。通过 REST API 进行的 流式传输 调用确实会按照逻辑上应计入并发计数(即它们保持打开的套接字连接并创建额外的负载)。针对 REST API 的非流式调用算作并发连接。

    我会看一下定价页面,看看我们是否可以让文字更清晰一些。

    【讨论】:

      猜你喜欢
      • 2014-01-31
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-05-16
      • 2021-02-26
      • 1970-01-01
      • 2012-01-21
      • 1970-01-01
      相关资源
      最近更新 更多