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 einerGoogle Cloud Ressource Ihr Google Cloud Projekt 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 nebenläufig 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 derGoogle Cloud Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud Ressourcen.

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 Google Cloud Projektebene. Die Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf das verfügbare Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.

Weitere Informationen finden Sie unter dem Cloud-Kontingente – Übersicht.

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

Kontingente

Für Media CDN gelten die folgenden Kontingente. Wenn Sie ein höheres Kontingent benötigen, wenden Sie sich an Ihr Google Cloud Vertriebsteam und fordern Sie Anpassungen an. Weitere Informationen finden Sie unter Kontingentanpassung anfordern.

Konfiguration

Element Standardkontingent
Maximale Anzahl von EdgeCacheService-Ressourcen pro Projekt 20
Maximale Anzahl von EdgeCacheOrigin-Ressourcen pro Projekt 30
Maximale Anzahl von EdgeCacheKeyset-Ressourcen pro Projekt 10

System limits

Für Media CDN gelten die folgenden Limits.

Konfiguration

Element Limits Hinweise
Maximale Anzahl von RouteRules-Ressourcen pro EdgeCacheService 200

Jeder EdgeCacheService kann bis zu 200 RouteRules Ressourcen definieren.
Maximale Anzahl von PathMatchers-Ressourcen pro EdgeCacheService 50

Für jeden EdgeCacheService können bis zu 50 PathMatchers Ressourcen definiert werden.
Maximale Anzahl von SSL-Zertifikaten pro Dienst 5 Informationen zum Kontingent für SSL-Zertifikate pro Projekt finden Sie hier.
Maximale Anzahl von öffentlichen Schlüsseln pro EdgeCacheKeyset 3 Mehrere Schlüssel in einem Schlüsselsatz ermöglichen die Schlüssel rotation. Entfernen Sie nicht verwendete Schlüssel im Laufe der Zeit.
Maximale Anzahl für Validierungen freigegebener Schlüssel pro EdgeCacheKeyset 3 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 -Statuscodes

Element Limits Hinweise
Maximale Größe des Anfrageheaders, einschließlich des Anfragepfads 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-Antwort 431 Request Header Fields Too Long abgelehnt.

Diese Anfragen werden mit einem statusDetails von headers_too_long protokolliert, wenn die Protokollierung aktiviert ist.

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

Anfragen mit einem Text, der dieses Limit überschreitet, werden mit dem HTTP 413 Content Too Large Statuscode abgelehnt.

Maximale Größe des Antwortheaders Ungefähr 128 KiB

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

Maximale Größe cachefähiger Objekte 100 GiB

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

Dieses Limit kann auf bis zu 1 TiB erhöht werden. Wenn Sie ein höheres Limit benötigen, wenden Sie sich an Ihren Google-Supportmitarbeiter.

Maximale Größe nicht cachefähiger Antworten 10239 MiB

Dies ist die maximale Anzahl von Byte in einer Antwort (einschließlich Headern), die von Media CDN als Proxy verwendet werden, wenn ein Objekt nicht cachefähig ist. Nicht cachefähige Antworten werden nach Erreichen des Limits abgeschnitten.

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.

Unabhängig vom verwendeten Protokoll werden alle Header in Kleinbuchstaben umgewandelt.

Beispiel: Host wird zu host und Keep-Alive wird 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
Außerkraftsetzungen pro EdgeCacheService 10 pro Minute
Alle Aufrufe, die nicht im networkservices Namespace enthalten sind, pro Projekt 1.200 Aufrufe pro Minute
Schreibgeschützt: GetEdgeCache*, ListEdgeCache* pro Projekt 100 pro Minute
Lesen/Schreiben: alles im networkservices Namespace, das nicht als schreibgeschützt markiert ist, pro Projekt 100 pro Minute

Wir empfehlen, Update-Anfragen wie create, patch und delete einzeln zu senden. Die API stellt zwar mehrere gleichzeitige Anfragen in die Warteschlange, aber wenn Sie diese Anfragen gleichzeitig senden, kann dies zu einer erheblich höheren Latenz und längeren Verarbeitungszeiten führen, da das System die einzelnen Elemente seriell verarbeitet.

Client-Timeouts

Zeitlimit Maximale Dauer Status code 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.

Ursprungs-Timeouts

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

    Beide Timeouts umfassen die Zeit, die der Ursprung benötigt, um Header zurückzugeben und zu bestimmen, 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 maxAttempts festgelegten für den konfigurierten Ursprung angerechnet.

    Wenn Media CDN auf eine Antwort stößt, die keine Weiterleitung ist, 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.

  • responseTimeout und readTimeout steuern, wie lange eine gestreamte Antwort dauern kann. Nachdem Media CDN feststellt, dass eine vorgelagerte 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 Wert maxAttemptsTimeout 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. Ein HTTP-Statuscode 504 wird zurückgegeben, wenn das Zeitlimit vor der Rückgabe einer Antwort erreicht wird.

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 den 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 Byte des Textes empfangen werden. Wenn dieses Zeitlimit erreicht wird, bevor die Antwort vollständig ist, wird die Antwort abgeschnitten und protokolliert.

Kontingente verwalten

MitMedia CDN werden Kontingente für die Ressourcennutzung aus verschiedenen Gründen festgelegt. Kontingente schützen unter anderem die gesamte Google Cloud -Community vor unerwarteten Nutzungsspitzen. Außerdem unterstützen Kontingente Nutzer, die Google Cloud mit der kostenlosen Stufe prüfen, dabei, im Rahmen der Testversion zu verbleiben.

Alle Projekte beginnen mit den gleichen Kontingenten, die Sie ändern können, indem Sie zusätzliche Kontingente anfordern. Einige Kontingente könnten entsprechend Ihrer Nutzung eines Produkts automatisch erhöht werden.

Berechtigungen

Zur Anzeige von Kontingenten oder zur Anforderung von Kontingenterhöhungen benötigen IAM-Hauptkonten (Identity and Access Management) eine der folgenden Rollen:

Aufgabe Erforderliche Rolle
Kontingente für ein Projekt prüfen Beispiele:
Kontingente ändern, zusätzliche Kontingente anfordern Beispiele:
  • Project Owner (roles/owner)
  • Project Editor (roles/editor)
  • Quota Administrator (roles/servicemanagement.quotaAdmin)
  • Eine benutzerdefinierte Rolle mit der Berechtigung serviceusage.quotas.update

Kontingent prüfen

Console

  1. Rufen Sie in der Google Cloud Console die Seite Kontingente auf.

    Kontingente aufrufen

  2. Mit dem Feld Tabelle filtern können Sie nach den zu aktualisierenden Kontingenten suchen. Wenn Sie den Namen des Kontingents nicht kennen, verwenden Sie stattdessen die Links auf dieser Seite.

gcloud

Führen Sie mit der Google Cloud CLI den folgenden Befehl aus, um Ihre Kontingente zu prüfen. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID:

    gcloud compute project-info describe --project PROJECT_ID

Mit dem folgenden Befehl prüfen Sie das genutzte Kontingent in einer Region:

    gcloud compute regions describe example-region

Fehler beim Überschreiten Ihres Kontingents

Wenn Sie ein Kontingent mit einem gcloud-Befehl überschreiten, gibt gcloud eine quota exceeded-Fehlermeldung aus und liefert den Exit-Code 1.

Wenn Sie mit einer API-Anfrage ein Kontingent überschreiten,gibt Google Cloud den folgenden HTTP-Statuscode zurück: 413 Request Entity Too Large. Google Cloud

Weitere Kontingente anfordern

Verwenden Sie die Google Cloud Console, um die meisten Kontingente anzupassen. Weitere Informationen finden Sie unter Kontingentanpassung beantragen.

Ressourcenverfügbarkeit

Jedes Kontingent stellt die maximale Anzahl an Ressourcen eines bestimmten Typs dar, die Sie erstellen können, sofern der Ressourcentyp verfügbar ist. Beachten Sie, dass Kontingente die Verfügbarkeit von Ressourcen nicht garantieren. Selbst wenn Sie ein verfügbares Kontingent haben, können Sie keine neue Ressource erstellen, wenn keine verfügbar ist.

Beispiel: Sie haben noch ein ausreichendes Kontingent zum Erstellen einer neuen regionalen externen IP-Adresse in einer bestimmten Region. Dies ist jedoch nicht möglich, wenn in dieser Region keine externen IP-Adressen verfügbar sind. Die Verfügbarkeit von zonalen Ressourcen kann sich auch auf Ihre Fähigkeit auswirken, eine neue Ressource zu erstellen.

Es kommt nur selten vor, dass Ressourcen in einer kompletten Region nicht verfügbar sind. Ressourcen innerhalb einer Zone können aber manchmal vorübergehend ausgeschöpft sein, ohne dass sich das auf das Service Level Agreement (SLA) für den Ressourcentyp auswirkt. Weitere Informationen finden Sie im entsprechenden SLA für die Ressource.