Saat ini kami memigrasikan sebagian jenis laporan dari pelaporan offline ke pelaporan instan. Setelah pengguna dimigrasikan, respons queries.list akan menyertakan laporan instan yang sudah ada. Lihat postingan blog kami untuk informasi selengkapnya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Kuota

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.

2.000 permintaan per project per hari - dapat ditingkatkan.
4 kueri per detik (QPS) per project.
- 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.
403	userRateLimitExceeded	Batas Kapasitas Pengguna Terlampaui	Memperlambat kecepatan pengiriman permintaan menggunakan backoff eksponensial.

Apa itu backoff eksponensial?

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.

Buka Bid Manager API di Konsol API Google.
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.