Unser Ziel ist es, alle mit FCM gesendeten Nachrichten zuzustellen. Die Zustellung jeder Nachricht kann jedoch manchmal zu einer schlechten Nutzererfahrung führen. In anderen Fällen müssen wir Grenzen festlegen, damit FCM einen skalierbaren Dienst für alle Absender bereitstellen kann. Die in diesem Abschnitt beschriebenen Arten von Limits und Kontingenten helfen uns, diese wichtigen Faktoren in Einklang zu bringen.
Drosselung nachgelagerter Nachrichten
Mit der HTTP v1 API wurden Kontingente pro Projekt und Minute für Downstream-Messaging eingeführt. Das Standardkontingent von 600.000 Nachrichten pro Minute deckt über 99% der FCM-Entwickler ab und schützt gleichzeitig die Stabilität des Systems und minimiert die Auswirkungen von Projekten mit Spitzen.
Spitzen im Traffic können zu Fehlern durch Kontingentüberschreitung führen. Wenn das Kontingent überschritten wird, gibt das System den HTTP-Statuscode 429 (QUOTA_EXCEEDED) zurück, bis das Kontingent in der folgenden Minute wieder aufgefüllt wird. 429-Antworten können auch in Überlastungssituationen zurückgegeben werden. Wir empfehlen Ihnen daher dringend, 429-Antworten gemäß den veröffentlichten Empfehlungen zu verarbeiten.
Hinweis:
- Beim Downstream-Kontingent werden Nachrichten und nicht Anfragen gemessen.
- Clientfehler (HTTP-Statuscode 400–499) werden gezählt (außer 429).
- Kontingente gelten pro Minute, aber diese Minuten sind nicht an die Uhrzeit angepasst.
Kontingent für Monitoring
Sie können Kontingente, Nutzung und Fehler in der Google Cloud Console ansehen:
- Rufen Sie die Google Cloud-Konsole auf.
- Wählen Sie APIs & Dienste aus.
- Wählen Sie in der Tabellenliste die Firebase Cloud Messaging API aus.
- Wählen Sie KONTINGENTE UND SYSTEMLIMITS aus.
HINWEIS: Diese Grafiken sind nicht genau auf die Kontingentminuten abgestimmt. Das bedeutet, dass 429-Fehler ausgegeben werden können, obwohl der Traffic unter dem Kontingent liegt.
Kontingenterhöhung anfordern
Bevor Sie eine Kontingenterhöhung beantragen, sollten Sie Folgendes prüfen:
- Ihre Nutzung liegt regelmäßig mindestens 5 Minuten pro Tag bei ≥ 80% des Kontingents.
- Sie haben ein Client-Fehlerverhältnis von unter 5 %, insbesondere bei Spitzen-Traffic.
- Sie halten sich an die Best Practices für das Senden von Mitteilungen in großem Umfang.
Wenn Sie diese Kriterien erfüllen, können Sie eine Kontingenterhöhung um bis zu +25% beantragen. FCM wird sich nach Kräften bemühen, dem Antrag nachzukommen (eine Erhöhung kann nicht garantiert werden).
Wenn Sie aufgrund eines bevorstehenden Starts oder eines temporären Ereignisses mehr Kontingent für Downstream-Nachrichten benötigen, fordern Sie das Kontingent mindestens 15 Tage im Voraus an, damit genügend Zeit für die Bearbeitung der Anfrage bleibt. Bei großen Anfragen (über 18 Millionen Nachrichten pro Minute) ist eine Vorlaufzeit von mindestens 30 Tagen erforderlich. Anfragen für Markteinführungen und besondere Ereignisse unterliegen weiterhin den Anforderungen an das Client-Fehlerverhältnis und den Best Practices.
Häufig gestellte Fragen zu FCM-Kontingenten
Limit für Themennachrichten
Die Rate für das Hinzufügen oder Entfernen von Themenabos ist auf 3.000 Abfragen pro Sekunde pro Projekt begrenzt.
Informationen zu den Raten für das Senden von Nachrichten finden Sie unter Fanout-Drosselung.
Fan-Out-Drosselung
Beim Fanout von Nachrichten wird eine Nachricht an mehrere Geräte gesendet, z. B. wenn Sie auf Themen und Gruppen ausrichten oder wenn Sie mit dem Notifications Composer auf Zielgruppen oder Nutzersegmente ausrichten.
Das Verteilen von Nachrichten erfolgt nicht sofort. Daher kann es vorkommen, dass mehrere Verteilungen gleichzeitig laufen. Wir beschränken die Anzahl gleichzeitiger Message-Fanouts pro Projekt auf 1.000. Danach lehnen wir möglicherweise zusätzliche Fanout-Anfragen ab oder verschieben die Fanout-Anfragen, bis einige der bereits laufenden Fanouts abgeschlossen sind.
Die tatsächlich erreichbare Fanout-Rate wird durch die Anzahl der Projekte beeinflusst, die gleichzeitig Fanouts anfordern. Eine Fanout-Rate von 10.000 QPS für ein einzelnes Projekt ist nicht ungewöhnlich, aber diese Zahl ist keine Garantie und hängt von der Gesamtlast des Systems ab. Die verfügbare Fanout-Kapazität wird auf Projekte aufgeteilt und nicht auf Fanout-Anfragen. Wenn für Ihr Projekt also zwei Fanouts laufen, wird für jeden Fanout nur die Hälfte der verfügbaren Fanout-Rate verwendet. Am besten maximieren Sie die Fanout-Geschwindigkeit, indem Sie jeweils nur einen aktiven Fanout ausführen.
Minimierbare Nachrichtenbegrenzung
Wie unter Minimierbare Nachrichten beschrieben, sind minimierbare Nachrichten benachrichtigungsbezogene Inhalte, die übereinander minimiert werden können. Wenn ein Entwickler dieselbe Nachricht zu häufig an eine App sendet, verzögern wir die Nachrichten, um die Auswirkungen auf den Akku des Nutzers zu verringern.
Wenn Sie beispielsweise eine große Anzahl neuer E‑Mail-Synchronisierungsanfragen an ein einzelnes Gerät senden, verzögern wir die nächste E‑Mail-Synchronisierungsanfrage möglicherweise um einige Minuten, damit das Gerät mit einer niedrigeren durchschnittlichen Rate synchronisiert werden kann. Diese Drosselung erfolgt ausschließlich, um die Auswirkungen auf den Akku für den Nutzer zu begrenzen.
Wenn Ihr Anwendungsfall hohe Burst-Sende-Muster erfordert, sind nicht minimierbare Nachrichten möglicherweise die richtige Wahl. Achten Sie bei solchen Nachrichten darauf, dass der Inhalt in den Nachrichten enthalten ist, um die Akkukosten zu senken.
Wir beschränken minimierbare Nachrichten auf 20 Nachrichten pro App und Gerät. Danach wird alle 3 Minuten eine neue Nachricht hinzugefügt.
Maximale Nachrichtenrate für ein einzelnes Gerät
Unter Android können Sie bis zu 240 Nachrichten pro Minute und 5.000 Nachrichten pro Stunde an ein einzelnes Gerät senden. Dieser hohe Grenzwert soll kurzfristige Traffic-Spitzen ermöglichen, z. B. wenn Nutzer schnell über den Chat interagieren. Dieses Limit verhindert, dass Fehler in der Sendelogik versehentlich den Akku eines Geräts entladen.
Unter iOS wird ein Fehler zurückgegeben, wenn die Rate die APNs-Limits überschreitet.