即時出價應用程式最佳做法

本指南將說明開發應用程式時應考量的最佳做法 根據即時出價通訊協定而定

管理連線

保持連線

建立新連線會增加延遲時間，且在兩端使用比重複使用現有連線所需的資源多得多。關閉的連線數越少，就越少需要重新開啟的連線。

第一，每次新連線都需要額外的網路往返時間 建立。由於我們會視需要建立連線，連線的第一個要求有效期限較短，因此比起後續要求，更有可能逾時。任何額外的逾時都會提高錯誤率，進而導致出價方受到節流。

第二，許多網路伺服器會為每個連線產生專屬的背景工作執行緒 長期來看待開發也就是說，如要關閉並重新建立連線，伺服器必須關閉並捨棄執行緒、分配新的執行緒、讓其可執行，並建立連線狀態，最後再處理要求。這會造成許多不必要的負載。

避免關閉連線

請先調整連線行為。大多數伺服器預設值都是針對擁有大量用戶端的環境所量身打造，每個用戶端都會發出少量要求。相較之下，RTB 會由少數機器代表大量瀏覽器傳送要求。在這些情況下，建議盡可能重複使用連線。建議您設定下列項目：

• 閒置逾時時間設為 2.5 分鐘。
• 將連線上的要求數量上限設為最高可能值。
• RAM 可連線的最大連線數上限 並謹慎確認連線數量 並未過於接近該值

以 Apache 為例 KeepAliveTimeout 到 150，MaxKeepAliveRequests 到 ，且 MaxClients 的值會視伺服器類型而定。

連線行為調整完畢後，您應該確定 出價工具程式碼不會無端關閉連線。舉例來說，如果您的前端程式碼在後端錯誤或逾時的情況中傳回預設的「無出價」回應，請確定程式碼是在未關閉連線的情況下傳回回應。如此一來，就不會在出價工具發生下列情況時避免情況 超載、連線開始關閉、逾時數目增加。 導致出價工具受到節制

保持連線平衡

如果 Authorized Buyers 連線至您的出價方伺服器 這些連線可能會在一段時間後變得不平衡 因為只要知道 Proxy 伺服器的 IP 位址 無法判斷收到每個呼叫的出價工具伺服器。 隨著時間的推移，Authorized Buyers 會在建立後結束 連線以及出價方伺服器重新啟動時， 都可能變得很變動

當部分連線使用率很高時，其他已開啟的連線可能會處於閒置狀態，因為當下並不需要這些連線。隨著授權買方的流量變化，閒置連線可能會變成有效連線，有效連線也可能會變成閒置連線。這些情況可能會導致出價工具伺服器上的負載量不均 是否會造成連線品質不佳Google 會在 10,000 次要求後關閉所有連線，以便自動重新平衡熱門連線。如果您仍發現環境中的流量不平衡，可以採取其他步驟：

1. 如果您使用前端 Proxy，請為每項要求選取後端，而非為每個連線選取一次。
2. 如果您是透過硬體負載平衡器或防火牆代理連線，且連線建立後對應項目會固定，請指定每個連線的要求數量上限。請注意，Google 已指定每個連線 10,000 個要求的上限，因此 只有在資料沒有熱度時 連線至您的環境以 Apache 為例 將「MaxKeepAliveRequests」設為 5,000
3. 設定出價方的伺服器來監控請求率，並關閉部分 因自己的人脈關係經常處理過多要求 與同業相比

妥善處理超載

理想情況下，配額應設為足夠高，讓出價方能夠接收所有可處理的要求，但不要超過這個數量。實務上，只將配額 要達到最佳狀態並不容易，而且有多種形式時會發生超載 後端在尖峰時段停止運作時，流量組合會有所變化， 每個要求都需要更多的處理程序，或者您才剛設定配額值 過高因此，您必須考量出價工具的行為模式 所以會有太多流量進來

因應暫時流量變化 (最多一週) 的區域間 (尤其是亞洲、美國西部與美國東部與美國西部之間)， 建議您將尖峰時段的緩衝率設為 7 天，以及每次交易的 QPS 之間的 15% 位置。

以高負載下發生的行為而言，出價方可分為三大類 類別：

「回覆所有問題」出價方

雖然易於導入，但這個出價工具在 超載。無論如何，它都會嘗試回應收到的每項出價請求，並將無法立即放送的請求排入佇列。接著發生的情況通常如下所示：

• 要求比率會隨著要求比率提高 開始逾時
• 隨著呼叫率接近峰值，延遲時間會急遽上升
• 開始進行節流，大幅減少允許的說明文字數量
• 延遲時間開始恢復，導致節流減少
• 週期重新開始。

這個出價工具的延遲圖形看起來像非常陡峭的鋸齒狀 。另外，佇列要求會導致伺服器開始分頁記憶體或執行其他導致長期減速的動作，且延遲時間直到尖峰時間結束後才會恢復，導致整個尖峰期間的呼叫率降低。無論是哪種情況，摘要的摘要數量也比較少 比起將配額設為較低值時，您能做出不同的回應。

「error on overload」出價方

這個出價方接受特定費率的摘要，然後開始傳回 錯誤。這可以透過內部逾時、停用連線佇列 (由 Apache 上的 ListenBackLog 控制)、在使用率或延遲時間過高時實作機率性捨棄模式，或透過其他機制來達成。如果 Google 觀察到錯誤率超過 15%，就會開始限流。與「回應所有」出價方不同，這個出價方會「減少損失」，因此在請求率下降時，可以立即復原。

在超載期間，此出價方延遲時間的圖表會呈現淺淺的鋸齒狀圖案，並在可接受的最高頻率附近本地化。

「no-bid on overload」出價方

這個出價工具會接受最多一定數量的說明文字，然後開始傳回「沒有出價」回應，以便處理任何超載情況。類似「超載時發生錯誤」出價方 而且有多種執行方式差異在於不會向 Google 傳回信號，因此我們不會限制說明文字。 前端機器會吸收超載，因此只會允許流量 以便繼續前往後端

這位出價方延遲時間的圖表顯示，在尖峰時段，系統會 (人為地) 停止並平行處理要求率，而包含出價的回應比例也會相應下降。

建議您將「超載時發生錯誤」與「超載時不出價」做法結合，如下所示：

• 超額佈建前端，並將其設為在超載時發生錯誤，以便最大化它們能以某種形式回應的連線數量。
• 超載發生錯誤時，前端電腦可以使用罐頭「沒有出價」不需要剖析要求。
• 實作後端的健康狀態檢查，如果沒有任何後端有足夠的容量，則會傳回「無出價」回應。

如此即可吸收部分超載，並讓後端有機會 盡可能回應所有要求。您可以想到這個 「超載時沒有出價」前端機器則會改回使用「錯誤」模式 超載」要求數量大幅高於預期時

如果您有「回覆所有人」選項可以考慮轉換為 「超載時發生錯誤」出價工具來微調連線行為 拒絕超載這樣會讓系統傳回更多錯誤， 有助於縮短逾時時間，並防止伺服器進入伺服器狀態 無法回應任何要求。

回應連線偵測

確保出價工具可以在沒有連線的情況下回應連線偵測 (ping) 要求 執行偵錯時，顯然十分重要。Google 會使用 ping 要求，對出價方狀態、連線關閉行為、延遲時間等進行健全性檢查和偵錯。查詢要求的格式如下：

id: "7xd2P2M7K32d7F7Y50p631"

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true

請注意，與您預期的不同，ping 要求不包含任何廣告位址。如上方詳述，回應連線偵測 (ping) 要求後，請勿關閉連線。

考慮對等互連

另一種減少網路延遲時間或變化的方法，就是與 Google 對等互連。透過對等互連，您可以最佳化流量進入出價工具的路徑。連線端點保持不變，但中間連結會變更。詳情請參閱對等連線指南。 建議將對等互連視為最佳做法的理由摘要如下：

• 在網路上，轉接連結的選擇方式主要透過「熱點路由」(hot-potato routing)，這個方法會在 Google 網路外尋找最接近的連結，以便將封包傳送至目的地，並透過該連結將封包路由傳送。如果流量經過由我們有許多對等連線的供應商所擁有的骨幹網路部分，所選連結可能會位於封包開始的位置附近。在此之後，我們無法控制封包前往出價方的方式，因此封包可能會在途中轉送至其他自治系統 (網路)。

• 相反地，如果設定了直接對等互連協議，封包 一律透過對等互連連結傳送。無論封包來自何處，都會穿越 Google 擁有或租用的連結，直到到達共用對等點為止，該點應位於出價方位置附近。反向行程 會先短暫跳躍至 Google 網路，接著保留在 Google 整個網路將大部分的旅程保留在 Google 管理的基礎架構中，可確保封包採用低延遲路線，並避免許多潛在的變化。

提交靜態 DNS

我們建議買家一律向 Google 提交單一靜態 DNS 結果，並由 Google 處理流量。

以下是出價方 DNS 伺服器嘗試載入平衡或管理可用性時的兩種常見做法：

1. DNS 伺服器會針對查詢發出一個位址或位址子集，然後以某種方式輪流傳送回應。
2. DNS 伺服器一律會以相同的位址組合回應，但會循環回應中的位址順序。

第一種方法的負載平衡效果不佳，因為堆疊的多個層級都會快取大量資料，而且嘗試略過快取的做法可能也不會取得偏好的結果，因為 Google 會向出價方收取 DNS 解析時間費用。

第二種方法完全無法達到負載平衡，因為 Google 會隨機從 DNS 回應清單中選取 IP 位址，因此回應中的順序並不重要。

如果出價工具做出 DNS 變更，Google 將採用 但重新整理間隔仍不確定。