In diesem Dokument sind die für App Engine geltenden Kontingente und Limits aufgeführt.
Ein Kontingent schränkt ein, wie viel von einer bestimmten gemeinsam genutzten Google Cloud-Ressource Ihr Cloud-Projekt nutzen kann, einschließlich Hardware, Software und Netzwerkkomponenten.
Kontingente sind 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.
- Eine Möglichkeit bietet, das Kontingent zu ändern oder anzufordern.
Wenn ein Kontingent ü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 Cloud-Projekt und werden von allen Anwendungen und IP-Adressen geteilt, die dieses 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.
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.
Wenn Sie die Abrechnung für Ihre Anwendung aktivieren, werden die Sicherheitsgrenzwerte der Anwendung erhöht. Weitere Informationen finden Sie im Abschnitt Ressourcen.
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='[email protected]', from='[email protected]', 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? Wenn Sie ein höheres E-Mail-Kontingent benötigen, können Sie E-Mails mit SendGrid senden. Für alle anderen Kontingenterhöhungen können Sie als Nutzer der Supportpakete Silber, Gold oder Platin beim zuständigen Supportmitarbeiter höhere Durchsatzlimits anfordern.
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.
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, das in der Container Registry gespeichert wird. 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“ (Front-End und Back-End) 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 |
---|---|
„F“-Instanzen | 28 kostenlose Stunden pro Tag |
„B“-Instanzen | 9 kostenlose Stunden 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 die Operations-Suite von Google Cloud. Weitere Informationen zu Preisen und Limits finden Sie in der Preisübersicht der Operations-Suite von Google Cloud.
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.
- Gesendete Nachrichten
- Die Gesamtzahl der Nachrichten, die von der Anwendung gesendet wurden. Das maximale Kontingent für gesendete Nachrichten bleibt bis zur Begleichung der ersten Abrechnung Ihrer Anwendung innerhalb des kostenlosen Bereichs.
- Gesendete Administratornachrichten
- 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.
Aufgabenwarteschlange
- Task Queue API-Aufrufe
- Die Gesamtzahl der Aufrufe der Task Queue API durch die Anwendung, um eine Aufgabe in die Warteschlange zu stellen.
- Anzahl der in der Aufgabenwarteschlange gespeicherten Aufgaben
- Die Gesamtanzahl der Aufgaben, die von der Anwendung in die Warteschlange gestellt und noch nicht ausgeführt wurden.
- Bytemenge der in der Aufgabenwarteschlange gespeicherten Aufgaben
- Die genutzten Byte von Aufgaben, die von der Anwendung in die Warteschlange gestellt und noch nicht ausgeführt wurden.
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 |
---|---|---|
Task Queue API-Aufrufe | 1.000.000.000 | – |
Verwaltungsaufrufe der Aufgabenwarteschlangen (über die Cloud Console) | 10.000 | – |
Ressource | Standardlimit |
---|---|
Anzahl der in der Aufgabenwarteschlange gespeicherten Aufgaben | 10.000.000.000 |
Bytemenge der in der Aufgabenwarteschlange gespeicherten Aufgaben | – |
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. Sie können die maximale Byteanzahl der gespeicherten Aufgaben in Ihrer Warteschlangenkonfiguration festlegen. 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. |
Pull-Warteschlangenlimits | |
---|---|
Maximale Aufgabengröße | 1 MB |
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 |
Maximale Anzahl von Aufgaben, die in einem Vorgang freigegeben werden können | 1.000 Aufgaben |
Maximale Nutzlastmenge beim Freigeben eines Stapels von Aufgaben | 32 MB |
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 |