Bigquery流插入，持久还是新的http连接在每个插入上？

Question

我将google-api-ruby-client用于流到BigQuery中。所以每当有请求的时候。它作为队列被推入Redis &然后一个新的塞迪基克工作人员试图插入到bigquery中。我认为这涉及在每次插入时打开到bigquery的新HTTPS连接。

我设置的方式是:事件每1秒发布一次，或者当批处理大小达到1MB (1MB)时，以先发生者为准。这是针对每个工作人员的，因此Biquery可能通过多个HTTPS连接每秒接收数十个HTTP帖子。

这是使用Google提供的API客户端完成的。

现在的问题是--对于流插入，更好的方法是：

1. 持久HTTPS连接。如果是，那么应该是一个在所有请求之间共享的全局连接吗？还是别的什么？
2. 打开新连接。就像我们现在使用google-api-ruby-client一样

Answer 1

我认为现在谈论这些优化还为时尚早。另外，还缺少其他上下文，比如是否耗尽了内核的TCP连接。或者有多少连接处于TIME_WAIT状态，等等。

1. 在同一台计算机上的工作池没有达到每秒1000个连接之前，您应该坚持库提供的默认模式。

否则，这将需要很多其他的上下文和深入的理解这是如何工作的，以便在这里优化一些东西。

1. 另一方面，可以将更多的行批次到同一个流插入请求，限制中，如下所示：

最大行大小:1MB

HTTP请求大小限制: 10 MB

每秒最大行数:每秒100,000行，每个表。

每次请求的最大行数: 500行

每秒最大字节数:每秒100 MB，每个表

1. 阅读我的其他建议，Google BigQuery:慢流插入性能

我还将努力给出上下文，以便更好地理解港口用尽时的复杂情况：

比方说，在一台机器上，每秒有30,000个端口和500个新连接(典型)：

1 second goes by you now have 29500 
10 seconds go by you now have 25000 
30 seconds go by you now have 15000 
at 59 seconds you get to 500, 
at 60 you get back 500 and stay at using 29500 and that keeps rolling at 
29500. Everyone is happy. 

现在假设平均每秒看到550个连接。突然之间，没有可用的端口可供使用了。

因此，您的第一个选择是扩大允许的本地端口的范围；非常容易，但是即使您尽可能多地打开它，从1025年到65535，仍然只有64000个端口；使用60秒的TCP_TIMEWAIT_LEN，平均可以维持每秒1000个连接。仍然没有使用持久连接。

这里更好地讨论了这个端口排气：http://www.gossamer-threads.com/lists/nanog/users/158655