Cloud de Confiance by S3NS verwendet Kontingente, um den Umfang einzuschränken, in dem Sie eine bestimmte freigegebene Cloud de Confiance by S3NS Ressource nutzen können. Jedes Kontingent stellt eine bestimmte zählbare Ressource dar, z. B. API-Aufrufe an einen bestimmten Dienst, die Anzahl der an einen bestimmten Dienst gesendeten Byte oder die Anzahl der Streamingverbindungen, die von Ihrem Projekt gleichzeitig verwendet werden.
Viele Dienste haben auch Limits, die nicht mit dem Kontingentsystem in Zusammenhang stehen. Dies sind feste Einschränkungen wie die maximale Nachrichtengröße oder die Anzahl der Pub/Sub-Ressourcen, die Sie in einem Projekt erstellen können. Diese können nicht erhöht oder verringert werden.
Kontingente ansehen und verwalten
Sie können die aktuellen Kontingentlimits eines Projekts und deren Nutzung im Dashboard „IAM & Verwaltung“ für Kontingente ansehen. Außerdem können Sie dieses Dashboard für Folgendes verwenden:
- Kontingentlimits reduzieren
- Höhere Kontingentlimits beantragen
Weitere Informationen zum Monitoring und zu Benachrichtigungen zu Ihrer Kontingentnutzung finden Sie unter Monitoring.
Zuordnung der Kontingentnutzung
Für den Push-Abonnentendurchsatz wird die Kontingentnutzung anhand des Projekts berechnet, in dem das Push-Abo enthalten ist. Dies ist das Projekt, das im Namen des Abos angezeigt wird.
Für alle anderen Kontingente wird die Nutzung anhand des Projekts berechnet, das mit den in der Anfrage angegebenen Anmeldedaten verknüpft ist. Die Kontingentnutzung wird nicht anhand des Projekts berechnet, das die angeforderte Ressource enthält.
Beispiel: Wenn ein Dienstkonto in Projekt A eine Veröffentlichungsanfrage an ein Thema in Projekt B sendet, wird das Kontingent für Projekt A belastet.
In einigen Fällen möchten Sie möglicherweise, dass die Kontingentnutzung anhand eines anderen Projekts berechnet wird. Mit dem Systemparameter X-Goog-User-Project können Sie das Projekt für die Kontingentzuordnung ändern. Weitere Informationen zu X-Goog-User-Project,
finden Sie unter Systemparameter.
Mit der gcloud CLI können Sie das Projekt für die Kontingentzuordnung für eine bestimmte Anfrage festlegen. Die gcloud CLI sendet den Anfrageheader X-Goog-User-Project.
Sie benötigen die Rolle roles/serviceusage.serviceUsageConsumer oder eine benutzerdefinierte Rolle mit der Berechtigung serviceusage.services.use für das Projekt, das Sie für die Kontingentzuordnung verwenden möchten.
Das folgende Beispiel zeigt, wie Sie eine Liste der Abos im Projekt RESOURCE_PROJECT abrufen und gleichzeitig das Kontingent Verwaltungsvorgänge für das Projekt QUOTA_PROJECT belasten. Führen Sie den folgenden Befehl in Ihrem Google Cloud CLI-Terminal aus:
gcloud pubsub subscriptions list --project=
RESOURCE_PROJECT --billing-project=
QUOTA_PROJECT
Ersetzen Sie QUOTA_PROJECT durch die ID des Cloud de Confiance by S3NS Projekts, für das Sie das Kontingent belasten möchten.
Bei Pub/Sub ist das in Rechnung gestellte Projekt immer das, das die Ressource enthält. Sie können das Projekt nur für die Kontingentzuordnung ändern.
Pub/Sub Kontingente
Die in der folgenden Tabelle aufgelisteten Kontingente können pro Projekt im Dashboard „APIs & Dienste“ für Kontingente aufgerufen und bearbeitet werden.
Regionale Kontingente sind in drei Typen unterteilt:
- Große Regionen:
europe-west1,europe-west4,us-central1,us-east1,us-east4,us-west1,us-west2 - Mittelgroße Regionen:
asia-east1,asia-northeast1,asia-southeast1,europe-west2,europe-west3 - Kleine Regionen: alle anderen Regionen
Kontingente für die genau einmalige Zustellung sind regionsspezifisch. Weitere Informationen finden Sie in der folgenden Tabelle für jede Region.
| Kontingent | Standardkontingentlimit | Beschreibung |
|---|---|---|
| Publisher-Durchsatz pro Region |
|
Die Kontingentnutzung beruht auf der Größe der veröffentlichten
In einer Veröffentlichungsanfrage können mehrere Nachrichten enthalten sein. Für diese Nachrichten wird kein zusätzliches Kontingent berechnet. Die Größe der Nachricht, wie sie für
Kontingentnutzung berechnet wird, umfasst auch das automatisch generierte
|
| Pull-Abonnentendurchsatz pro Region |
|
Die Kontingentnutzung beruht auf der Größe der zurückgegebenen
Die Größe der Nachricht, wie sie für die Kontingentnutzung berechnet wird, umfasst auch das automatisch generierte
|
| Bestätigungsdurchsatz pro Region |
|
Die Kontingentnutzung beruht auf der Größe der
|
| Durchsatz für Push-Abos pro Region |
|
Bei Push-Zustellungsanfragen an den
Push-Endpunkt richtet sich die Kontingentnutzung nach der Größe der
|
| Durchsatz für BigQuery-Abos pro Region |
|
Bei Anfragen an BigQuery richtet sich die Kontingentnutzung nach der Größe der |
| Cloud Storage-Abos Durchsatz pro Region |
|
Bei Anfragen an Cloud Storage richtet sich die Kontingentnutzung nach der Größe der |
| Durchsatz für Bigtable-Abos (Vorschau) pro Region |
|
Bei Anfragen an Bigtable richtet sich die Kontingentnutzung nach der Größe der |
| StreamingPull-Abonnentendurchsatz pro Region |
|
Die Kontingentnutzung beruht auf der Größe der
Für Clientbibliotheken werden StreamingPull Vorgänge nach Möglichkeit verwendet. |
| Anzahl der offenen StreamingPull-Verbindungen pro Region |
|
Die Anzahl der offenen StreamingPull-Verbindungen zu einem beliebigen Zeitpunkt. Siehe StreamingPull. |
| Verwaltungsvorgänge | 6.000 pro Minute (100 Vorgänge pro Sekunde) |
Für jeden Verwaltungsvorgang wird diesem Kontingent eine Einheit angerechnet. Verwaltungsvorgänge umfassen die folgenden RPC-Methoden:
|
| Anzahl der Nachrichten, die aus Abos mit aktivierter genau einmaliger Zustellung pro Region abgerufen wurden |
|
Die Kontingentnutzung beruht auf der Anzahl der
|
| Anzahl der Nachrichten, die bestätigt wurden oder deren Frist verlängert wurde wenn Abos mit aktivierter genau einmaliger Zustellung pro Region verwendet werden |
|
Die Kontingentnutzung beruht auf der Anzahl der Bestätigungs-IDs in
|
Durchsatzkontingenteinheiten
Die Nutzung von Durchsatzkontingenten wird in Einheiten von 1 KB gemessen. 1 KB entspricht 1.000 Byte. Beispiel: In einer PublishRequest mit 105 Nachrichten mit jeweils 50 Byte beträgt die Nutzerdatengröße 105 * 50 bytes = 5250 bytes. Die Kontingentnutzung beläuft sich also auf max(1kB, ceil(5250 bytes/1000)) = 6kB.
Ressourcenlimits
| Ressource | Limits |
|---|---|
| Projekt |
10.000 Themen 10.000 angehängte oder getrennte Abos 5.000 Snapshots 10.000 Schemas |
| Thema |
10.000 angehängte Abos 5.000 angehängte Snapshots Ist die Aufbewahrung von Themennachrichten konfiguriert, können Nachrichten, die zu einem Thema veröffentlicht wurden, bis zu 31 Tage ab dem Zeitpunkt der Veröffentlichung im nichtflüchtigen Speicher gespeichert werden. |
| Abo |
Bewahrt nicht quittierte Nachrichten ab der Veröffentlichung standardmäßig sieben Tage lang im nichtflüchtigen Speicher auf. Es gibt kein Limit für die
Anzahl der aufbewahrten Nachrichten. Wenn Abonnenten ein Abo nicht nutzen, läuft es ab. Die standardmäßige Ablaufzeit beträgt 31 Tage. |
| Schema | Schemagröße (Feld definition): 300 KBRevisionen pro Schema: 20 |
| Veröffentlichungsanfrage |
10 MB (Gesamtgröße) 1.000 Nachrichten |
| Meldung |
Nachrichtengröße (Feld data): 10 MBAttribute pro Nachricht: 100 Attributschlüsselgröße: 256 Byte Attributwertgröße: 1.024 Byte |
| StreamingPull-Streams | 10 MB/s pro offenem Stream |
| Unäre Pull-Antwort |
Maximale Anzahl von Nachrichten in der Pull-Antwort: 1.000 Maximale Größe der Pull-Antwort: 10 MB |
| Pull-/StreamingPull-Nachrichten | Der Dienst kann Limits festlegen, die die Gesamtzahl der pro Verbindung ausstehenden StreamingPull-Nachrichten regeln. Wenn Sie ein solches Limit erreichen, sollten Sie die Rate, mit der Sie Nachrichten bestätigen, und die Anzahl der verwendeten Verbindungen erhöhen. |
| Acknowledge- und ModifyAckDeadline-Anfragen |
512 KB (Gesamtgröße) |
| Reihenfolgeschlüssel | Wenn Nachrichten Reihenfolgeschlüssel haben, beträgt der maximale Publisher-Durchsatz 1 MB/s pro Reihenfolgeschlüssel. |
| Cloud Storage-Bucket-Objekte | Wenn Sie Cloud Storage-Importthemen verwenden, beträgt das Limit für die Anzahl der Objekte in einem Bucket 50 Millionen. |
Dienstkonto für höhere Kontingente verwenden
Wenn Sie das Google Cloud CLI-Tool mit einem normalen Nutzerkonto – keinem Dienstkonto – verwenden, sind Pub/Sub-Vorgänge auf eine für manuelle Vorgänge geeignete Rate beschränkt. Raten über diesem Limit führen zum RESOURCE_EXHAUSTED. Dies können Sie durch die Verwendung von Anmeldedaten für ein Dienstkonto verhindern. Wenn Sie zur Automatisierung die Anmeldedaten der gcloud CLI verwenden möchten, ein Dienstkonto aktivieren für Ihre Pub/Sub-Vorgänge.
Standortendpunkte zum Weiterleiten von Anfragen verwenden
Wenn Sie in bestimmten Regionen zusätzliche Kontingente haben, können Sie Anfragen mithilfe von Standort-Pub/Sub-Endpunktenan diese Regionen weiterleiten. Wenn Sie Nachrichten in einem globalen Endpunkt veröffentlichen, leitet der Pub/Sub-Dienst den Traffic möglicherweise an eine Region weiter, die nicht über ausreichende Kontingente verfügt.
In Regionen, in denen Anfragen zur Kontingenterhöhung gewährt wurden, kann es vorkommen, dass Sie nicht sofort auf die gesamte gewährte Kapazität zugreifen können, wenn Sie Traffic zwischen den verschiedenen Endpunkttypen verschieben.
Kontingentabweichungen
Kontingentabweichungen können auftreten, wenn veröffentlichte oder empfangene Nachrichten kleiner als 1.000 Byte sind. Beispiel:
Wenn Sie zehn Nachrichten mit je 500 Byte in separaten Anfragen veröffentlichen, beträgt Ihre Kontingentnutzung als Publisher 10.000 Byte. Das liegt daran, dass Nachrichten unter 1.000 Byte automatisch auf 1.000 Byte aufgerundet werden.
Wenn Sie die zehn Nachrichten innerhalb einer einzelnen Pull-Antwort empfangen, beträgt Ihre Kontingentnutzung als Abonnent möglicherweise nur 5 KB. Dies liegt daran, dass für die Bestimmung des Gesamtkontingents die Nachrichten in ihrer tatsächlichen Größe zusammengefasst werden.
Auch das Gegenteil kann der Fall sein. Die Kontingentnutzung als Abonnent kann über der Kontingentnutzung als Publisher liegen, wenn Sie mehrere Nachrichten in einer einzelnen Veröffentlichungsanfrage veröffentlichen oder die Nachrichten in separaten Pull-Anfragen empfangen.