本指南說明根據 RTB 通訊協定開發應用程式時，可參考的最佳做法。
管理連線
保持連線
建立新連線會增加延遲時間，而且相較於重複使用現有連線，會耗用更多資源。只要關閉較少的連線，您可以減少必須再次開啟的連線數量。
首先，建立每個新連線時，都需要額外的網路往返時間。由於我們是依照需求建立連線，因此連線的第一個要求效期較短，而且比後續要求更可能逾時。任何額外的逾時都會增加錯誤率，進而可能導致您的出價工具受到節流。
其次，許多網路伺服器都會針對建立的每個連線產生專屬的工作站執行緒。也就是說，如要關閉並重新建立連線，伺服器必須先關閉並捨棄執行緒、分配新執行緒、使其可執行，以及建構連線狀態，最後再處理要求。因而產生大量不必要的負擔
避免關閉連線
請先調整連線行為。大多數的伺服器預設值都是針對具有大量用戶端的環境量身打造，每個環境都會提出少量要求。相對來說，如果是即時出價，一小群機器會代表大量瀏覽器傳送要求。在這些情況下，最好盡可能重複使用連線。建議您設定：
- 閒置逾時設為 2.5 分鐘。
- 連線的要求數量上限 (可能值)。
- RAM 可以容納的連線數量上限，但須小心確認連線數量並未太接近該值。
以 Apache 為例，這會將 KeepAliveTimeout 設為 150，將 MaxKeepAliveRequests 設為 0，並將 MaxClients 設為依附伺服器類型的值。
連線行為調整完畢後，您也應該確保出價工具程式碼不會無謂關閉連線。舉例來說，如果您的前端程式碼在後端錯誤或逾時時傳回預設的「沒有出價」回應，請確保程式碼在不關閉連線的情況下傳回回應。這樣一來，您就能避免在出價工具超載、連線開始關閉及逾時次數增加的情況下，導致出價工具受到節流影響。
保持連線平衡
如果 Authorized Buyers 透過 Proxy 伺服器連線至您的出價工具伺服器，連線可能會隨著時間不平衡，因為只能得知 Proxy 伺服器的 IP 位址，Authorized Buyers 無法判斷接收每個呼叫的出價方伺服器。隨著 Authorized Buyers 建立及關閉連線，且出價方的伺服器重新啟動後，對應至各個連線的連線數量可能會變得十分變動。
當某些連線大量使用時，其他已開啟的連線大多因為當時不需要而處於閒置狀態。隨著 Authorized Buyers 流量變化，閒置的連線會變為有效連線，而有效連線可能會進入閒置狀態。如果連線叢集品質不佳，這些情況可能會導致出價工具伺服器的負載不平均。為了防範這種情況，Google 會在要求 10,000 次後關閉所有連線，以隨著時間自動重新平衡熱連線。如果您發現環境中的流量仍不平衡，則可採取其他步驟：
- 如果您使用的是前端 Proxy，請為每項要求選取後端，而非每個連線一次。
- 如果您要透過硬體負載平衡器或防火牆發出 Proxy 連線，且在連線建立後已固定完成，請指定每個連線的要求數量上限。請注意，Google 已將每個連線的要求數量上限設為 10,000 個，因此如果您依然在自己的環境中發現熱線叢集建立為叢集，才需要提供較嚴格的值。以 Apache 為例，將
MaxKeepAliveRequests設為 5,000 - 設定出價方的伺服器來監控其要求比率，如果與同業相比，如果持續處理太多要求，則關閉自己的一些連線。
妥善處理超載
在理想情況下，配額設定要夠高，這樣您的出價工具就能接收所有要求，但不超過這個值要求的數量。實際上，要將配額保持在最佳程度並不容易，而且會發生超載的原因可能有很多種：後端在尖峰期間停止運作、流量組合變更，導致每項要求需要進行更多處理，或是配額值太高。因此，建議您考量出價工具在流量過大時的行為。
為因應亞洲和美國西部和美國東部和美國西部區域之間的暫時流量轉移 (最多一週)，建議您將 7 天的尖峰間隔設為 15%，以及每個交易地點的 QPS。
以負載量繁重下的行為來說，出價工具分為三大類：
- 「回應一切」的出價工具
雖然實作方式簡單，但這個出價工具在超載時效能最差。這項工具只會嘗試回應收到的所有出價要求，無論是何種情況，都會將無法立即放送的出價要求排入佇列。會發生的情況通常如下：
- 隨著要求比率的攀升，請求的延遲時間也必須提高，直到所有要求都逾時為止
- 延遲在呼叫率接近峰值時突然提高
- 開始節流，大幅減少允許的呼叫數量
- 延遲時間開始恢復，導致節流減少
- 月經週期重新開始。
這個出價工具的延遲圖表類似於非常陡峭的模式。此外，佇列中的要求會導致伺服器啟動分頁記憶體，或執行導致長期減速的因素，而且在尖峰時間結束之前，延遲完全不會復原，導致整個峰值期間的呼叫頻率降低。無論是哪一種情況，進行的呼叫或回應次數都會比配額設為較低值時來得少。
- 「超載時發生錯誤」出價工具
此出價工具接受特定費率的呼叫，然後開始傳回部分呼叫的錯誤。這項作業可以透過內部逾時、停用連線佇列 (由 Apache 上的
ListenBackLog控制)、在使用率或延遲時間過高時實作機率下降模式，或其他機制。如果 Google 發現錯誤率超過 15%，就會開始進行節流。與「回應所有問題」的出價工具不同，這個出價方會「減少損失」，在要求率降低時立即復原。這個出價工具的延遲時間圖表類似於超載期間的淺鋸齒模式，並且已調整為可接受的最高速率。
- 「超載時沒有出價」出價工具
此出價工具接受特定費率的呼叫，然後針對任何超載開始傳回「沒有出價」回應。與「超載時發生錯誤」的出價工具類似，可以透過多種方式實作。差別在於系統不會傳回任何信號給 Google，因此我們絕不會限縮呼叫範圍。超載會由前端機器吸收，只允許他們能夠處理的流量繼續傳遞至後端。
這個出價工具的延遲時間圖表顯示一個高原 (手動) 在尖峰時間停止平行處理要求率，包含出價的回應比例也會相對下降。
建議您透過下列方式結合「超載時發生錯誤」與「超載時沒有出價」的方法：
- 超額佈建前端，並設定為在超載時發生錯誤，以盡可能提高其以某些形式回應的連線數量。
- 超載發生錯誤時，前端機器可以使用制式「沒有出價」回應，不需要剖析請求。
- 導入後端健康狀態檢查，如果可用容量不足，系統會傳回「沒有出價」回應。
這樣做可以讓系統吸收部分超載，並讓後端能根據能夠處理的要求盡可能回應所需的要求。您可以將這種情況視為「超載時沒有出價」，前端機器會在要求數量明顯高於預期時，改回「超載時發生錯誤」。
如果您有「回應一切」的出價工具，請考慮調整連線行為，將其轉換為「超載時發生錯誤」出價工具，以便影響超載。雖然這樣會導致系統傳回更多錯誤，但這能減少逾時，同時避免伺服器進入無法回應任何要求的狀態。
回應連線偵測 (ping)
偵錯時，請務必確保您的出價工具可以回應連線偵測 (ping) 要求，而非個別的連線管理機制。Google 會使用連線偵測要求，針對出價工具狀態、連線關閉行為、延遲等情況進行健全性檢查和偵錯。連線偵測 (ping) 要求的形式如下：
id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true
OpenRTB JSON
"id": "4YB27BCXimH5g7wB39nd3t"
OpenRTB Protobuf
id: "7xd2P2M7K32d7F7Y50p631"
請注意，連線偵測 (ping) 要求並未包含任何廣告版位，但與您預期的不同。如上方所述，回應連線偵測要求後，請勿關閉連線。
考慮對等互連
另一個減少網路延遲或變異性的方法，是與 Google 對等互連。透過對等互連，將流量到達出價工具的路徑最佳化。連線端點維持不變，但中繼連結會改變。詳情請參閱對等互連指南。我們將對等互連視為最佳做法的原因摘要如下：
在網站上，系統主要是透過「熱馬鈴薯轉送」選擇大眾運輸連結，這會找出我們的網路之外的最接近連結，可將封包接收到其目的地，並透過該連結轉送封包。當流量通過我們擁有許多對等互連連線的供應商所擁有的骨幹部分時，所選連結可能就很接近封包起點。除此之外，我們也無法控制封包指向出價方的路徑，因此封包可能會在過程中退回其他自主系統 (網路)。
相對地，如果設有直接對等互連協議，封包一律會透過對等互連連結傳送。無論封包來自何處，它都會週遊 Google 擁有或租用的連結，直到到達共用對等互連點，而該連結應該靠近出價工具的位置。反向行程一開始會短暫跳到 Google 網路，然後繼續留在 Google 網路中。只要將大部分的行程保留在 Google 代管的基礎架構上，封包就會採用低延遲的路徑，同時避免大量的潛在變異性。
提交靜態 DNS
我們建議買家一律向 Google 提交單一靜態 DNS 結果，並由 Google 處理流量傳送。
以下是出價方 DNS 伺服器在嘗試負載平衡或管理可用性時的兩種常見做法：
- DNS 伺服器會將一個或部分位址分派給查詢，然後以一些方式循環處理這個回應。
- DNS 伺服器一律會回應同一組位址，但會在回應中循環排列位址的順序。
由於 Google 會向出價方收取 DNS 解析時間，因此第一種技術在負載平衡方面較差，因為堆疊有許多層級的快取，而嘗試略過快取也可能無法獲得偏好的結果。
第二項技術完全無法實現負載平衡，因為 Google 會從 DNS 回應清單中隨機選取 IP 位址，因此回應中的順序無關。
如果出價方做出 DNS 變更，Google 會遵循 DNS 記錄中設定的 TTL(存留時間)，但重新整理間隔仍不明確。