2015-10-11 37 views
0

我爲Streaming Data Into BigQuery使用google-api-ruby-client。所以只要有請求。它作爲隊列被推入Redis &然後新的Sidekiq工作人員嘗試插入到bigquery中。我認爲它涉及到每插入一個新的HTTPS連接到bigquery。Bigquery流插入,每個插入持久或新的http連接?

我的設置是: 事件每隔1秒發佈一次或批量大小達到1MB(1兆字節)時,以先發生者爲準。這是每個工作人員,因此Biquery API可能會在多個HTTPS連接上每秒接收數十個HTTP帖子。

這是使用Google提供的API客戶端完成的。

現在的問題 - 對於流插入,什麼是更好的方法: -

  1. 持續HTTPS連接。如果是的話,那麼它應該是一個全局連接,並在所有請求之間共享?或者是其他東西?
  2. 打開新的連接。就像我們現在正在使用的那樣google-api-ruby-client

回答

1

我認爲早期談論這些優化是非常值得的。如果你耗盡了內核的TCP連接,也會丟失其他上下文。或者有多少個連接處於TIME_WAIT狀態等等。

  1. 直到工人池不會在同一臺機器上達到每秒1000個連接,您應該使用默認模式下貼庫提供

否則這將需要很多其他方面和深層次的理解這是如何工作的,以便在這裏優化某些東西。

  • 在另一方面可以批量更多行到同streaming insert requests, the limits是:
  • 最大行大小:1 MB
    HTTP請求大小限制:10 MB
    每秒最大行數:每個表格每秒100,000行。
    每個請求的最大行數:每秒500個
    最大字節數:每秒100 MB,每個表

  • 讀我的其他建議 Google BigQuery: Slow streaming inserts performance

  • 我會嘗試給出上下文以更好地理解端口用盡時的複雜情況:

    讓我們假設在一臺機器上有一個池每秒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