Kontingente und Limits

In diesem Dokument sind die Kontingente und Systemlimits für Media CDN aufgeführt.

  • Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern.
  • Systemlimits sind feste Werte, die nicht geändert werden können.

Google Cloud nutzt Kontingente, um für Fairness zu sorgen und Spitzen bei der Ressourcennutzung und ‑verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Ressource vonGoogle Cloud Ihr Projekt von Google Cloud nutzen kann. 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. Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community der Nutzer vonGoogle Cloud schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Ressourcen von Google Cloud .

Das Cloud-Kontingentsystem tut Folgendes:

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 auszuführen versuchen, schlägt dann fehl.

Kontingente gelten in der Regel auf der Ebene des Projekts von Google Cloud . Die Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf das verfügbare Kontingent in einem anderen Projekt. Innerhalb eines Projekts von Google Cloud werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.

Für Media CDN-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.

Limits

Für Media CDN gelten die folgenden Limits.

Konfiguration

Element Limits Hinweise
Maximale Anzahl von EdgeCacheService 20 pro Projekt Wenden Sie sich an Ihr Google Cloud -Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
Maximale Anzahl von EdgeCacheOrigin 30 pro Projekt Wenden Sie sich an Ihr Google Cloud -Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
Maximale Anzahl von EdgeCacheKeyset 10 pro Projekt Wenden Sie sich an Ihr Google Cloud -Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
Maximale Anzahl von RouteRules pro EdgeCacheService 2000

Für jedes EdgeCacheService können bis zu 10 PathMatchers definiert werden und für jedes PathMatcher bis zu 200 RouteRules.

Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von SSL-Zertifikaten pro Dienst 5 Dieses Limit kann nicht erhöht werden. Beachten Sie auch das Kontingent pro Projekt für SSL-Zertifikate.
Maximale Anzahl öffentlicher Schlüssel pro EdgeCacheKeyset 3 Dieses Limit kann nicht erhöht werden. Mehrere Schlüssel in einem Schlüsselsatz wurden für die Schlüsselrotation entwickelt: Sie sollten ältere und nicht verwendete Schlüssel im Laufe der Zeit entfernen.
Maximale Anzahl für Validierungen freigegebener Schlüssel pro EdgeCacheKeyset 3 Dieses Limit kann nicht erhöht werden. Mehrere Schlüssel in einem Schlüsselsatz wurden für die Schlüsselrotation entwickelt: Sie sollten ältere und nicht verwendete Schlüssel im Laufe der Zeit entfernen.

HTTP-Header, -Anfragen und -Antworten

Element Limits Hinweise
Maximale Anfrageheader-Größe, einschließlich Anfragepfad 16 KiB Dieses Limit kann nicht erhöht werden.

Je nach zugrunde liegendem Protokoll wird die Anfrageverbindung entweder geschlossen, ohne dass ein Antwortcode geschrieben wird, oder die Anfrage wird mit einer HTTP-431 Request Header Fields Too Long-Antwort abgelehnt.

Diese Anfragen werden mit einem statusDetails von headers_too_long protokolliert, wenn das Logging aktiviert ist.

Maximale Größe des Anfragetexts 16 KiB Dieses Limit kann nicht erhöht werden.

Anfragen mit einem Textkörper, der dieses Limit überschreitet, werden mit dem HTTP-Statuscode 413 Content Too Large abgelehnt.

Maximale Größe des Antwortheaders Ca. 128 KiB Dieses Limit kann nicht erhöht werden.

Ursprungsantworten mit Headern, die dieses Limit überschreiten, führen dazu, dass ein HTTP 502 an den Client gesendet wird. Diese werden mit einem statusDetails von backend_response_headers_too_long protokolliert, wenn das Logging aktiviert ist.

Maximale Größe cachefähiger Objekte 100 GiB Dieses Limit kann nicht erhöht werden.

Dies ist die maximale Größe von Objekten am Ursprung, die Media CDN im Cache speichern kann. Größere Objekte werden als nicht cachefähig behandelt.

Maximale Größe nicht cachefähiger Antworten 500 MiB Dieses Limit kann nicht erhöht werden.

Die maximale Anzahl von Bytes in einem Antworttext, die Media CDN weiterleitet, wenn ein Objekt nicht im Cache gespeichert werden kann. Nicht cachefähige Antworten werden gekürzt, sobald das Limit erreicht ist.

Umwandlung der Header in Kleinbuchstaben Immer für Media CDN Media CDN folgt den HTTP/2-Konventionen für Groß- und Kleinschreibung von Anfrage- und Antwortheadern.

Alle Header werden ungeachtet des verwendeten Protokolls in Kleinbuchstaben umgewandelt.

Beispiel: Host wird zu host und Keep-Alive zu keep-alive.

Die Groß- und Kleinschreibung von Headerwerten wird nicht geändert.

Limits für API-Anfrageraten

Wenn Sie eine höhere Ratenbegrenzung für API-Anfragen benötigen, können Sie die aktuelle Verwendung prüfen und eine Erhöhung anfordern.

Element Limits
Ungültigmachungen 10 pro Minute pro EdgeCacheService
Alle Aufrufe, die nicht im Namespace networkservices enthalten sind 1.200 Aufrufe pro Minute und Projekt
Schreibgeschützt: GetEdgeCache*, ListEdgeCache* 100 pro Minute und Projekt
Lesen/Schreiben: alles im Namespace networkservices, das nicht als schreibgeschützt markiert ist 100 pro Minute und Projekt

Wir empfehlen, Aktualisierungsanfragen wie create, patch und delete einzeln zu senden. Die API stellt zwar mehrere gleichzeitige Anfragen in die Warteschlange, aber das gleichzeitige Senden dieser Anfragen kann zu einer erheblich erhöhten Latenz und längeren Verarbeitungszeiten führen, da das System jedes Element seriell verarbeitet.

Client-Timeouts

Zeitlimit Maximale Dauer Statuscode Beschreibung
Maximum request duration 5 Minuten HTTP 408 Request Timeout Die maximale Dauer für die Antwort auf eine einzelne Anfrage.
Header timeout 10 Sekunden HTTP 408 Request Timeout Wie lange der Client benötigen darf, um den vollständigen Satz von Anfrageheadern zu senden.

Ursprungszeitlimits

  • connectTimeout und maxAttemptsTimeout begrenzen, wie lange Media CDN benötigt, um eine verwendbare Antwort zu finden.

    Beide Zeitüberschreitungen umfassen die Zeit, die der Ursprung benötigt, um Header zurückzugeben und festzulegen, ob ein Failover oder eine Weiterleitung verwendet werden soll. connectTimeout gilt unabhängig für jeden Ursprungsversuch, während maxAttemptsTimeout die Zeit einschließt, die für die Verbindung bei allen Ursprungsversuchen erforderlich ist, einschließlich Failovers und Weiterleitungen. Das Folgen einer Weiterleitung zählt als zusätzlicher Versuch, eine Verbindung zum Ursprung herzustellen, und wird auf die für den konfigurierten Ursprung festgelegten maxAttempts angerechnet.

    Wenn Media CDN auf eine Antwort ohne Weiterleitung trifft, z. B. von einem Weiterleitungs- oder Failover-Ursprung, gelten die Werte readTimeout und responseTimeout. Weitergeleitete Ursprünge verwenden die Werte connectTimeout, readTimeout und responseTimeout, die für den EdgeCacheOrigin konfiguriert sind, der auf die Weiterleitung gestoßen ist.

  • Mit responseTimeout und readTimeout wird gesteuert, wie lange eine gestreamte Antwort dauern kann. Nachdem Media CDN festgestellt hat, dass eine Upstream-Antwort verwendet wird, sind weder connectTimeout noch maxAttemptsTimeout relevant. An diesem Punkt treten readTimeout und responseTimeout in Kraft.

Media CDN führt maximal vier Ursprungsversuche über alle Ursprünge hinweg aus, unabhängig von den von jedem EdgeCacheOrigin festgelegten maxAttempts. Media CDN verwendet den maxAttemptsTimeout-Wert aus dem primären EdgeCacheOrigin. Die Zeitlimitwerte pro Versuch (connectTimeout, readTimeout und responseTimeout) werden für den EdgeCacheOrigin jedes Versuchs konfiguriert.

In der folgenden Tabelle werden die Zeitlimitfelder beschrieben:

Feld Standard Beschreibung
connectTimeout 5 Sekunden

Der maximale Zeitraum, den Media CDN ab dem Starten der Anfrage an den Ursprung benötigen darf, bis Media CDN bestimmt, ob die Antwort verwendbar ist. In der Praxis deckt connectTimeout den Zeitraum ab, der mit dem Erstellen der Anfrage beginnt und in der Folge das Ausführen von DNS-Lookups und TLS-Handshakes, das Herstellen einer TCP/QUIC-Verbindung und schließlich das Abrufen der Antwortheader umfasst, die den HTTP-Statuscode enthalten.

Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 15 Sekunden sein.
maxAttemptsTimeout 15 Sekunden

Die maximale Zeit für alle Verbindungsversuche zum Ursprung, einschließlich Failover-Ursprünge, bevor ein Fehler an den Client zurückgegeben wird. Wenn das Zeitlimit erreicht ist, bevor eine Antwort zurückgegeben wird, wird der HTTP-Statuscode 504 zurückgegeben.

Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 30 Sekunden sein.

Diese Einstellung definiert die Gesamtdauer für alle Ursprungsverbindungsversuche, einschließlich Failover-Ursprünge, um die Gesamtzeit zu begrenzen, die Clients warten müssen, bis das Streamen von Inhalten startet. Es wird nur der erste maxAttemptsTimeout-Wert verwendet, wobei der erste durch den für die angegebene Route konfigurierten Ursprung definiert wird.
readTimeout 15 Sekunden

Die maximale Wartezeit zwischen Lesevorgängen einer einzelnen HTTP-Antwort. Das readTimeout wird durch das responseTimeout begrenzt. Alle Lesevorgänge der HTTP-Antwort müssen innerhalb der durch das responseTimeout festgelegten Frist abgeschlossen werden. Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 30 Sekunden sein. Wenn dieses Zeitlimit erreicht wird, bevor die Antwort vollständig ist, wird die Antwort abgeschnitten und protokolliert.
responseTimeout 30 Sekunden

Die maximale Dauer, bis eine Antwort abgeschlossen sein muss.

Das Zeitlimit muss ein Wert zwischen 1 Sekunde und 120 Sekunden sein.

Die Dauer wird ab dem Zeitpunkt gemessen, an dem die ersten Body-Bytes empfangen werden. Wenn dieses Zeitlimit erreicht wird, bevor die Antwort vollständig ist, wird die Antwort abgeschnitten und protokolliert.

Manage quotas

Media CDN enforces quotas on resource usage for various reasons. For example, quotas protect the community of Google Cloud users by preventing unforeseen spikes in usage. Quotas also help users who are exploring Google Cloud with the free tier to stay within their trial.

All projects start with the same quotas, which you can change by requesting additional quota. Some quotas might increase automatically based on your use of a product.

Permissions

To view quotas or request quota increases, Identity and Access Management (IAM) principals need one of the following roles.

Task Required role
Check quotas for a project One of the following:
Modify quotas, request additional quota One of the following:
  • Project Owner (roles/owner)
  • Project Editor (roles/editor)
  • Quota Administrator (roles/servicemanagement.quotaAdmin)
  • A custom role with the serviceusage.quotas.update permission

Check your quota

Console

  1. In the Google Cloud console, go to the Quotas page.

    Go to Quotas

  2. To search for the quota that you want to update, use the Filter table. If you don't know the name of the quota, use the links on this page instead.

gcloud

Using the Google Cloud CLI, run the following command to check your quotas. Replace PROJECT_ID with your own project ID.

    gcloud compute project-info describe --project PROJECT_ID

To check your used quota in a region, run the following command:

    gcloud compute regions describe example-region

Errors when exceeding your quota

If you exceed a quota with a gcloud command, gcloud outputs a quota exceeded error message and returns with the exit code 1.

If you exceed a quota with an API request, Google Cloud returns the following HTTP status code: 413 Request Entity Too Large.

Request additional quota

To adjust most quotas, use the Google Cloud console. For more information, see Request a quota adjustment.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, if that resource is available. It's important to note that quotas don't guarantee resource availability. Even if you have available quota, you can't create a new resource if it is not available.

For example, you might have sufficient quota to create a new regional, external IP address in a given region. However, that is not possible if there are no available external IP addresses in that region. Zonal resource availability can also affect your ability to create a new resource.

Situations where resources are unavailable in an entire region are rare. However, resources within a zone can be depleted from time to time, typically without impact to the service level agreement (SLA) for the type of resource. For more information, review the relevant SLA for the resource.