Azure vertraulichen Sachgrenzen

Azure vertraulichen Sachkonten beschränkt die Anzahl der Hauptbücher in einem Abonnement und die Daten und den Code, die ein Ledger speichert, um die Leistung und Verfügbarkeit jedes Sachbuchs vorhersehbar zu halten. In diesem Artikel werden diese Grenzwerte beschrieben, wie das Hauptbuch reagiert, wenn eine Anforderung sie überschreitet und welche Leistung von einem Ledger erwartet wird.

Note

Die Grenzwerte in diesem Artikel sind Standardwerte. In bestimmten Fällen kann ein einzelnes Sachbuch unterschiedliche Grenzen haben, z. B. ein Sachbuch, das vor der Einführung eines Grenzwerts erstellt wurde. Wenn Sie höhere Grenzwerte anfordern oder Einschränkungen besprechen möchten, wenden Sie sich an Azure-Support.

Grenzwerte für Abonnements

Der folgende Grenzwert gilt für jedes Azure-Abonnement.

Limit Wert
Ledger pro Abonnement 2

Ledger-Datenbeschränkungen

Die folgenden Grenzwerte gelten standardmäßig für jedes Hauptbuch.

Limit Standardwert Fehlercode
Sammlungen pro Hauptbuch 5.000 CollectionCapacityExceeded
Länge der Sammlungs-ID 256 Bytes CollectionIdTooLong
Größe des Inhalts eines Sachbucheintrags 8 KiB (8.192 Bytes) EntrySizeCapacityExceeded
Tags pro Ledger (nur öffentliche Sachbücher) 10.000 TagCapacityExceeded
  • Sammlungen pro Hauptbuch: Die Standardauflistung wird nicht gezählt. Wenn ein Hauptbuch den Grenzwert erreicht, werden Schreibvorgänge, die eine neue Sammlung erstellen würden, abgelehnt. Schreibvorgänge in vorhandene Auflistungen sind weiterhin erfolgreich.
  • Länge der Sammlungs-ID: Die Länge wird in Bytes der UTF-8-codierten ID nach der URL-Decodierung gemessen. Der Grenzwert gilt nur, wenn ein Schreibvorgang eine neue Auflistung erstellt, sodass Sie vor der Einführung dieses Grenzwerts weiterhin schreiben und aus Sammlungen lesen können, die erstellt wurden.
  • Größe des Inhalts eines Ledgereintrags: Die Größe wird nach der JSON-Decodierung in Bytes des UTF-8-codierten contents Werts gemessen. Der Inhalt von genau 8.192 Bytes wird akzeptiert. Der Grenzwert gilt für Schreibvorgänge sowohl für neue als auch für vorhandene Auflistungen. Die Sammlungs-ID, Tags und andere Felder der Anforderung zählen nicht zu diesem Grenzwert. Die gesamte Anforderung unterliegt auch der maximalen Anforderungstextgröße des Sachbuchs.
  • Tags pro Ledger: Ein Tag zählt einmal für jede Sammlung, die sie verwendet. Beispielsweise zählt das in zwei Auflistungen verwendete Tag chocolate als zwei Tags. Wenn ein Hauptbuch den Grenzwert erreicht, werden Schreibvorgänge, die einer Sammlung ein neues Tag hinzufügen würden, abgelehnt. Schreibvorgänge ohne Tags oder mit Tags, die von der Auflistung bereits verwendet werden, sind weiterhin erfolgreich.

Ein Schreibvorgang, der einen Grenzwert überschreitet, wird mit DEM HTTP-Statuscode 400 (Ungültige Anforderung) abgelehnt, und nichts in der Anforderung wird in das Hauptbuch geschrieben. Die Antwort enthält den Fehlercode und eine Meldung, die den Grenzwert enthält, der für das Hauptbuch gilt. Beispiele:

{
  "error": {
    "code": "EntrySizeCapacityExceeded",
    "message": "Entry contents of 9000 bytes exceed the limit of 8192 bytes."
  }
}

Tagbeschränkungen pro Schreibzugriff

Tags werden nur in öffentlichen Hauptbüchern unterstützt. Die folgenden Grenzwerte gelten für jedes öffentliche Hauptbuch.

Limit Wert
Tags pro Schreibzugriff 5
Taglänge 63 Zeichen

Tags dürfen nicht leer sein und dürfen nur die Zeichen A–Z, –z, a–9, 0, _-, , .und .~ Ein Schreibzugriff, der diese Grenzwerte überschreitet oder ein ungültiges Tag enthält, wird mit DEM HTTP-Statuscode 400 und dem NotAllowed Fehlercode abgelehnt.

Benutzerdefinierte Funktionsbeschränkungen

Die folgenden Grenzwerte gelten für benutzerdefinierte Funktionen (UDFs) in jedem Ledger. Anforderungen, die sie überschreiten, werden mit HTTP-Statuscode 400 abgelehnt.

Limit Wert Fehlercode
UDFs pro Ledger 100 UserDefinedFunctionCapacityExceeded
Länge der UDF-ID 256 Bytes InvalidFunctionId
UDF-Codegröße 64 KiB (65.536 Bytes) InvalidInput
Vorhaken pro Schreibzugriff 5 InvalidInput
Post-Hooks pro Schreibzugriff 5 InvalidInput

Die UDF-Zählungs- und ID-Längenbeschränkungen gelten nur, wenn Sie eine UDF erstellen. Sie können weiterhin eine vorhandene UDF aktualisieren, wenn ihr Code in 64 KiB passt.

Die Laufzeitoptionen, die beim Ausführen einer UDF gelten, finden Sie unter Ausführen von UDFs. Weitere Informationen zu Pre-Hooks und Post-Hooks finden Sie unter Transaktions-Hooks.

Benutzerdefinierte Endpunktlaufzeitoptionen

Werte, die festgelegt PATCH /app/userDefinedEndpoints/runtimeOptions sind, müssen innerhalb der folgenden Bereiche liegen. Andernfalls wird die Anforderung mit dem HTTP-Statuscode 400 und dem InvalidInput Fehlercode abgelehnt. Nur die Optionen, deren Wert die Anforderung ändert, werden überprüft.

Laufzeitoption Zulässige Werte
max_heap_bytes Bis zu 209.715.200 (200 MiB)
max_stack_bytes 1 bis 10.485.760 (10 MiB)
max_execution_time_ms Bis zu 10.000 (10 Sekunden)
max_cached_interpreters 1 bis 20

Performance

Die Leistung eines Ledgers hängt von Ihrer Arbeitsauslastung ab, z. B. von der Größe Ihrer Einträge, der Anzahl der Anforderungen, die Sie gleichzeitig senden, und der Mischung aus Lese- und Schreibvorgängen. Die folgenden Anleitungen geben eine allgemeine Vorstellung davon, was Sie erwarten müssen. Es ist keine Garantie.

Throughput

  • Ein Ledger kann Hunderte von Schreibvorgängen pro Sekunde erhalten. Kleinere Einträge und mehr gleichzeitige Anforderungen erhöhen die Rate. Schreibvorgänge, die benutzerdefinierte Funktionen ausführen, dauern je nach Code der Funktionen länger.
  • Beim Lesen des neuesten Eintrags einer Sammlung werden weniger Ressourcen als ein Schreibvorgang verwendet, sodass ein Hauptbuch in der Regel mehr dieser Anforderungen erfüllen kann. Das Abrufen eines Eintrags nach Transaktions-ID, Abrufen einer Bestätigung und Bereichsabfragen verwenden mehr Ressourcen als das Lesen des neuesten Eintrags, da das Hauptbuch die Daten zuerst aus dem Speicher lädt. Eine hohe Rate dieser Anforderungen reduziert den Durchsatz für Schreibvorgänge.
  • Ein Kunde, der auf jede Antwort wartet, bevor er die nächste Anforderung sendet, ist durch seine Roundtripzeit an das Hauptbuch begrenzt. Um ein Hauptbuch optimal nutzen zu können, senden Sie Anforderungen gleichzeitig und wiederverwenden Sie Verbindungen.

Wenn Ihre Workload einen dauerhaften hohen Durchsatz benötigt, testen Sie sie auf einem Hauptbuch, bevor Sie zur Produktion wechseln. Wenn Sie mehr Durchsatz benötigen, wenden Sie sich an Azure-Support.

Latenz

  • Standardmäßig wird eine Schreibanforderung zurückgegeben, sobald das Hauptbuch den Schreibvorgang akzeptiert, und das Hauptbuch setzt den Schreibvorgang kurz danach fest. Bevor Sie sich auf einen Schreibvorgang verlassen, z. B. um den Beleg zu erhalten, überprüfen Sie, ob der Status lautet Committed. Die Clientbibliotheken können auf den Commit für Sie warten.
  • Das Abrufen eines Eintrags nach Transaktions-ID, Abrufen einer Bestätigung und Bereichsabfragen kann zuerst zurückgegeben Loading werden, während das Hauptbuch die Daten lädt. Wiederholen Sie die Anforderung innerhalb einer Minute, bis sie das Ergebnis zurückgibt.
  • Die Latenz hängt auch von Entfernung und Last ab. Jede neue Verbindung benötigt einen TLS-Handshake mit dem Hauptbuch, sodass Verbindungen wiederverwendet und Ihre Kunden in der Nähe der Region des Ledgers ausgeführt werden. Erwarten Sie, dass die Latenz steigt, wenn die Last eines Hauptbuchs zunimmt, was sie erhalten kann.

Verwandte Inhalte

  • Zuletzt aktualisiert um