Karena Google Chat API adalah layanan bersama, kami menerapkan kuota dan batasan untuk memastikan bahwa API tersebut digunakan secara adil oleh semua pengguna dan untuk melindungi performa Google Workspace secara keseluruhan.
Jika melebihi kuota, Anda akan menerima respons kode status HTTP
429: Too many requests
. Pemeriksaan batas kapasitas tambahan di backend Chat
juga dapat menghasilkan respons error yang sama. Jika error ini terjadi, Anda
harus menggunakan
algoritma backoff eksponensial
dan mencoba lagi nanti. Selama Anda tetap berada dalam kuota per menit yang tercantum dalam tabel berikut, tidak ada batasan jumlah permintaan yang dapat Anda buat per hari.
Dua jenis kuota berlaku untuk metode Chat API: kuota per ruang dan per project.
Kuota per ruang
Kuota per ruang membatasi frekuensi kueri di ruang tertentu dan digunakan bersama oleh semua aplikasi Chat yang bertindak di ruang tersebut yang memanggil metode Chat API yang tercantum untuk setiap kuota.
Tabel berikut menjelaskan batas kueri per ruang:
Kuota Per Ruang |
Metode Chat API |
Batas (per 60 detik, dibagikan |
---|---|---|
Operasi baca per menit |
|
900 |
Operasi tulis per menit |
|
60 |
Kuota per project
Kuota per project membatasi kapasitas kueri untuk sebuah project Google Cloud, sehingga berlaku untuk satu aplikasi Chat yang memanggil metode Chat API yang ditentukan untuk setiap kuota.
Tabel berikut menjelaskan batas kueri per project. Anda juga dapat menemukan batas ini di halaman Quotas.
Kuota Per Project |
Metode Chat API |
Batas (per 60 detik) |
---|---|---|
Operasi tulis pesan per menit |
|
3000 |
Pembacaan pesan per menit |
|
3000 |
Operasi tulis keanggotaan per menit |
|
300 |
Pembacaan keanggotaan per menit |
|
3000 |
Operasi tulis ruang per menit |
|
60 |
Pembacaan ruang per menit |
|
3000 |
Penulisan lampiran per menit |
|
600 |
Bacaan lampiran per menit |
|
3000 |
Penulisan reaksi per menit |
|
600 |
Reaksi dibaca per menit |
|
3000 |
Batas penggunaan tambahan
Ada batas kuota tambahan untuk membuat ruang jenis GROUP_CHAT
atau SPACE
(dengan menggunakan metode spaces.create
atau spaces.setup
).
Buat kurang dari 35 ruang per menit dan 800 ruang per
jam dari jenis ini. Ruang jenis DIRECT_MESSAGE
tidak tunduk pada batas kuota tambahan ini.
Traffic API tinggi yang menargetkan ruang yang sama dapat memicu batas internal tambahan yang tidak terlihat di halaman Quotas.
Mengatasi error kuota berbasis waktu
Untuk semua error berbasis waktu (maksimum N permintaan per X menit), sebaiknya kode Anda menangkap pengecualian dan menggunakan backoff eksponensial terpotong untuk memastikan perangkat Anda tidak menghasilkan beban yang berlebihan.
Backoff eksponensial adalah strategi penanganan error standar untuk aplikasi jaringan. Algoritma backoff eksponensial mencoba ulang permintaan menggunakan waktu tunggu yang meningkat secara eksponensial di antara permintaan, hingga waktu backoff maksimum. Jika permintaan masih gagal, penundaan antarpermintaan harus meningkat seiring waktu hingga permintaan berhasil.
Contoh algoritma
Algoritma backoff eksponensial mencoba ulang permintaan secara eksponensial, sehingga meningkatkan waktu tunggu antar-percobaan ulang hingga waktu backoff maksimum. Contoh:
- Buat permintaan ke Google Chat API.
- Jika permintaan gagal, tunggu 1 +
random_number_milliseconds
dan coba lagi permintaan tersebut. - Jika permintaan gagal, tunggu 2 +
random_number_milliseconds
dan coba lagi permintaan tersebut. - Jika permintaan gagal, tunggu 4 +
random_number_milliseconds
dan coba lagi permintaan tersebut. - Dan seterusnya, hingga waktu
maximum_backoff
. - Terus tunggu dan coba ulang hingga jumlah maksimum percobaan ulang, tetapi jangan tambah waktu tunggu antar-percobaan ulang.
dalam hal ini:
- Waktu tunggunya adalah
min(((2^n)+random_number_milliseconds), maximum_backoff)
, dengann
bertambah 1 untuk setiap iterasi (permintaan). random_number_milliseconds
adalah angka acak milidetik yang kurang dari atau sama dengan 1.000. Hal ini membantu menghindari kasus saat banyak klien disinkronkan oleh beberapa situasi dan semua mencoba lagi sekaligus, sehingga mengirimkan permintaan dalam gelombang yang disinkronkan. Nilairandom_number_milliseconds
dihitung ulang setelah setiap permintaan coba lagi.maximum_backoff
biasanya 32 atau 64 detik. Nilai yang sesuai bergantung pada kasus penggunaan.
Klien dapat terus mencoba ulang setelah mencapai waktu maximum_backoff
.
Percobaan ulang setelah tahap ini tidak perlu terus meningkatkan waktu backoff. Misalnya,
jika klien menggunakan waktu maximum_backoff
64 detik, setelah mencapai
nilai ini, klien dapat mencoba lagi setiap 64 detik. Pada titik tertentu,
klien harus dicegah agar tidak mencoba ulang tanpa batas.
Waktu tunggu antara percobaan ulang dan jumlah percobaan ulang bergantung pada kasus penggunaan dan kondisi jaringan Anda.
Meminta peningkatan kuota per project
Bergantung pada penggunaan resource project, Anda mungkin ingin meminta penambahan kuota. Panggilan API oleh akun layanan dianggap menggunakan akun tunggal. Mengajukan permohonan untuk penambahan kuota belum tentu disetujui. Peningkatan kuota yang besar mungkin memerlukan waktu lebih lama untuk disetujui.
Tidak semua project memiliki kuota yang sama. Seiring meningkatnya penggunaan Google Cloud dari waktu ke waktu, kuota Anda mungkin perlu ditingkatkan. Jika Anda memperkirakan adanya peningkatan penggunaan yang signifikan di masa mendatang, Anda dapat secara proaktif meminta penyesuaian kuota dari halaman Kuota di konsol Google Cloud.
Untuk mempelajari lebih lanjut, lihat referensi berikut:
- Tentang permintaan penambahan kuota
- Melihat batas dan penggunaan kuota saat ini
- Meminta batas kuota yang lebih tinggi