Karena Google Chat API adalah layanan bersama, kami menerapkan kuota dan batasan untuk memastikan bahwa layanan ini digunakan secara adil oleh semua pengguna dan untuk melindungi performa keseluruhan Google Workspace.
Jika Anda melebihi kuota, Anda akan menerima respons kode status HTTP 429: Too many requests. Pemeriksaan batas frekuensi 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.
Beberapa jenis kuota dapat berlaku untuk metode Chat API: kuota per project, per ruang, dan per pengguna.
Kuota per project
Kuota per project membatasi frekuensi kueri untuk project Google Cloud, dan dengan demikian 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 Kuota.
Kuota per project |
Metode Chat API |
Batas (per 60 detik) |
|---|---|---|
Penulisan pesan per menit |
|
3000 |
Pembacaan pesan per menit |
|
3000 |
Penulisan keanggotaan per menit |
|
300 |
Pembacaan keanggotaan per menit |
|
3000 |
Penulisan ruang per menit |
|
60 |
Pembacaan ruang per menit |
|
3000 |
Penulisan lampiran per menit |
|
600 |
Pembacaan lampiran per menit |
|
3000 |
Penulisan reaksi per menit |
|
600 |
Pembacaan reaksi per menit |
|
3000 |
Penulisan CustomEmoji per menit |
|
600 |
Pembacaan CustomEmoji per menit |
|
3000 |
Penulisan bagian per menit |
|
600 |
Pembacaan bagian per menit |
|
3000 |
Pembacaan ketersediaan per menit |
|
3000 |
Penulisan ketersediaan per menit |
|
3000 |
Kuota per ruang
Kuota per ruang membatasi frekuensi kueri di ruang tertentu dan dibagikan di antara 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 detik) |
|---|---|---|
Pembacaan per detik |
|
15 |
Penulisan per detik |
|
1 |
Penulisan Buat Reaksi per detik |
|
5 |
Penulisan pesan per detik saat mengimpor data ke Google Chat |
|
10 |
Kuota per pengguna
Kuota per pengguna membatasi frekuensi kueri untuk pengguna Google Chat. Kueri berkaitan dengan semua aplikasi Chat yang memanggil metode Chat API atas nama pengguna (menggunakan autentikasi pengguna).
Tabel berikut menjelaskan batas kueri per pengguna:
Kuota per pengguna |
Metode Chat API |
Batas (per detik) |
|---|---|---|
Penulisan CustomEmoji per detik |
|
1 |
Pembacaan CustomEmoji per detik |
|
15 |
Penulisan per detik |
|
1 |
Pembacaan per detik |
|
15 |
Batas penggunaan tambahan
Traffic API yang tinggi yang menargetkan ruang yang sama dapat memicu batas internal tambahan yang tidak terlihat di halaman Kuota.
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, penting untuk meningkatkan penundaan antara permintaan dari waktu ke 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_millisecondsdan coba lagi permintaan. - Jika permintaan gagal, tunggu 2 +
random_number_millisecondsdan coba lagi permintaan. - Jika permintaan gagal, tunggu 4 +
random_number_millisecondsdan coba lagi permintaan. - Dan seterusnya, hingga waktu
maximum_backoff. - Lanjutkan menunggu dan mencoba ulang hingga jumlah maksimum percobaan ulang, tetapi jangan tambah waktu tunggu antar-percobaan ulang.
dengan:
- Waktu tunggu adalah
min(((2^n)+random_number_milliseconds), maximum_backoff), dengannbertambah 1 untuk setiap iterasi (permintaan). random_number_millisecondsadalah bilangan acak milidetik yang kurang dari atau sama dengan 1.000. Hal ini membantu menghindari kasus saat banyak klien disinkronkan oleh situasi tertentu dan semua mencoba lagi secara bersamaan, sehingga mengirimkan permintaan dalam gelombang yang disinkronkan. Nilairandom_number_millisecondsdihitung ulang setelah setiap permintaan coba lagi.maximum_backoffbiasanya 32 atau 64 detik. Nilai yang sesuai bergantung pada kasus penggunaan.
Klien dapat terus mencoba lagi 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 suatu saat,
klien harus dicegah untuk mencoba lagi tanpa batas.
Waktu tunggu antara percobaan ulang dan jumlah percobaan ulang bergantung pada kasus penggunaan dan kondisi jaringan Anda.
Meminta penambahan kuota per project
Bergantung pada penggunaan resource project Anda, Anda mungkin ingin meminta penyesuaian kuota. Panggilan API oleh akun layanan dianggap menggunakan satu akun. Mengajukan permohonan untuk penyesuaian kuota belum tentu disetujui. Permintaan penyesuaian kuota yang akan meningkatkan nilai kuota secara signifikan dapat memerlukan waktu lebih lama untuk disetujui.
Tidak semua project memiliki kuota yang sama. Seiring meningkatnya penggunaan Google Cloud dari waktu ke waktu, nilai 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 & Batas Sistem di konsol Google Cloud.
Untuk mempelajari lebih lanjut, lihat referensi berikut: