為符合 Real-time Curation 服務的延遲限制，請將伺服器放置在最有可能將區隔要求傳送至目標位置的Google Cloud 區域附近。佈建及設定 DNS，確保從特定區域傳送至端點的流量會轉送至最近的伺服器。
下表列出 Real-time Curation 使用的 Google Cloud 地區、大致位置，以及最有可能從這些地區傳送至伺服器的目標位置範例 (以 SegmentRequest 表示)：
| Google Cloud 區域 | 區域位置 | 目標位置範例 |
|---|---|---|
| us-east1 | 美國南卡羅來納州 | 北美洲 (東岸) |
| us-west1 | 美國奧勒岡州 | 北美洲 (西岸) |
| us-central1 | 美國愛荷華州 | 北美洲 (中部) |
| europe-west1 | 比利時 | 歐洲 |
| europe-west4 | Amsterdam, Netherlands | 歐洲 |
| asia-southeast1 | 新加坡 | 亞洲 |
| asia-east1 | 台灣 | 亞洲 |
使用 HTTP 永久連線來縮短延遲時間
為減少延遲，Google 強烈建議您將 Real-time Curation 整合功能設為使用持續性連線。建立持續性連線後，端點會重複使用連線，而不是為每個傳入的區隔要求建立新連線。
伺服器位置
雖然您可以預期大部分區隔要求都是從最接近使用者所在位置的區域傳送，但 Google 無法保證一律如此。伺服器位置越靠近多個區域，您就越有可能收到指定地區的完整片段要求。Google 建議將伺服器放置在適合目標位置的部分區域附近。舉例來說，只要將伺服器放在 us-east1、us-west1 和 us-central1 區域附近，就能接收大部分的北美洲流量。
你必須在 50 毫秒內傳送區段回應。
這個期限包含區域與伺服器之間的網路時間，以及伺服器建構回應的時間。建議您至少要有 10 毫秒的緩衝時間，以因應網路延遲的意外變化。
後續步驟
- 即時收錄通訊協定參考資料：瞭解即時收錄中使用的要求和回應結構。
- 剖析即時收錄要求： 瞭解如何剖析即時收錄要求。
- 建立即時收錄回應： 瞭解如何建立即時收錄回應。