Firebase流式REST连接是否计入并发连接限制？ [英] Do Firebase streaming REST connections count against the concurrent connection limit?

问题描述

在最近的问题有人指出， Firebase定价文档指出：

REST API请求不计算在内对你的连接限制

我理解（并赞赏）这个语句的意思是：GET，PUT，POST和DELETE请求针对REST API通常用于对数据进行非实时操作，例如下载数据进行备份或批量计算。这些通常是不经常的，相对短暂的操作，并且一般来说应该使实时数据连接的数量减少。但是，当我们看 Firebase的REST流媒体API 。与REST API的其余部分不同，流式传输显然是用于实时数据连接的。根据上面引用的文件，这些连接不应该超出连接限制。但是根据Firebase开发者对Google网上论坛的的评论 ：
$ b

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

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

为了测试，我编写了一个小型的C＃客户端，它使用Firebase REST streaming 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（）; 
 
 
 
 
 
 $ b 
开始后约15分钟我的Firebase仪表板中的并发连接确实增加了1.运行第二个实例，再次增加了仪表板中的并发连接数。
 
 
 
所以这个测试似乎证实在Google网上论坛上暗示的是：REST流媒体客户端算作一个并发连接。有人可以证实这一点或在我的测试中发现缺陷吗？
通过REST API进行流式传输调用时，它们在逻辑上应该（即保持打开一个套接字连接并创建额外的负载）计数。针对REST API的非流式调用不会将计为并发连接。
 
 
 
我将查看定价页面，看看是否我们可以使文字更清晰一些。
 
In a recent question someone pointed out that the Firebase pricing documentation states:

  
REST API requests don't count towards your connection limits
I understand (and appreciate) this statement for what it seems meant for: GET, PUT, POST and DELETE requests against the REST API are typically used for non-real-time operations on the data, such as downloading the data for back-up or bulk calculations. These are typically infrequent, relatively short-lived operations and in general should dwarf the number of real-time data connections.

But that is different when we look at Firebase's REST streaming API. Unlike the rest of the REST API, the streaming is clearly intended for real-time data connections. 

According to the documentation quoted above, these connections should not count against the connection limit. But according to a comment by a Firebase developer  on Google Groups: 

  
concurrent [connections] are real-time clients or streamed REST
The part I emphasized seems to suggest that clients using the streaming REST API do count against the connection limit.

To test, I wrote a small C# client that uses the Firebase REST streaming API to monitor a node:
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();
        }
    }
}
About 15 minutes after starting this program the concurrent connections in my Firebase dashboard indeed went up by 1. Running a second instance, increased the concurrent connection count in the dashboard again.

So this test seems to confirm what was hinted at on Google Groups: REST streaming clients count as a concurrent connection. Can someone confirm this or spot a flaw in my test?
解决方案
Your assumptions here are correct. Streaming calls via the REST API do count against your concurrents count as they logically should (i.e. they are holding open a socket connection and creating additional load). Non-streaming calls against the REST API do not count as concurrent connections.

I'll have a look at the pricing page and see if we can make the text a bit clearer.

                        
这篇关于Firebase流式REST连接是否计入并发连接限制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！