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

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

管理連線

保持連線

建立新的連線會增加延遲，耗費更多心力 資源比重複使用現有資源更是少減少關閉狀態 可以減少需要使用的連線數量 可以選取「重新建立」，再次生成新的提示

第一，每次新連線都需要額外的網路往返時間 建立。由於我們是按照需求建立關係，因此第一個請求 連線的有效期限較短，而且可能在 後續要求任何額外的逾時都會提高錯誤率， 您的出價工具受到節制

第二，許多網路伺服器會為每個連線產生專屬的背景工作執行緒 長期以來的目標這表示如要關閉並重新建立連線 必須關閉並捨棄執行緒、分配新的執行緒、讓執行緒可以執行。 建立連線狀態，最後再處理要求。可真多 不必要的額外負擔

避免關閉連線

請先調整連線行為。大多數伺服器預設值都是針對 各有少量用戶端的環境 要求。以即時出價來說，然後是一小群機器將請求傳送到 相對地在這類 會盡量重複使用連線。三 建議您設定：

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

以 Apache 為例，這樣 該值會包含設定 KeepAliveTimeout 到 150，MaxKeepAliveRequests 到 ，且 MaxClients 的值會視伺服器類型而定。

連線行為調整完畢後，您應該確定 出價工具程式碼不會無端關閉連線。舉例來說 傳回預設「無出價」的前端程式碼做為回應 請確保程式碼在不關閉 以獲得最佳效能和最安全的連線如此一來，就不會在出價工具發生下列情況時避免情況 超載、連線開始關閉、逾時數目增加。 導致出價工具受到節制

保持連線平衡

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

如果大量連線的使用率過高，其他已開啟的連線 大多處於閒置狀態，因為當時不需要使用。阿斯 Authorized Buyers 的流量變化和閒置連線會變成有效狀態 連線可能處於閒置狀態。這些情況可能會導致出價工具伺服器上的負載量不均 是否會造成連線品質不佳Google 會透過以下方式 在 10,000 個要求之後關閉所有連線，以自動重新平衡熱 持續增加連線如果還是發現流量不平衡 您可以採取後續行動：

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

妥善處理超載

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

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

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

「回覆所有問題」出價方

雖然易於導入，但這個出價工具在 超載。它只會嘗試回應收到的每個出價要求， 找出無法立即放送的內容情境 發生的常見原因如下所示：

• 要求比率會隨著要求比率提高 開始逾時
• 延遲在呼叫率接近峰值時突然提高
• 開始節流，大幅減少允許摘要的數量
• 延遲時間開始恢復，導致節流減少
• 週期重新開始。

這個出價工具的延遲圖形看起來像非常陡峭的鋸齒狀 。或者，已排入佇列的要求會讓伺服器開始分頁 或是執行其他會造成長期拖慢速度的事 直到尖峰時段結束才復原，導致呼叫失敗 整個峰值區間的流量但無論是哪種情況，摘要的摘要數量也比較少 比起將配額設為較低值的情況，系統能傳回不同值。

「超載時發生錯誤」出價方

這個出價方接受特定費率的摘要，然後開始傳回 錯誤。方法是使用內部逾時，以停用 連線佇列 (由 Apache 上的 ListenBackLog 控管)、 在使用率或延遲情況一併導入機率捨棄模式的情況下 或是其他類似機制如果 Google 觀察到錯誤率超過 15% 我們將開始節流和「回覆所有人」選項不同出價方，這個出價方 「削減其損失」讓機器可在要求率達到前立即復原 下降。

這個出價工具的延遲圖形類似淺層鋸 並在超載期間依可接受的最大值進行本地化 頻率。

「超載時沒有出價」出價方

這個出價方接受特定費率的摘要，然後開始傳回 「沒有出價」任何超載的回應類似「超載時發生錯誤」出價方 而且有多種執行方式兩者差別在於 信號就會傳回 Google，因此我們絕對不會處理呼叫。 前端機器會吸收超載，因此只會允許流量 以便繼續前往後端

這個出價工具的延遲圖形顯示了 (人為的) 峰值時停止平行處理要求比率 包含出價的回應比例

建議您結合「超載時發生錯誤」設定為「超載時沒有出價」 方法如下：

• 超額佈建前端，並將其設為在超載時發生錯誤，以便最大化它們能以某種形式回應的連線數量。
• 超載發生錯誤時，前端電腦可以使用罐頭「沒有出價」不需要剖析要求。
• 對後端執行健康狀態檢查，確保在容量不足的情況下，系統會傳回「沒有出價」回應。

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

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

回應連線偵測

確保出價工具可以在沒有連線的情況下回應連線偵測 (ping) 要求 執行偵錯時，顯然十分重要。Google 採用連線偵測 (ping) 出價工具狀態的例行檢查和偵錯要求，連結關閉 行為和延遲等連線偵測 (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

"id": "4YB27BCXimH5g7wB39nd3t"

id: "7xd2P2M7K32d7F7Y50p631"

請注意，有別於您預期的設定，連線偵測 (ping) 要求並不包含任何 廣告版位。如上方詳述，回應連線偵測 (ping) 要求後，請勿關閉連線。

考慮對等互連

另一個減少網路延遲或變異性的方法，就是與 Google 對等互連。 對等互連有助於改善流量進入出價工具的路徑。 連線端點維持不變，但中繼連結會改變。詳情請參閱 詳情請參閱對等互連指南。 建議將對等互連視為最佳做法的理由摘要如下：

• 在網際網路上，大眾運輸連結主要透過 "hot-potato" 進行選擇 轉送」尋找我們網路外最接近且 封包傳送至目的地，然後將封包轉送至該連結。時間 流量會穿越我們擁有 所選的連結可能會較靠近 就可以啟動封包超過該點後，我們就無法控制封包的路徑 出價工具就跟出價者一樣，因此可能會彈跳轉至其他自治系統 整個過程 (網路)

• 相反地，如果設定了直接對等互連協議，封包 一律透過對等互連連結傳送。無論封包來自何處 週遊 Google 擁有或租用的連結，直到能被分享 與出價工具位置相近。反向行程 會先短暫跳躍至 Google 網路，接著保留在 Google 整個網路透過 Google 代管的方式確保大部分的行程 可確保封包採用低延遲路徑，並避免 都可能出現差異

提交靜態 DNS

我們建議買方一律向 Google 提交一項靜態 DNS 結果， 來處理流量傳送作業

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

1. DNS 伺服器會分發一個位址或部分位址以回應 然後以某種方式循環執行這個回應
2. DNS 伺服器一律會以同一組位址回應，但會循環執行 則會參照回應中的地址順序。

第一項技術是負載平衡方面的成效不彰，因為 多層堆疊，並且試圖繞過快取 也會收到偏好結果，因為 Google 會向 出價工具

第二種技術完全無法達成負載平衡 會從 DNS 回應清單中隨機選取一個 IP 位址，這樣 沒有影響。

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