配額

配額可以防止 Google 基礎架構受到自動化程序不當使用 Google Bid Manager API 的侵擾。避免單一開發人員的行為對更大的社群產生負面影響。

配額限制

下列預設配額限制是由所有 Bid Manager API 資源和方法共用。

• 每項專案每日 2,000 個要求 (可以增加)。
• 每項專案每秒 4 次查詢 (QPS)。
  • 在 Google API 控制台中，這項配額稱為「每位使用者每分鐘查詢數」，並設定為 240。

注意事項： 每日配額會在太平洋標準時間的午夜重新計算。

超出配額限制

萬一您的要求因超出配額限製而失敗，API 會傳回 HTTP 狀態碼和發生錯誤的原因。此外，回應主體會包含錯誤原因的詳細說明。如需錯誤回應範例，請參閱錯誤訊息指南。

以下列出因超出配額限製而造成要求失敗的錯誤，以及建議採取的行動。

程式碼	原因	訊息	建議做法
403	dailyLimitExceeded	已超過每日上限	未修正問題前請勿重試。在 Google API 控制台中查看用量，並修改工作流程來減少要求數量。如果您認為用量合理，可以要求額外配額。
403	userRateLimitExceeded	超過使用者頻率限制	使用指數輪詢減慢傳送要求的速度。

什麼是指數輪詢？

指數輪詢是網路應用程式的標準錯誤處理策略，用戶端可透過這種策略，以逐漸增加的次數定期重試失敗的要求。如果大量要求或繁重的網路流量導致伺服器傳回錯誤，指數輪詢就是處理這類錯誤的一種不錯的策略。相反地，處理與網路流量或回應時間相關的錯誤 (例如授權憑證無效或找不到檔案的錯誤) 並不是很有意義的策略。

在正確的使用之下，指數輪詢可以提升頻寬使用的效率，減少取得成功回應所需的要求數，並最大化並行環境中的要求總處理量。

實作簡單指數輪詢的流程如下：

1. 對 API 提出要求。
2. 收到指出您應該要重試要求的 HTTP 503 回應。
3. 等待 1 秒鐘 + random_number_milliseconds 毫秒，然後重試要求。
4. 收到指出您應該要重試要求的 HTTP 503 回應。
5. 等待 2 秒鐘 + random_number_milliseconds 毫秒，然後重試要求。
6. 收到指出您應該要重試要求的 HTTP 503 回應。
7. 等待 4 秒鐘 + random_number_milliseconds 毫秒，然後重試要求。
8. 收到指出您應該要重試要求的 HTTP 503 回應。
9. 等待 8 秒鐘 + random_number_milliseconds 毫秒，然後重試要求。
10. 收到指出您應該要重試要求的 HTTP 503 回應。
11. 等待 16 秒鐘 + random_number_milliseconds 毫秒，然後重試要求。
12. 停止。報告或記錄錯誤。

在以上流程中，random_number_milliseconds 是小於或等於 1000 的隨機毫秒數。這是必要的，因為使用較小的隨機延遲有助於更平均地分散負載，並避免對伺服器產生衝擊的可能性。必須在每次等待之後重新定義 random_number_milliseconds 的值。

注意：等待時間一律是 (2 ^ n) + random_number_milliseconds，其中 n 是一開始定義為 0 的單調遞增整數。對於每個疊代 (每次要求)，整數 n 會遞增 1。

演算法已設定為會在 n 等於 5 時終止。這個上限可以防止用戶端一直重試下去，導致要求在總延遲時間達到約 32 秒之後，才會被視為「無法復原的錯誤」。您可以把重試次數的上限設高一點，尤其是在大型上傳作業執行的過程中；但請確保要把重試延遲時間的上限設定在合理的地方，例如短於一分鐘。

要求額外每日配額

如果您認為應用程式需要額外每日配額，可以按照下列指示申請更多每日配額。

下列操作說明僅適用於發生 dailyLimitExceeded 錯誤的專案。其他配額錯誤的建議動作請參閱上表。

1. 前往 Google API 控制台中的 Bid Manager API。
2. 查看「Metrics」(指標) 頁面上的使用統計資料，確認應用程式正常運作。請仔細檢查所呼叫的方法，並處理任何非預期或過度使用的問題，然後再繼續操作。
3. 如果用量正常，請前往「配額」頁面，按一下「每日查詢數量」旁邊的編輯圖示，然後點選「申請更多配額」的連結。

提交提高要求前，請務必詳閱資訊，並遵循配額申請表單中的指示操作。

注意： 您提供的電子郵件地址必須是您主動監控的電子郵件地址，業務代表可能會與您聯絡，以便收集額外資訊。