Batas Kapasitas
Google Ads API mengelompokkan permintaan untuk pembatasan kapasitas menurut kueri per detik (QPS) per ID pelanggan (CID) dan token developer, yang berarti pengukuran diterapkan secara terpisah pada CID dan token developer. Google Ads API menggunakan algoritma Token Bucket untuk mengukur permintaan dan menentukan batas QPS yang sesuai, sehingga batas persisnya akan bervariasi bergantung pada beban server secara keseluruhan pada waktu tertentu.
Tujuan penerapan batas kecepatan adalah untuk mencegah satu pengguna mengganggu layanan bagi pengguna lain dengan (baik secara sengaja maupun tidak sengaja) membanjiri server Google Ads API dengan volume permintaan yang tinggi.
Permintaan yang melanggar batas frekuensi akan ditolak dengan error:
RESOURCE_TEMPORARILY_EXHAUSTED.
Anda dapat mengontrol aplikasi dan mengurangi batas kecepatan dengan secara aktif mengurangi jumlah permintaan dan membatasi QPS dari sisi klien.
Ada beberapa cara untuk mengurangi kemungkinan terlampauinya batas frekuensi. Memahami konsep Pola Integrasi Perusahaan (EIP) seperti Pengiriman Pesan, Pengiriman Ulang, dan Pembatasan dapat membantu Anda membangun aplikasi klien yang lebih andal.
Praktik yang direkomendasikan berikut diurutkan berdasarkan kompleksitas, dengan strategi yang lebih sederhana di bagian atas dan arsitektur yang lebih andal, tetapi canggih setelahnya:
Membatasi tugas serentak
Salah satu akar penyebab terlampauinya batas frekuensi adalah aplikasi klien memunculkan terlalu banyak tugas paralel. Meskipun kami tidak membatasi jumlah permintaan paralel yang dapat dimiliki aplikasi klien, hal ini dapat melampaui batas Permintaan Per Detik di tingkat token developer.
Sebaiknya tetapkan batas atas yang wajar untuk jumlah total tugas serentak yang akan membuat permintaan (di semua proses dan mesin), dan sesuaikan ke atas untuk mengoptimalkan throughput tanpa melebihi batas kecepatan.
Selain itu, Anda dapat mempertimbangkan pembatasan QPS dari sisi klien (lihat Pembatasan dan pembatas kecepatan).
Permintaan pembuatan batch
Pertimbangkan untuk mengelompokkan beberapa operasi ke dalam satu permintaan. Hal ini paling
berlaku pada panggilan MutateFoo. Misalnya, jika Anda memperbarui status untuk beberapa instance AdGroupAd - daripada memanggil MutateAdGroupAds sekali untuk setiap AdGroupAd, Anda dapat memanggil MutateAdGroupAds sekali, dan meneruskan beberapa operations. Lihat panduan operasi batch kami untuk beberapa contoh tambahan.
Meskipun menggabungkan permintaan mengurangi jumlah total permintaan dan mengurangi batas frekuensi Permintaan Per Menit, hal ini dapat memicu batas frekuensi Operasi Per Menit jika Anda melakukan sejumlah besar operasi terhadap satu akun.
Throttling dan pembatas kapasitas
Selain membatasi jumlah total thread di aplikasi klien, Anda juga dapat menerapkan pembatasan kapasitas di sisi klien. Hal ini dapat memastikan semua thread di seluruh proses dan / atau cluster Anda diatur oleh batas QPS tertentu dari sisi klien.
Anda dapat melihat Guava Rate Limiter, atau menerapkan algoritma berbasis Token Bucket Anda sendiri untuk lingkungan yang dikelompokkan. Misalnya, Anda dapat membuat token dan menyimpannya di penyimpanan transaksional bersama seperti database, dan setiap klien harus mendapatkan dan menggunakan token sebelum memproses permintaan. Jika token habis, klien harus menunggu hingga batch token berikutnya dibuat.
Antrean
Antrean pesan adalah solusi untuk distribusi beban operasi, sekaligus mengontrol kecepatan permintaan dan konsumen. Ada sejumlah opsi antrean pesan yang tersedia—beberapa open source, beberapa berpemilik—dan banyak di antaranya dapat berfungsi dengan berbagai bahasa.
Saat menggunakan antrean pesan, Anda dapat memiliki beberapa produsen yang mengirim pesan ke antrean dan beberapa konsumen yang memproses pesan tersebut. Pembatasan dapat diterapkan di sisi konsumen dengan membatasi jumlah konsumen serentak, atau menerapkan pembatas frekuensi atau pembatasan untuk produsen atau konsumen.
Misalnya, jika konsumen pesan mengalami error batas kecepatan, konsumen tersebut dapat mengembalikan permintaan ke antrean untuk dicoba lagi. Pada saat yang sama, konsumen tersebut juga dapat memberi tahu semua konsumen lain untuk menjeda pemrosesan selama beberapa detik untuk memulihkan diri dari error.