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.
In diesem Dokument sind die für App Engine geltenden Kontingente und Limits aufgeführt. Weitere Informationen zu Kontingenten finden Sie unter Kontingente für Virtual Private Cloud.
Ein Kontingent schränkt ein, wie viel von einer bestimmten gemeinsam genutzten Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen kann, einschließlich Hardware, Software und Netzwerkkomponenten. Daher sind Kontingente Teil eines Systems, das Folgendes tut:
- Ihre Nutzung oder Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen.
- Ihren Verbrauch dieser Ressourcen einschränken, um u. a. für Fairness zu sorgen und Nutzungsspitzen zu reduzieren.
- Konfigurationen verwalten, die automatisch vorgeschriebene Einschränkungen erzwingen.
- Möglichkeit, das Kontingent anzufordern oder zu ändern.
Wenn ein Kontingentlimit überschritten wird, blockiert das System in den meisten Fällen den Zugriff auf die entsprechende Google-Ressource und die Aufgabe, die Sie ausführen möchten, schlägt fehl. In den meisten Fällen gelten Kontingente für jedes Google Cloud-Projekt und werden von allen Anwendungen und IP-Adressen geteilt, die dieses Google Cloud-Projekt verwenden.
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='test@example.com', from='admin@example.com',
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.
Kontingente für die flexible App Engine-Umgebung
Wenn Sie eine Anwendung in der flexiblen App Engine-Umgebung bereitstellen, werden Google Cloud Platform-Ressourcen verbraucht. Obwohl Sie diese Ressourcen möglicherweise nicht ändern können, werden sie auf Ihr Kontingent angerechnet.
So finden Sie beispielsweise die Ressourcennutzung der Instanzressourcen auf der Seite Compute Engine-Ressourcenkontingente.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 |
| 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. |
| Objekt-Schreibvorgänge | 20.000 kostenlos, keine Obergrenze.
Wird das kostenlose Kontingent überschritten, gelten die entsprechenden Tarife. |
| Objekt-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.
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.
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.
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.
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.
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
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 |