我正在使用google-api-ruby-client for Streaming Data Into BigQuery。因此，每当有请求时，它都会作为队列推送到Redis中，然后一个新的Sidekiq工作线程尝试插入到bigquery中。我认为这涉及到每次插入都打开一个新的HTTPS连接到bigquery。
我设置的方法是：事件每1秒或当批大小达到1 MB（一兆字节）时（以先发生者为准）发布一次。这是针对每个工作线程的，因此Biquery API可能会通过多个HTTPS连接每秒接收数十个HTTP发布。
这是使用Google提供的API客户端完成的。
现在的问题--对于流式插入，什么是更好的方法：-
1.持久的HTTPS连接.如果是，那么它应该是一个在所有请求之间共享的全局连接吗？还是其他什么？
1.正在打开新连接.就像我们现在使用google-api-ruby-client所做的那样
1条答案
按热度按时间vjrehmav1#
我认为现在谈论这些优化还为时过早。还有其他的上下文缺失，比如你是否耗尽了内核的TCP连接。或者有多少连接处于TIME_WAIT状态等等。
1.在同一台机器上的工作池没有达到每秒1000个连接之前，您应该坚持使用库提供的默认模式
否则，这将需要大量的其他上下文和深入了解它是如何工作的，以便优化这里的一些东西。
1.另一方面，您可以将更多行批量放入同一个streaming insert requests, the limits中：
最大行大小：1兆字节
HTTP请求大小限制：10兆字节
每秒最大行数：每个表每秒100，000行。
每个请求的最大行数：500
每秒最大字节数：每个表每秒100 MB
1.阅读我的其他建议谷歌BigQuery：流插入性能缓慢
我还将试图提供背景，以便更好地理解港口枯竭时的复杂情况：
假设在一台计算机上，您有一个包含30，000个端口的池，并且每秒有500个新连接（典型值）：
现在假设您看到平均每秒有550个连接，突然之间就没有可用的端口了。
因此，您的第一个选择是扩大允许的本地端口的范围;很简单，但是即使你尽可能地打开它，从1025增加到65535，那仍然只有64000个端口;使用60秒的TCP_TIMEWAIT_LEN，你可以维持平均每秒1000个连接。2仍然没有持久连接在使用中。
此端口排气最好在此处讨论：http://www.gossamer-threads.com/lists/nanog/users/158655