Kami berupaya untuk senantiasa menyampaikan setiap pesan yang dikirimkan menggunakan FCM. Namun, jika kami menyampaikan setiap pesan, terkadang pengalaman pengguna secara keseluruhan dapat terganggu. Selain itu, kami perlu menetapkan batasan untuk memastikan bahwa FCM menyediakan layanan yang skalabel bagi semua pengirim. Jenis batas dan kuota yang dijelaskan di bagian ini membantu kami menyeimbangkan faktor penting ini.
Throttling pesan downstream
HTTP v1 API memperkenalkan kuota per project, per menit untuk pesan downstream. Kuota default 600 ribu pesan per menit mencakup lebih dari 99% developer FCM sekaligus melindungi stabilitas sistem dan meminimalkan dampak project yang tidak stabil.
Lonjakan pola traffic dapat mengakibatkan error kuota terlampaui. Ketika kuota terlampaui, sistem akan menampilkan kode status HTTP 429 (QUOTA_EXCEEDED) hingga kuota diisi ulang pada menit berikutnya. Respons 429 juga dapat ditampilkan saat terjadi kelebihan beban, jadi sebaiknya tangani respons 429 sesuai rekomendasi yang dipublikasikan.
Perhatikan bahwa:
- Kuota downstream mengukur pesan, bukan permintaan.
- Error klien (kode status HTTP 400-499) dihitung (tidak termasuk 429).
- Kuota dihitung per menit, tetapi menit ini tidak selaras dengan jam.
Kuota pemantauan
Anda dapat melihat kuota, penggunaan, dan error di Konsol Google Cloud:
- Buka Google Cloud console
- Pilih APIs & services
- Dari daftar tabel, pilih Firebase Cloud Messaging API
- Pilih QUOTA & SYSTEM LIMITS.
CATATAN: Grafik ini tidak benar-benar selaras dengan menit kuota, artinya 429 mungkin ditampilkan saat traffic tampak berada di bawah kuota.
Meminta penambahan kuota
Sebelum meminta penambahan kuota, pastikan:
- Penggunaan Anda secara rutin ≥ 80% dari kuota selama minimal 5 menit berturut-turut per hari.
- Anda memiliki rasio error klien < 5%, terutama selama traffic puncak.
- Anda mematuhi praktik terbaik terkait pengiriman pesan dalam skala besar.
Jika memenuhi kriteria ini, Anda dapat mengirimkan permintaan peningkatan kuota hingga +25% dan FCM akan berupaya semaksimal mungkin untuk memenuhi permintaan tersebut (tidak ada peningkatan yang dapat dijamin).
Jika Anda memerlukan kuota pesan downstream lebih banyak karena peluncuran yang akan datang atau peristiwa sementara, mintalah kuota Anda setidaknya 15 hari sebelumnya agar terdapat waktu yang cukup untuk menangani permintaan tersebut. Untuk permintaan besar (>18 juta pesan per menit), diperlukan pemberitahuan setidaknya 30 hari sebelumnya. Peluncuran dan permintaan peristiwa khusus tetap tunduk pada persyaratan rasio error klien dan praktik terbaik.
Lihat juga FAQ tentang kuota FCM.
Batas pesan topik
Tingkat penambahan atau penghapusan langganan topik dibatasi hingga 3.000 QPS per project.
Untuk mengetahui tingkat pengiriman pesan, baca artikel mengenai Throttling Fanout.
Throttling fanout
Fanout pesan adalah proses pengiriman pesan ke beberapa perangkat, seperti saat Anda menarget topik dan grup, atau saat Anda menggunakan Notifications composer untuk menarget audience atau segmen pengguna.
Fanout pesan tidak berjalan seketika, jadi terkadang ada beberapa fanout yang sedang diproses secara bersamaan. Batas jumlah fanout pesan yang diproses secara bersamaan per project adalah 1.000. Di atas itu, kami dapat menolak permintaan fanout tambahan atau menunda fanout permintaan tersebut sampai beberapa fanout yang sedang diproses selesai.
Kapasitas fanout aktual yang dapat dicapai dipengaruhi oleh jumlah project yang meminta fanout pada saat yang bersamaan. Tidak jarang fanout untuk suatu project mencapai 10.000 QPS, tetapi angka tersebut bukan jaminan dan merupakan hasil dari total beban pada sistem. Penting untuk diperhatikan bahwa kapasitas fanout yang tersedia dibagi antar-project dan bukan untuk seluruh permintaan fanout. Jadi, jika project Anda memiliki dua fanout yang sedang diproses, setiap fanout hanya akan mendapatkan setengah dari kapasitas fanout yang tersedia. Cara yang disarankan untuk memaksimalkan kecepatan fanout Anda adalah dengan hanya memiliki satu fanout aktif yang sedang diproses dalam satu waktu.
Throttling pesan yang dapat diciutkan
Seperti yang dijelaskan dalam artikel Pesan yang dapat diciutkan, pesan ini adalah notifikasi bebas konten yang didesain agar dapat menciut secara bertumpuk. Jika developer terlalu sering mengulangi pesan yang sama ke suatu aplikasi, kami akan menunda (men-throttle) pesan untuk mengurangi dampak pada baterai pengguna.
Misalnya, jika Anda mengirim sejumlah besar permintaan sinkronisasi email baru ke satu perangkat, kami mungkin menunda permintaan sinkronisasi email berikutnya selama beberapa menit sehingga perangkat dapat melakukan sinkronisasi pada tingkat rata-rata yang lebih rendah. Throttling ini dilakukan semata-mata untuk membatasi dampak pada baterai yang dialami oleh pengguna.
Jika kasus penggunaan Anda membutuhkan pola pengiriman burst tinggi, pesan yang tidak dapat diciutkan mungkin merupakan pilihan yang tepat. Untuk pesan semacam itu, pastikan Anda memasukkan konten ke dalamnya untuk mengurangi dampak pada baterai.
Kami membatasi burst berisi 20 pesan yang dapat diciutkan per aplikasi per perangkat, dengan isi ulang 1 pesan setiap 3 menit.
Tingkat pesan maksimum ke satu perangkat
Untuk Android, Anda dapat mengirim hingga 240 pesan per menit dan 5.000 pesan per jam ke satu perangkat. Batas yang tinggi ini dimaksudkan untuk memungkinkan burst traffic jangka pendek, seperti ketika pengguna berinteraksi dengan cepat melalui chat. Dengan batas ini, error dalam logika pengiriman tidak akan menghabiskan baterai pada suatu perangkat secara tidak sengaja.
Untuk iOS, kami akan menampilkan error saat tarif melebihi batas APN.