Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Kuota melindungi infrastruktur Google dari proses otomatis yang menggunakan Google Bid Manager API dengan cara yang tidak pantas. Mereka memastikan bahwa tindakan dari satu developer tidak dapat berdampak negatif pada komunitas yang lebih besar.
Batas kuota
Batas kuota default berikut digunakan bersama oleh semua sumber daya dan metode Bid Manager API.
Di Konsol API Google, kuota ini disebut sebagai Kueri per menit per pengguna, dan ditetapkan menjadi 240.
Melebihi batas kuota
Jika permintaan Anda gagal karena melebihi batas kuota, API akan menampilkan kode status HTTP dan alasan error tersebut. Selain itu, isi respons berisi deskripsi mendetail tentang penyebab error. Lihat panduan Pesan Error untuk mengetahui contoh respons error.
Daftar berikut menampilkan kemungkinan error dan tindakan yang disarankan untuk kegagalan permintaan yang disebabkan oleh melampaui batas kuota.
Code
Alasan
Pesan
Tindakan yang Disarankan
403
dailyLimitExceeded
Batas Harian Terlampaui
Jangan mencoba lagi tanpa memperbaiki masalah. Periksa penggunaan Anda dari Konsol API Google dan ubah alur kerja untuk membuat lebih sedikit permintaan. Anda dapat meminta kuota tambahan jika yakin bahwa penggunaan Anda wajar.
Backoff eksponensial adalah strategi penanganan error standar untuk aplikasi jaringan, yang mana klien secara berkala mencoba lagi permintaan yang gagal, dengan menambah lamanya penundaan antara setiap permintaan yang gagal. Jika volume permintaan yang tinggi atau traffic jaringan yang tinggi menyebabkan server menampilkan error, backoff eksponensial mungkin merupakan strategi yang tepat untuk menangani error tersebut. Sebaliknya, ini bukan strategi yang relevan untuk menangani error yang tidak terkait dengan volume jaringan atau waktu respons, seperti kredensial otorisasi yang tidak valid atau error file tidak ditemukan.
Jika digunakan dengan benar, backoff eksponensial akan meningkatkan efisiensi penggunaan bandwidth, mengurangi jumlah permintaan yang diperlukan untuk mendapatkan respons yang berhasil, dan memaksimalkan throughput permintaan dalam lingkungan serentak.
Alur untuk mengimplementasikan backoff eksponensial sederhana adalah sebagai berikut:
Buat permintaan ke API.
Terima respons HTTP 503, yang menunjukkan bahwa Anda harus mencoba lagi permintaan tersebut.
Tunggu 1 detik + random_number_milliseconds dan coba lagi permintaan tersebut.
Terima respons HTTP 503, yang menunjukkan bahwa Anda harus mencoba lagi permintaan tersebut.
Tunggu 2 detik + random_number_milliseconds dan coba lagi permintaan tersebut.
Terima respons HTTP 503, yang menunjukkan bahwa Anda harus mencoba lagi permintaan tersebut.
Tunggu 4 detik + random_number_milliseconds dan coba lagi permintaan tersebut.
Terima respons HTTP 503, yang menunjukkan bahwa Anda harus mencoba lagi permintaan tersebut.
Tunggu 8 detik + random_number_milliseconds dan coba lagi permintaan tersebut.
Terima respons HTTP 503, yang menunjukkan bahwa Anda harus mencoba lagi permintaan tersebut.
Tunggu 16 detik + random_number_milliseconds dan coba lagi permintaan tersebut.
Stop. Laporkan atau buat log untuk error.
Pada alur di atas, random_number_milliseconds adalah angka acak milidetik yang kurang dari atau sama dengan 1.000. Ini diperlukan, karena memperkenalkan penundaan acak yang singkat akan membantu mendistribusikan beban dengan lebih merata dan menghindari kemungkinan penyerbuan server. Nilai random_number_milliseconds harus ditentukan ulang setelah setiap periode tunggu.
Catatan: Periode tunggu selalu (2 ^ n) + random_number_milliseconds, yang mana n adalah bilangan bulat yang meningkat secara monotonik, yang awalnya ditetapkan sebagai 0. Integer n ditambah dengan 1 untuk setiap iterasi (setiap permintaan).
Algoritma disetel untuk dihentikan jika n adalah 5. Batas ini mencegah agar klien tidak terus mencoba tanpa batas, dan mengakibatkan penundaan total sekitar 32 detik sebelum permintaan dianggap "error yang tidak dapat dipulihkan". Jumlah percobaan ulang maksimum yang lebih besar tidak masalah, terutama jika upload yang panjang sedang berlangsung; tetapi pastikan untuk membatasi penundaan percobaan ulang pada jumlah yang masuk akal, misalnya, kurang dari satu menit.
Meminta kuota harian tambahan
Jika Anda merasa bahwa aplikasi Anda memerlukan kuota harian tambahan, Anda dapat meminta lebih banyak dengan mengikuti petunjuk di bawah ini.
Petunjuk berikut hanya berlaku untuk project yang mengalami error dailyLimitExceeded. Tindakan yang disarankan untuk kesalahan kuota lainnya dibahas dalam tabel di atas.
Tinjau statistik penggunaan dari halaman Metrics untuk memastikan aplikasi berfungsi seperti yang diharapkan. Perhatikan metode yang telah dipanggil dan atasi penggunaan yang tidak diharapkan atau berlebihan sebelum melanjutkan.
Jika penggunaan terlihat normal, buka halaman Kuota, klik ikon edit di samping Kueri per hari, lalu klik link "Ajukan permohonan untuk kuota yang lebih tinggi".
Pastikan untuk meninjau informasi dan mengikuti petunjuk yang disertakan dalam formulir permintaan kuota sebelum mengirimkan permintaan penambahan kuota.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-31 UTC."],[[["\u003cp\u003eGoogle Bid Manager API uses quotas to protect its infrastructure and ensure fair usage for all developers.\u003c/p\u003e\n"],["\u003cp\u003eDefault quota limits include 2,000 requests per project per day and 4 queries per second per project.\u003c/p\u003e\n"],["\u003cp\u003eExceeding quota limits results in specific error codes, requiring actions like reducing requests or using exponential backoff.\u003c/p\u003e\n"],["\u003cp\u003eExponential backoff is a retry strategy for handling temporary errors by gradually increasing wait times between requests.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers can request additional daily quota through the Google API Console if needed.\u003c/p\u003e\n"]]],["Google Bid Manager API uses quotas to protect its infrastructure, limiting projects to 2,000 daily requests and 4 queries per second. Exceeding these results in errors; `dailyLimitExceeded` requires usage examination and possible quota increase, while `userRateLimitExceeded` needs rate slowdown via exponential backoff. Exponential backoff retries failed requests with increasing delays (e.g., 1, 2, 4 seconds) and randomized milliseconds, terminating after a set number of attempts. Additional daily quota can be requested through the Google API Console.\n"],null,["# Quotas protect Google's infrastructure from automated processes that use the Google Bid Manager API in an inappropriate way. They ensure that one developer's actions cannot negatively impact the larger community.\n\nQuota limits\n------------\n\nThe following default quota limits are shared by all Bid Manager API resources and methods.\n\n- 2,000 requests per project per day - [can be increased](#additional_quota).\n- 4 queries per second (QPS) per project.\n - In the Google API Console this quota is referred to as **Queries per minute per user**, and is set to 240.\n\n| **Note:** Daily quotas refresh at midnight PST.\n\nExceeding quota limits\n----------------------\n\nIn the unlikely event that your request fails due to exceeding a quota limit, the API returns an HTTP status code and reason for the error. Additionally, the body of the response contains a detailed description of what caused the error. See the [Error Messages](/bid-manager/core_errors) guide for an example error response.\n\nThe following list shows the possible errors and recommended actions for request failures caused by exceeding quota limits.\n\n| Code | Reason | Message | Recommended Action |\n|------|-----------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 403 | dailyLimitExceeded | Daily Limit Exceeded | Do not retry without fixing the problem. [Examine your usage](https://console.developers.google.com/project/_/apiui/apiview/doubleclickbidmanager/metrics) from the Google API Console and modify your workflow to make fewer requests. You can [request additional quota](#additional_quota) if you believe your usage is reasonable. |\n| 403 | userRateLimitExceeded | User Rate Limit Exceeded | Slow down the rate at which you are sending requests using [exponential backoff](#exponential_backoff). |\n\n#### What is exponential backoff?\n\nExponential backoff is a standard error handling strategy for network applications in which the client periodically retries a failed request over an increasing amount of time. If a high volume of requests or heavy network traffic causes the server to return errors, exponential backoff may be a good strategy for handling those errors. Conversely, it is not a relevant strategy for dealing with errors unrelated to network volume or response times, such as invalid authorization credentials or file not found errors.\n\nUsed properly, exponential backoff increases the efficiency of bandwidth usage, reduces the number of requests required to get a successful response, and maximizes the throughput of requests in concurrent environments.\n\nThe flow for implementing simple exponential backoff is as follows:\n\n1. Make a request to the API.\n2. Receive an `HTTP 503` response, which indicates you should retry the request.\n3. Wait 1 second + random_number_milliseconds and retry the request.\n4. Receive an `HTTP 503` response, which indicates you should retry the request.\n5. Wait 2 seconds + random_number_milliseconds, and retry the request.\n6. Receive an `HTTP 503` response, which indicates you should retry the request.\n7. Wait 4 seconds + random_number_milliseconds, and retry the request.\n8. Receive an `HTTP 503` response, which indicates you should retry the request.\n9. Wait 8 seconds + random_number_milliseconds, and retry the request.\n10. Receive an `HTTP 503` response, which indicates you should retry the request.\n11. Wait 16 seconds + random_number_milliseconds, and retry the request.\n12. Stop. Report or log an error.\n\nIn the above flow, random_number_milliseconds is a random number of milliseconds less than or equal to 1000. This is necessary, since introducing a small random delay helps distribute the load more evenly and avoid the possibility of stampeding the server. The value of random_number_milliseconds must be redefined after each wait.\n\n**Note:**The wait is always (2 \\^ n) + random_number_milliseconds, where n is a monotonically increasing integer initially defined as 0. The integer n is incremented by 1 for each iteration (each request).\n\nThe algorithm is set to terminate when n is 5. This ceiling prevents clients from retrying infinitely, and results in a total delay of around 32 seconds before a request is deemed \"an unrecoverable error.\" A larger maximum number of retries is fine, especially if a long upload is in progress; just be sure to cap the retry delay at something reasonable, say, less than one minute.\n\nRequesting additional daily quota\n---------------------------------\n\nIf you think that your application requires additional daily quota, you can request more by following the instructions below.\n\nThe following instructions only apply to projects that have encountered a `dailyLimitExceeded` error. Recommended actions for other quota errors are covered in the [table above](#exceeding_limits).\n\n1. Navigate to the [Bid Manager API](https://console.developers.google.com/project/_/apiui/apiview/doubleclickbidmanager/quotas) in the Google API Console.\n2. Review your usage statistics from the **Metrics** page to ensure your application is behaving as expected. Pay close attention to the methods that have been called and address any unexpected or excessive usage before proceeding.\n3. If usage looks normal, navigate to the **Quotas** page, click the edit icon next to **Queries per day** and click the link to \"Apply for higher quota\".\n\nMake sure to review the information and follow the instructions included in the quota request form before submitting an increase request.\n| **Note:** The email address you provide must be one that you actively monitor, as a representative may reach out to gather additional information."]]
