Kontingente

Regions-ID

REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.

Hier finden Sie weitere Informationen zu Regions-IDs.

OK

In diesem Dokument sind die für App Engine geltenden Kontingente und Limits aufgeführt.

Google Cloud nutzt Kontingente, um Fairness zu gewährleisten und Spitzen bei Ressourcennutzung und -verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen darf. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt gleichzeitig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Die Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community der Google Cloud-Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud-Ressourcen.

Das Cloud-Kontingentsystem ermöglicht Folgendes:

• Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen
• Ihren Verbrauch dieser Ressourcen einschränken
• Eine Möglichkeit bieten, Änderungen am Kontingentwert anzufordern

Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie ausführen möchten, schlägt fehl.

Kontingente gelten in der Regel auf Google Cloud-Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud-Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.

Für App Engine-Ressourcen gelten auch Beschränkungen. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn dies angegeben ist.

Eine App Engine-Anwendung kann ein bestimmtes Ressourcenkontingent verbrauchen. Sie können den täglichen Verbrauch der Anwendung auf der Google Cloud Console auf der Seite Kontingente einsehen.

Arten von Kontingenten

Die folgenden Arten von Kontingenten gelten für App Engine-Anwendungen:

• Kostenlose Kontingente stellen Ihrer Anwendung eine bestimmte Menge jeder Ressource kostenlos zur Verfügung. Weitere Informationen zu kostenlosen Kontingenten finden Sie auf dieser Seite im Abschnitt Ressourcen. Wenn Ihre Anwendung ein kostenloses Kontingent überschreitet, wird Ihnen die weitere Nutzung der Ressource in Rechnung gestellt.

  Nur die App Engine-Standardumgebung bietet kostenlose Kontingente.

• Tageskontingente schützen die Integrität des App Engine-Systems. Damit wird ein übermäßiger Ressourcenverbrauch durch eine einzelne Anwendung zulasten anderer Anwendungen vermieden. Wenn Sie diese Limits überschreiten, erhalten Sie eine Fehlermeldung. Tageskontingente werden täglich um Mitternacht gemäß Pacific Time (PT) erneuert.
• Minutenkontingente schützen davor, dass Ihre Anwendung ihre gesamten Ressourcen innerhalb kürzester Zeit verbraucht oder dass Anwendungen eine Ressource komplett belegen. Wenn Ihre Anwendung eine Ressource zu schnell verbraucht und dabei eines der Minutenkontingente erschöpft, wird in der Google Cloud Console auf der Seite Kontingente neben dem betreffenden Kontingent der Hinweis „Kontingent erreicht“ angezeigt. Anfragen für Ressourcen, die den Grenzwert des Minutenkontingents erreicht haben, werden abgelehnt.

Projektinhaber und Abrechnungsadministratoren können die Abrechnung für ein Projekt aktivieren.

Ausführliche Informationen dazu, was bei Überschreiten eines Kontingents passiert und wie Sie Kontingentüberschreitungen handhaben, finden Sie unter Vorgehensweise bei erschöpften Ressourcen.

Tipp: Die maximalen Minutenkontingente berücksichtigen hohe Trafficaufkommen, um Trafficspitzen bei der Erwähnung Ihrer Website in den Medien zu bewältigen. Wenn ein bestimmtes Kontingent diese Anforderung Ihrer Meinung nach nicht erfüllt, senden Sie uns Feedback in der Problemverfolgung. Wenn Sie Feedback senden, stellt das keine Anfrage hinsichtlich der Erhöhung Ihres Kontingents dar, aber Sie geben uns damit einen Einblick, welches Kontingent für allgemeine Anwendungsfälle möglicherweise zu niedrig ist.

Wenn Sie extrem hohe Trafficaufkommen erwarten oder Ihre Anwendung beispielsweise aufgrund einer wichtigen Produkteinführung oder umfassender Lasttests besonders hohe Kontingente erfordert, empfiehlt sich die Registrierung für ein Supportpaket.

Ressourcen auffüllen

In App Engine wird die Ressourcennutzung Ihrer Anwendung im Hinblick auf Systemkontingente überwacht. Alle Ressourcenmesswerte werden zu Beginn jedes Kalendertags zurückgesetzt. Dies gilt nicht für gespeicherte Daten, die jeweils den Umfang des genutzten Datenspeichers darstellen.

Tageskontingente werden täglich um Mitternacht gemäß Pacific Time (PT) erneuert. Minutenkontingente werden alle 60 Sekunden erneuert.

Vorgehensweise bei erschöpften Ressourcen

Wenn eine Anwendung alle ihr zugeordneten Ressourcen verbraucht hat, ist sie erst nach dem Auffüllen des Kontingents wieder verfügbar. Dies kann bedeuten, dass Ihre Anwendung erst wieder funktioniert, nachdem das Kontingent erneuert wurde.

Wenn für die Initiierung einer Anfrage erforderliche Ressourcen verbraucht sind, gibt App Engine standardmäßig den Fehlercode 403 oder 503 zurück, anstatt einen Anfrage-Handler aufzurufen. Dieses Verhalten gilt für die Ressource Instanzstunden.

Tipp: Sie können festlegen, dass Ihre Anwendung bei Überschreiten eines Kontingents eine benutzerdefinierte Fehlerseite ausgibt. Weitere Informationen finden Sie in der Referenz zur Konfigurationsdatei für Python (2.7, 3), Java, Go, PHP (5.5, 7) und Node.js.

Für alle anderen Ressourcen, die erschöpft sind, wird eine Ausnahme ausgegeben, wenn die Anwendung versucht, diese zu nutzen. Diese Ausnahme kann von der Anwendung erfasst und verarbeitet werden, indem der Nutzer beispielsweise eine Fehlermeldung erhält. In der Python API ist diese Ausnahme apiproxy_errors.OverQuotaError. In der API für Java ist diese Ausnahme com.google.apphosting.api.ApiProxy.OverQuotaException. In der Go API meldet die Funktion appengine.IsOverQuota, ob ein Fehler einen API-Aufruffehler aufgrund eines nicht ausreichenden verfügbaren Kontingents darstellt.

Das folgende Beispiel zeigt, wie der Fehler OverQuotaError abgefangen werden kann, der von der Methode SendMessage() ausgegeben wird, wenn ein E-Mail-bezogenes Kontingent überschritten wurde:

try:
    mail.SendMessage(to='[e-mail]', from='[e-mail]',
            subject='Test Email', body='Testing')
except apiproxy_errors.OverQuotaError, message:
    # Log the error. logging.error(message)
    # Display an informative message to the user.
    self.response.out.write('The email could not be sent. '
            'Please try again later.')

Überschreitet Ihre Anwendung die Standardlimits? Sie können auch Cloud Customer Care kontaktieren, um höhere Durchsatzlimits anzufordern. Wenn Sie ein höheres E-Mail-Kontingent benötigen, können Sie E-Mails mit SendGrid senden.

Ressourcen

Anwendungen können, entsprechend den geltenden Kontingenten, folgende Ressourcen verwenden. Ressourcen, die auf kostenpflichtige Limits angerechnet werden, sind als „(kostenpflichtig)“ gekennzeichnet. Die Ressourcenmengen geben die Zuteilung über einen Zeitraum von 24 Stunden an.

Die Kosten für zusätzliche Ressourcen finden Sie in der Preisübersicht.

Dienste, Versionen und Instanzen

Die maximale Anzahl von Diensten und Versionen, die bereitgestellt werden kann, hängt von der Preisgestaltung Ihrer Anwendung ab. Sowohl für die flexible Umgebung als auch für die Standardumgebung gelten für Dienste und Versionen die gleichen Limits. Wenn Sie in einer Anwendung beispielsweise Standardversionen und flexible Versionen haben, werden diese Versionen auf das gleiche Limit angerechnet.

Limit	Kostenlose Anwendung	Kostenpflichtige Anwendung
Maximale Anzahl von Diensten pro Anwendung	5	210
Maximale Anzahl von Versionen pro Anwendung	15	210

Es besteht außerdem ein Limit für die Anzahl von Instanzen für jeden Dienst mit einfacher oder manueller Skalierung:

Maximale Anzahl von Instanzen pro manuell bzw. einfach skalierter Version
Kostenlose Anwendung	Kostenpflichtige Anwendung USA	Kostenpflichtige Anwendung EU
20	25 (200 für us-central)	25

Außerdem ist die Anzahl der Instanzen in Standardversionen, die pro Projekt und Region ausgeführt werden können, begrenzt. Die Instanzklasse des Dienstes bestimmt, welches Limit angewendet wird und welchen Beitrag eine Instanz dieses Dienstes zur Kontingentnutzung leistet. Beispielsweise zählt eine F4-Instanz als vier normalisierte Frontend-Instanzen.

Sie können den Kontingentverbrauch für die Instanzanzahl auf der Seite "IAM-Kontingente" einsehen.

Beschreibung	Limit	Kann erhöht werden
Maximale Anzahl von Frontend-Instanzen pro Projekt und Region, gemessen über einen Zeitraum von einer Minute	Hängt von der ausgewählten Region ab. Dieses Limit kann in Regionen mit hoher Kapazität höher oder in kürzlich geöffneten Regionen niedriger sein.	Ja
Maximale Anzahl von Back-End-Instanzen pro Projekt und Region, gemessen über einen Zeitraum von einer Minute	Hängt von der ausgewählten Region ab. Dieses Limit kann in Regionen mit hoher Kapazität höher oder in kürzlich geöffneten Regionen niedriger sein.	Ja

Hinweis:Wie Sie höhere Limits anfordern, erfahren Sie auf dieser Seite.

Auch die Anzahl der Zeichen in der URL Ihrer Anwendung ist begrenzt.

Beschreibung	Limit
Maximale Zeichen im Projekt-URL für die URL VERSION-dot-SERVICE-dot-PROJECT_ID	63

Standardmäßiger Cloud Storage-Bucket

Im standardmäßigen Cloud Storage-Bucket wird wie unten angegeben ein kostenloses Kontingent für die tägliche Nutzung zur Verfügung gestellt. Sie erstellen diesen kostenlosen Standard-Bucket in der Google Cloud Console auf der Seite mit den App Engine-Einstellungen für Ihr Projekt.

Die folgenden Kontingente gelten speziell für die Verwendung des Standard-Buckets. Eine Beschreibung dieser Kontingente finden Sie in der Preisübersicht für multiregionale Cloud Storage-Buckets.

Ressource	Standardlimit
Im standardmäßigen Cloud Storage-Bucket gespeicherte Daten	Erste 5 GB kostenlos, keine Obergrenze
Vorgänge der Klasse A im standardmäßigen Cloud Storage-Bucket	Erste 20.000 Vorgänge/Tag kostenlos, keine Obergrenze
Vorgänge der Klasse B im standardmäßigen Cloud Storage-Bucket	Erste 50.000 Vorgänge/Tag kostenlos, keine Obergrenze
Ausgehender Netzwerktraffic im standardmäßigen Cloud Storage-Bucket	Erste 1 GB kostenlos, keine Obergrenze

Blobstore

Die folgenden Kontingente gelten speziell für die Verwendung des Blobstore.

Gespeicherte Blobstore-Daten

Die Gesamtmenge der im Blobstore gespeicherten Daten. Für kostenpflichtige und kostenlose Anwendungen verfügbar.

Ressource	Standardlimit
Gespeicherte Blobstore-Daten	Erste 5 GB kostenlos, keine Obergrenze

Speicherung von Code und statischen Daten

Limit für statische Daten

In allen Sprachen außer Go dürfen statische Datendateien jeweils maximal 32 MB groß sein. Das Limit für Go ist 64 MB.

Gesamtspeicherplatz

Das Speicherkontingent bezieht sich auf die Gesamtmenge des Codes und der statischen Daten, die von allen Versionen Ihrer Anwendung gespeichert werden. Die gespeicherte Gesamtgröße von Code und statischen Dateien finden Sie in der Tabelle auf der Dashboard-Hauptseite. Die einzelnen Größen werden auf den Bildschirmen „Versionen“ bzw. „Back-Ends“ angezeigt. Bei Anwendungen werden für Code und statische Daten, die 1 GB pro Monat überschreiten, 0,026 $ pro GB berechnet.

Firestore im Datastore-Modus (Datastore)

Das Kontingent für gespeicherte Daten (kostenpflichtig) bezieht sich auf alle im Datenspeicher und in Blobstore für die Anwendung gespeicherten Daten. Weitere in der Google Cloud Console auf dem Bildschirm Kontingentdetails unter „Datastore“ aufgeführte Kontingente gelten speziell für den Datastore-Dienst.

Gespeicherte Daten (kostenpflichtig)

Die Gesamtmenge der Daten, die in den Datenspeicherentitäten und entsprechenden Indexen sowie in Blobstore gespeichert werden.

Dabei ist zu beachten, dass Daten im Datenspeicher erheblichen zusätzlichen Speicherplatzbedarf verursachen können. Dieser Zusatzaufwand hängt von der Anzahl und den Typen der zugehörigen Attribute ab und beinhaltet den von den integrierten und benutzerdefinierten Indexen verwendeten Speicherplatz. Für jede im Datenspeicher gespeicherte Entität sind folgende Metadaten erforderlich:

• Der Entitätsschlüssel, einschließlich Typ, ID bzw. Schlüsselname, sowie die Schlüssel der Ancestors der Entität.
• Name und Wert jedes Attributs. Da der Datenspeicher schemalos ist, muss für jede Entität der Name jedes Attributs zusammen mit dem Attributwert gespeichert werden.
• Alle integrierten und benutzerdefinierten Indexzeilen, die sich auf diese Entität beziehen. Jede Zeile enthält jeweils den Typ der Entität, eine Anzahl an Attributwerten, die von der Indexdefinition abhängt, sowie den Entitätsschlüssel.

Anzahl der Indexe

Die Anzahl der für die Anwendung vorhandenen Datenspeicherindexe. Dies gilt auch für in der Vergangenheit erstellte Indexe, die nicht mehr in der Konfiguration der Anwendung angezeigt werden, aber nicht gelöscht wurden. Weitere Informationen zu Limits finden Sie auf der Seite mit den Datastore-Limits.

Schreibvorgänge

Die Gesamtzahl der Schreibvorgänge in Datastore.

Lesevorgänge

Die Gesamtzahl der Lesevorgänge in Datastore.

Kleine Vorgänge

Die Gesamtzahl der kleinen Vorgänge in Datastore. Kleine Vorgänge umfassen Aufrufe zum Zuweisen von Datastore-IDs oder reine Schlüsselabfragen.

Ressource	Standardlimit
Gespeicherte Daten (kostenpflichtig)	1 GiB kostenlos; keine Obergrenze. Wird das kostenlose Kontingent überschritten, gelten die entsprechenden Tarife.
Anzahl der Indexe	200
Entitäts-Lesevorgänge	50.000 kostenlos, keine Obergrenze. Wird das kostenlose Kontingent überschritten, gelten die entsprechenden Tarife.
Entitäts-Schreibvorgänge	20.000 kostenlos, keine Obergrenze. Wird das kostenlose Kontingent überschritten, gelten die entsprechenden Tarife.
Entitäts-Löschvorgänge	20.000 kostenlos, keine Obergrenze. Wird das kostenlose Kontingent überschritten, gelten die entsprechenden Tarife.
Kleine Vorgänge	Unbegrenzt

Hinweis: Von Datastore Admin und Datastore Viewer generierte Datenspeichervorgänge werden auf Ihr Anwendungskontingent angerechnet.

Bereitstellungen

In einer App Engine-Anwendung sind bis zu 10.000 Bereitstellungen pro Tag möglich.

Bei einer Bereitstellung erstellt Cloud Build ein Container-Image und speichert das Image in Artifact Registry. Falls der von den Images verbrauchte Gesamtspeicherplatz die kostenlose Stufe übersteigt, fallen Kosten an.

Wichtig: Container Registry wurde verworfen und wird demnächst eingestellt. Organisationen, die Container Registry vor dem 8. Januar 2024 nicht verwendet haben, werden standardmäßig neue gcr.io-Repositories in Artifact Registry gehostet. Ab dem 15. Mai 2024 unterstützen Google Cloud-Projekte ohne vorherige Verwendung von Container Registry nur das Hosting und die Verwaltung von Images für die Domain gcr.io in Artifact Registry.

Container Registry soll am 18. März 2025 eingestellt werden. Weitere Informationen zur Einstellung finden Sie unter Einstellung von Container Registry.

Dateien

Das folgende Kontingent gilt für die Gesamtzahl der Anwendungsbereitstellungsdateien.

Dateien	Maximum
Standarddateien pro Anwendung	10.000 Dateien Wenden Sie sich an den Support, um eine Erhöhung zu beantragen.

Instanzstunden

Die Instanznutzung wird mit einem bestimmten Stundensatz nach Instanzlaufzeit berechnet.

Für die Instanzklassen „F“ und „B“ (Frontend und Backend) gibt es eigene kostenlose Kontingente. Beim Einsatz von App Engine-Diensten hängt es von der Instanzklasse des Dienstes ab, welches Kontingent gilt.

Ressource	Kostenloses Kontingent
F1-Instanzen	28 kostenlose Instanzstunden pro Tag
B1-Instanzen	9 kostenlose Instanzstunden pro Tag

Die Berechnung der Instanzstunden beginnt und endet, wenn eine Instanz wie unten beschrieben gestartet bzw. beendet wird, abhängig davon, welchen Skalierungstyp Sie für die Instanz angeben:

• Einfache oder automatische Skalierung: Die Berechnung endet 15 Minuten, nachdem eine Instanz die Verarbeitung der letzten Anfrage abgeschlossen hat.
• Manuelle Skalierung: Die Berechnung endet 15 Minuten, nachdem eine Instanz heruntergefahren wurde.

Falls die Zahl der von App Engine erstellten inaktiven Instanzen die Höchstzahl überschreitet, die Sie in der Google Cloud Console über den Tab „Leistungseinstellungen“ festgelegt haben, fallen für die überzähligen Instanzen keine Instanzstunden an.

Wichtig: Auf der Rechnung werden in den Abrechnungspositionen nicht die Namen der einzelnen Instanzklassen aufgeführt. Stattdessen sehen Sie die Instanzstunden der „B“-Klassen (Backend-Instanzen) und die Instanzstunden der „F“-Klassen (Frontend-Instanzen). Auf der Rechnung wird das entsprechende Vielfache der Instanzstunden für jede von Ihnen verwendete Instanzklasse ausgewiesen. Angenommen, Sie verwenden eine Stunde lang eine F4-Instanz, dann sehen Sie auf der Rechnung den Posten „Frontend-Instanz“ mit vier Instanzstunden zum F1-Satz.

Logs

Die Abrechnung für die Logs API erfolgt beim Abrufen von Logdaten.

Das Kontingent für die Logaufnahme bezieht sich auf die Daten für Anfrage- und Anwendungslogs einer Anwendung. Das Logging für App Engine-Anwendungen erfolgt durch Google Cloud Observability. Weitere Informationen zu Preisen und Limits finden Sie in der Preisübersicht für Google Cloud Observability.

E-Mail

Die Mail API-Nutzung kann auf der Seite IAM-Kontingente eingesehen werden.

Hinweis: Wenn Sie den Kontingentverbrauch einer Anwendung auf der Seite "IAM-Kontingente" aufrufen möchten, muss der App Engine Reporting Service für das Projekt aktiviert sein. Wenn Sie den Dienst nicht aktivieren können, prüfen Sie Ihre Berechtigungen und die Organisationsrichtlinien-Einschränkung constraints/serviceuser.services.

Hinweis:Wie Sie höhere Limits anfordern, erfahren Sie auf dieser Seite.

App Engine berechnet die E-Mail-Nutzung „per Nachricht“, wobei jede E-Mail an jeden Empfänger gezählt wird. Wenn Sie beispielsweise eine E-Mail an zehn Empfänger senden, zählt dies als zehn Nachrichten.

Nachrichten, die nicht an Administratoren gesendet werden

Die Gesamtzahl der von der Anwendung an Nicht-Anwendungsadministratoren gesendeten Nachrichten.

An Administratoren gesendete Nachrichten

Die Gesamtzahl der von der Anwendung an Anwendungsadministratoren gesendeten Nachrichten. Die maximale Gesamtgröße pro Administrator-E-Mail, einschließlich Kopfzeilen, Anhängen und Nachrichtentext, beträgt 16 KB.

Datenvolumen der gesendeten E-Mail-Textkörper

Die Menge der im Nachrichtentext von E-Mails gesendeten Daten.

Gesendete Anhänge

Die Gesamtzahl der zusammen mit E-Mail-Nachrichten gesendeten Anhänge.

Datenvolumen der gesendeten Anhänge

Die Menge der in Anhängen von E-Mail-Nachrichten gesendeten Daten.

Ressource	Standardmäßiges Tageslimit	Maximale Rate
E-Mail-Empfänger	100 Nachrichten	8 Nachrichten/Minute
An Administratoren gesendete E-Mails	5.000 E-Mails	24 E-Mails/Minute
Datenvolumen der gesendeten E-Mail-Textkörper	60 MB	340 KB/Minute
Gesendete Anhänge	2.000 Anhänge	8 Anhänge/Minute
Datenvolumen der gesendeten Anhänge	100 MB	10 MB/Minute

Sie können für die Mail API bis zu 50 autorisierte Absender hinzufügen.

Mehr E-Mails als im E-Mail-Tageskontingent festgelegt senden

Wenn für Ihre Anwendung höhere Kontingente zum Senden von E-Mails erforderlich sind, können Sie einen Drittanbieter wie SendGrid, Mailjet oder Mailgun verwenden.

Anfragen

Ausgehende Bandbreite (kostenpflichtig)

Der aufgrund von Anfragen von der Anwendung gesendete Datenumfang.

Dazu zählen:

• Daten, die aufgrund von sicheren und nicht sicheren Anfragen von Anwendungsservern, statischen Dateiservern oder Blobstore bereitgestellt werden
• In E-Mail-Nachrichten gesendete Daten
• Daten in ausgehenden HTTP-Anfragen, die vom URL-Abrufdienst gesendet wurden

Eingehende Bandbreite

Der aufgrund von Anfragen von der Anwendung empfangene Datenumfang. Eingehende HTTP-Anfragen dürfen jeweils nicht größer als 32 MB sein.

Dazu zählen:

• Von der Anwendung in sicheren und nicht sicheren Anfragen empfangene Daten
• Uploads zum Blobstore
• Als Antwort auf HTTP-Anfragen vom URL-Abrufdienst empfangene Daten

Sichere ausgehende Bandbreite

Der von der Anwendung aufgrund von Anfragen über eine sichere Verbindung gesendete Datenumfang.

Sichere eingehende Bandbreite

Der von der Anwendung aufgrund von Anfragen über eine sichere Verbindung empfangene Datenumfang.

Hinweis: Die ausgehende Bandbreite ist eine kostenpflichtige Ressource, die HTTP-/HTTPS-Anfragen einschließt. Das erste Gigabyte (1 GB) Daten an ausgehender Bandbreite pro Tag ist kostenlos. Für die ausgehende wie auch die eingehende Bandbreite gilt kein Tageslimit oder maximales Kontingent.

Suche

Kostenlose Kontingente für die Suche sind in der folgenden Tabelle aufgeführt. Eine ausführliche Beschreibung der verschiedenen Suchaufruftypen finden Sie in der jeweiligen Dokumentation zu Java, Python und Go.

Search API-Ressourcen werden gemäß den Raten des Preisschemas berechnet.

Ressourcen- oder API-Aufruf	Kostenloses Kontingent
Gesamtspeicherplatz (Dokumente und Indexe)	0,25 GB
Abfragen	1.000 Abfragen pro Tag
Dokumente zu Indexen hinzufügen	0,01 GB pro Tag

Im Kontingentbereich der Anwendungskonsole sehen Sie eine grobe Anzahl der API-Anfragen. Wenn Sie mehrere Dokumente in einem einzigen Aufruf indexieren, steigt die Anzahl der Aufrufe mit der Anzahl der Dokumente.

Diese Limits werden von der Search API festgelegt, um einen zuverlässigen Dienst zu gewährleisten:

• 100 aggregierte Minuten Abfrageausführungszeit pro Minute innerhalb einer Anwendung und eines Index.
• 15.000 Dokumente pro Minute hinzugefügt/gelöscht

Darüber hinaus besteht ein Speicherlimit von 10 GB pro Index. Bei Überschreiten dieses Werts durch eine API wird ein Fehler für unzureichendes Kontingent zurückgegeben. Dieses Limit kann auf bis zu 200 GB erhöht werden. Hierzu müssen Sie von der Google Cloud Console aus in der App Engine Search eine entsprechende Anfrage stellen.

Hinweis: Obwohl diese Limits minutengenau eingehalten werden, zeigt die Google Cloud Console die täglichen Summen für jede Minute an. Kunden mit der Supportstufe Silber, Gold oder Platin können bei dem für sie zuständigen Supportmitarbeiter höhere Durchsatzlimits anfordern.

Task Queue

Wenn eine Aufgabe ausgeführt wird, werden die zugehörigen Anfragen auf die Anfragekontingente der Anwendung angerechnet.

Diese Limits gelten für alle Aufgabenwarteschlangen:

Ressource	Tageslimit	Maximale Rate
Verwaltungsaufrufe der Aufgabenwarteschlangen (über die Cloud Console)	10.000	–

Ressource	Standardlimit
Maximale Anzahl von Warteschlangen (einschließlich Push- und Pull-Warteschlangen, aber ohne Standardwarteschlange)	100 Warteschlangen

Hinweis: Sobald eine Aufgabe ausgeführt oder gelöscht wurde, wird der von ihr belegte Speicher freigegeben. Ihr Speicherkontingent wird in regelmäßigen Abständen aktualisiert, sodass Sie den freigegebenen Speicherplatz möglicherweise nicht sofort sehen. Weitere Informationen finden Sie in der jeweiligen Dokumentation zu Python, Java, Go und PHP.

Die folgenden Limits gelten für Aufgabenwarteschlangen entsprechend ihrem Typ:

Push-Warteschlangenlimits
Maximale Aufgabengröße	100 KB
Ausführungsrate der Warteschlange	500 Aufgabenaufrufe pro Sekunde pro Warteschlange
Maximaler Countdown/ETA für eine Aufgabe	30 Tage ab dem aktuellen Datum und der aktuellen Uhrzeit
Maximale Anzahl von Aufgaben, die in einem Stapel hinzugefügt werden können	100 Aufgaben
Maximale Anzahl von Aufgaben, die in einer Transaktion hinzugefügt werden können	5 Aufgaben
Standardmäßige maximale Anzahl von Aufgabenwarteschlangen	100 Warteschlangen Sie können beim Support eine Erhöhung anfordern.

Cron

Die folgenden Kontingente gelten speziell für Cronjobs.

Cronjobs

Anzahl der Cronjobs.

Ressource	Standardlimit
Cronjob	250 Cronjobs

URL-Abruf

URL Fetch API-Aufrufe

Die Gesamtzahl der Zugriffe der Anwendung auf den URL-Abrufdienst, um eine HTTP- oder HTTPS-Anfrage auszuführen.

Über den URL-Abrufdienst gesendetes Datenvolumen

Die Menge der in Anfragen an den URL-Abrufdienst gesendeten Daten.

Über den URL-Abrufdienst empfangenes Datenvolumen

Die Menge der in Antworten vom URL-Abrufdienst erhaltenen Daten. Wird auch auf das Kontingent „Eingehende Bandbreite“ angerechnet.

Ressource	Tageslimit	Maximale Rate
URL Fetch API-Aufrufe	860.000.000 Aufrufe	660.000 Aufrufe/Minute
Über den URL-Abrufdienst gesendetes Datenvolumen	4,5 TB	3.600 MB/Minute
Über den URL-Abrufdienst empfangenes Datenvolumen	4,5 TB	3.600 MB/Minute