Freigeben über

Leistungstipps für Azure Cosmos DB und .NET SDK v2

  • Gilt für:: ✅ NoSQL

Azure Cosmos DB ist eine schnelle und flexible verteilte Datenbank mit nahtloser Skalierung, garantierter Latenz und garantiertem Durchsatz. Die Skalierung Ihrer Datenbank mit Azure Cosmos DB erfordert weder aufwendige Änderungen an der Architektur noch das Schreiben von komplexem Code. Das Hoch- und Herunterskalieren ist so einfach wie einen einzigen API-Aufruf zu tätigen. Weitere Informationen finden Sie unter Bereitstellen des Containerdurchsatzes oder zum Bereitstellen des Datenbankdurchsatzes. Da jedoch über Netzwerkaufrufe auf Azure Cosmos DB zugegriffen wird, gibt es clientseitige Optimierungen, die Sie vornehmen können, um spitzen Leistung zu erzielen, wenn Sie das SQL .NET SDK verwenden.

Wenn Sie also versuchen, die Datenbankleistung zu verbessern, sollten Sie die folgenden Optionen in Betracht ziehen:

Upgrade auf das .NET V3 SDK

Das .NET v3 SDK wird veröffentlicht. Wenn Sie das .NET v3 SDK verwenden, lesen Sie das .NET v3-Leistungshandbuch für die folgenden Informationen:

  • Standardeinstellungen für den Direct TCP-Modus
  • Stream-API-Unterstützung
  • Unterstützung eines benutzerdefinierten Serialisierers, um die Nutzung von System.Text.JSON zu ermöglichen.
  • Integrierte Batch- und Massenunterstützung

Hostingempfehlungen

Serverseitige Garbage Collection (GC) aktivieren

In einigen Fällen kann es hilfreich sein, die Häufigkeit zu verringern, mit der die Garbage Collection ausgeführt wird. Legen Sie gcServer in .NET auf true fest.

Erweitern Ihrer Clientworkload

Wenn Sie auf einem hohen Durchsatzniveau testen (> 50.000 RU/s), kann sich die Clientanwendung als Engpass erweisen, da der Computer die CPU- oder Netzwerkauslastung deckelt. Wenn dieser Punkt erreicht wird, können Sie das Azure Cosmos DB-Konto weiter auslasten, indem Sie Ihre Clientanwendungen auf mehrere Server horizontal hochskalieren.

Hinweis

Eine hohe CPU-Auslastung kann zu erhöhter Latenz und Ausnahmen des Typs „Anforderungstimeout“ führen.

Metadatenvorgänge

Überprüfen Sie das Vorhandensein einer Datenbank und/oder einer Sammlung nicht durch den Aufruf von Create...IfNotExistsAsync und/oder Read...Async im langsamsten Pfad und/oder vor der Durchführung eines Elementvorgangs. Die Überprüfung sollte nur beim Starten der Anwendung durchgeführt werden, wenn sie erforderlich ist, wenn Sie erwarten, dass sie gelöscht werden (andernfalls ist sie nicht erforderlich). Diese Metadatenvorgänge generieren zusätzliche End-to-End-Latenz, haben keine SLA und eigene separate Einschränkungen , die nicht skaliert werden, wie Datenvorgänge.

Protokollierung und Nachverfolgung

In einigen Umgebungen ist .NET DefaultTraceListener aktiviert. DefaultTraceListener führt in Produktionsumgebungen zu Leistungsproblemen, die eine hohe CPU-Auslastung und E/A-Engpässe bewirken. Stellen Sie sicher, dass DefaultTraceListener für Ihre Anwendung deaktiviert ist, indem Sie ihn in Produktionsumgebungen aus TraceListeners entfernen.

Die neuesten SDK-Versionen (größer als 2.16.2) entfernen sie automatisch, wenn sie sie erkennen, mit älteren Versionen können Sie sie entfernen:

if (!Debugger.IsAttached)
{
    Type defaultTrace = Type.GetType("Microsoft.Azure.Documents.DefaultTrace,Microsoft.Azure.DocumentDB.Core");
    TraceSource traceSource = (TraceSource)defaultTrace.GetProperty("TraceSource").GetValue(null);
    traceSource.Listeners.Remove("Default");
    // Add your own trace listeners
}

Vernetzung

Verbindungsrichtlinie: Verwenden des direkten Verbindungsmodus

.NET V2 SDK-Standardverbindungsmodus ist Gateway. Sie konfigurieren den Verbindungsmodus während der Erstellung der DocumentClient Instanz mithilfe des ConnectionPolicy Parameters. Wenn Sie den direkten Modus verwenden, müssen Sie den Protocol Parameter auch mithilfe des ConnectionPolicy Parameters festlegen. Weitere Informationen zu verschiedenen Konnektivitätsoptionen finden Sie im Artikel zu den Konnektivitätsmodi.

Uri serviceEndpoint = new Uri("https://contoso.documents.net");
string authKey = "your authKey from the Azure portal";
DocumentClient client = new DocumentClient(serviceEndpoint, authKey,
new ConnectionPolicy
{
   ConnectionMode = ConnectionMode.Direct, // ConnectionMode.Gateway is the default
   ConnectionProtocol = Protocol.Tcp
});

Kurzfristige Portauslastung

Wenn Sie ein hohes Verbindungsaufkommen oder eine hohe Portauslastung Ihrer Instanzen feststellen, überprüfen Sie zunächst, ob die Clientinstanzen Singletons sind. Anders ausgedrückt: Die Clientinstanzen müssen für die Lebensdauer der Anwendung eindeutig sein.

Bei der Ausführung im TCP-Protokoll optimiert der Client die Latenz, indem die langlebigen Verbindungen im Gegensatz zum HTTPS-Protokoll verwendet werden, wodurch die Verbindungen nach 2 Minuten Inaktivität beendet werden.

In Szenarien mit geringem Zugriff und wenn Sie im Vergleich zum Zugriff auf den Gatewaymodus eine höhere Verbindungsanzahl feststellen, können Sie:

  • Konfigurieren Sie die ConnectionPolicy.PortReuseMode-Eigenschaft auf PrivatePortPool (effektiv mit Framework-Version>= 4.6.1 und .NET Core Version >= 2.0): Mit dieser Eigenschaft kann das SDK einen kleinen Pool von ephemeralen Ports für verschiedene Azure Cosmos DB-Zielendpunkte verwenden.
  • Konfigurieren Sie die ConnectionPolicy.IdleConnectionTimeout-Eigenschaft, damit sie größer oder gleich 10 Minuten ist. Die empfohlenen Werte liegen zwischen 20 Minuten und 24 Stunden.

Aufrufen von OpenAsync, um die Startlatenz bei der ersten Anforderung zu vermeiden

Standardmäßig weist die erste Anforderung eine höhere Latenz auf, da sie die Adressroutingtabelle abrufen muss. Wenn Sie SDK V2 verwenden, rufen Sie einmal während der Initialisierung auf OpenAsync() , um diese Startlatenz für die erste Anforderung zu vermeiden. Der Anruf sieht wie folgt aus: await client.OpenAsync();

Hinweis

OpenAsync generiert Anforderungen zum Abrufen der Adressroutingtabelle für alle Container im Konto. Bei Konten mit vielen Containern, deren Anwendung jedoch auf eine Teilmenge von ihnen zugreift, OpenAsync würde ein unnötiger Datenverkehr generiert, was die Initialisierung verlangsamt. Daher ist die Verwendung OpenAsync in diesem Szenario möglicherweise nicht hilfreich, da der Anwendungsstart verlangsamt wird.

Für die Leistung platzieren Sie Clients in derselben Azure-Region

Platzieren Sie nach Möglichkeit sämtliche Anwendungen, die Azure Cosmos DB aufrufen, in der gleichen Region wie die Azure Cosmos DB-Datenbank. Hier ist ein ungefährer Vergleich: Aufrufe von Azure Cosmos DB innerhalb derselben Region sind innerhalb von 1 ms bis 2 ms abgeschlossen, die Latenz zwischen der West- und der Ostküste der USA beträgt jedoch mehr als 50 ms. Diese Latenz variiert ggf. von Anforderung zu Anforderung und ist abhängig von der Route, die die Anforderung zwischen dem Client und der Grenze des Azure-Rechenzentrums nimmt. Sie können die niedrigste mögliche Latenz erhalten, indem Sie sicherstellen, dass sich die aufrufende Anwendung in derselben Azure-Region befindet wie der bereitgestellte Azure Cosmos DB-Endpunkt. Eine Liste mit den verfügbaren Regionen finden Sie unter Azure-Regionen.

Die Azure Cosmos DB-Verbindungsrichtlinie

Erhöhen der Anzahl von Threads/Aufgaben

Da Aufrufe von Azure Cosmos DB über das Netzwerk getätigt werden, müssen Sie möglicherweise den Grad der Parallelität Ihrer Anforderungen variieren, damit die Clientanwendung minimale Wartezeiten zwischen Anforderungen aufwendet. Erstellen Sie beispielsweise bei Verwendung der Task Parallel Library von .NET mehrere Hundert Aufgaben für Lese- und Schreibvorgänge in Azure Cosmos DB.

Aktivieren von beschleunigten Netzwerken

Um Latenz und CPU-Jitter zu verringern, empfehlen wir, dass Sie beschleunigte Netzwerke auf virtuellen Clientcomputern aktivieren. Siehe Erstellen eines virtuellen Windows-Computers mit beschleunigtem Netzwerk oder Erstellen eines virtuellen Linux-Computers mit beschleunigtem Netzwerk.

SDK-Verwendung

Installieren des neuesten SDKs

Azure Cosmos DB-SDKs werden ständig verbessert, um eine optimale Leistung zu ermöglichen. Sehen Sie sich die Azure Cosmos DB SDK-Seiten an, um das neueste SDK zu ermitteln und Verbesserungen zu überprüfen.

Verwenden eines Singleton-Azure Cosmos DB-Clients für die Lebensdauer der Anwendung

Jede DocumentClient Instanz ist threadsicher und führt effiziente Verbindungsverwaltung und Adresszwischenspeicherung durch, wenn sie im direkten Modus ausgeführt werden. Um eine effiziente Verbindungsverwaltung und eine bessere SDK-Clientleistung zu ermöglichen, empfehlen wir, eine einzelne Instanz pro AppDomain Lebensdauer der Anwendung zu verwenden.

Vermeiden von blockierenden Aufrufen

Das Azure Cosmos DB SDK sollte so konzipiert werden, dass es viele Anforderungen gleichzeitig verarbeiten kann. Asynchrone APIs ermöglichen die parallele Verarbeitung Tausender Anforderungen in einem kleinen Pool von Threads, indem nicht auf blockierende Aufrufe gewartet wird. Anstatt darauf zu warten, dass eine synchrone Aufgabe mit langer Laufzeit abgeschlossen wird, kann der Thread eine andere Anforderung bearbeiten.

Ein häufiges Leistungsproblem in Apps, die das Azure Cosmos DB SDK verwenden, sind blockierende Aufrufe, die asynchron sein könnten. Viele synchrone blockierende Aufrufe führen zu einem Threadmangel im Pool und zu längeren Antwortzeiten.

Vermeiden Sie Folgendes:

  • Blockieren der asynchronen Ausführung durch Aufrufen von Task.Wait oder Task.Result.
  • Verwenden von Task.Run, um eine synchrone API als asynchron festzulegen.
  • Abrufen von Sperren in allgemeinen Codepfaden. Das Azure Cosmos DB .NET SDK liefert die beste Leistung, wenn der Code parallel ausgeführt wird.
  • Aufrufen von Task.Run und sofortiges Warten darauf. ASP.NET Core führt bereits App-Code in normalen Threadpoolthreads aus, sodass das Aufrufen von Task.Run nur zu einer zusätzlichen unnötigen Threadpoolplanung führt. Auch wenn der geplante Code einen Thread blockieren würde, verhindert Task.Run dies nicht.
  • Verwenden Sie „ToList()“ für DocumentClient.CreateDocumentQuery(...). Es nutzt blockierende Aufrufe, um die Abfrage synchron zu entladen. Verwenden Sie AsDocumentQuery(), um die Abfrage asynchron zu verarbeiten.

Empfohlene Vorgehensweise:

  • Rufen Sie die .NET-APIs von Azure Cosmos DB asynchron auf.
  • Die gesamte Aufrufliste ist asynchron, um von async/await-Mustern zu profitieren.

Über einen Profiler wie z. B. PerfView können Threads ermittelt werden, die dem Threadpool häufig hinzugefügt werden. Das Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start-Ereignis gibt einen Thread an, der dem Threadpool hinzugefügt wurde.

Erhöhen System.Net MaxConnections pro Host bei Verwendung des Gatewaymodus

Azure Cosmos DB-Anforderungen werden über HTTPS/REST gestellt, wenn Sie den Gatewaymodus verwenden. Sie unterliegen dem Standardverbindungsgrenzwert pro Hostname oder IP-Adresse. Möglicherweise müssen Sie einen höheren Wert (100 bis 1.000) festlegen MaxConnections , damit die Clientbibliothek mehrere gleichzeitige Verbindungen mit Azure Cosmos DB verwenden kann. In .NET SDK 1.8.0 und höher ist der Standardwert für ServicePointManager.DefaultConnectionLimit „50“. Um den Wert zu ändern, können Sie "Documents.Client.ConnectionPolicy.MaxConnectionLimit " auf einen höheren Wert festlegen.

Backoff bei RetryAfter-Intervallen implementieren

Während des Leistungstests sollten Sie die Last erhöhen, bis ein kleiner Teil der Anfragen gedrosselt wird. Wenn die Anforderungen gedrosselt werden, sollte die Clientanwendung diese Drosselung für das vom Server angegebene Wiederholungsintervall aussetzen. Durch das Aussetzen wird die geringstmögliche Wartezeit zwischen den Wiederholungsversuchen gewährleistet.

Die folgenden SDKs bieten Unterstützung für Wiederholungsrichtlinien:

Weitere Informationen finden Sie unter "RetryAfter".

In Version 1.19 und höher des .NET SDK gibt es einen Mechanismus zum Protokollieren zusätzlicher Diagnoseinformationen und zur Problembehandlung von Latenzproblemen, wie im folgenden Beispiel gezeigt. Sie können die Diagnosezeichenfolge für Anforderungen protokollieren, die eine höhere Leselatenz aufweisen. Die erfasste Diagnosezeichenfolge hilft Ihnen zu verstehen, wie oft Sie 429 Fehler für eine bestimmte Anforderung erhalten haben.

ResourceResponse<Document> readDocument = await this.readClient.ReadDocumentAsync(oldDocuments[i].SelfLink);
readDocument.RequestDiagnosticsString

Cachedokument-URIs für niedrigere Leselatenz

Zur Erzielung einer optimalen Leseleistung sollten Dokument-URIs möglichst immer zwischengespeichert werden. Sie müssen die Logik definieren, um die Ressourcen-ID zwischenzuspeichern, wenn Sie eine Ressource erstellen. Nachschlagevorgänge, die auf Ressourcen-IDs basieren, sind schneller als namensbasierte Nachschlagevorgänge, sodass das Zwischenspeichern dieser Werte die Leistung verbessert.

Erhöhen der Anzahl von Threads/Aufgaben

Weitere Informationen finden Sie unter "Erhöhen der Anzahl von Threads/Aufgaben " im Abschnitt "Netzwerk" dieses Artikels.

Abfragevorgänge

Informationen zu Abfragevorgängen finden Sie in den Leistungstipps für Abfragen.

Indizierungsrichtlinie

Beschleunigen von Schreibvorgängen durch Ausschließen nicht verwendeter Pfade von der Indizierung

Mit der Azure Cosmos DB-Indizierungsrichtlinie können Sie auch angeben, welche Dokumentpfade in die Indizierung aufgenommen oder von der Indizierung ausgeschlossen werden sollen, indem Sie Indizierungspfade (IndexingPolicy.IncludedPaths und IndexingPolicy.ExcludedPaths) verwenden. Indizierungspfade können die Schreibleistung verbessern und den Indexspeicher für Szenarien reduzieren, in denen die Abfragemuster vorher bekannt sind. Dies liegt daran, dass der Indizierungsaufwand direkt mit der Anzahl der indizierten eindeutigen Pfade zusammenhängt. In diesem Code wird beispielsweise gezeigt, wie ein vollständiger Abschnitt der Dokumente (einer Unterstruktur) aus der Indizierung mithilfe des "*"-Wildcards ausgeschlossen wird:

var collection = new DocumentCollection { Id = "excludedPathCollection" };
collection.IndexingPolicy.IncludedPaths.Add(new IncludedPath { Path = "/*" });
collection.IndexingPolicy.ExcludedPaths.Add(new ExcludedPath { Path = "/nonIndexedContent/*");
collection = await client.CreateDocumentCollectionAsync(UriFactory.CreateDatabaseUri("db"), collection);

Weitere Informationen finden Sie unter Indizierungsrichtlinien für Azure Cosmos DB.

Durchsatz

Messen und Optimieren für einen geringeren Bedarf an Anforderungseinheiten pro Sekunde

Azure Cosmos DB bietet einen umfangreichen Satz von Datenbankvorgängen. Zu diesen Vorgängen gehören relationale und hierarchische Abfragen mit UDFs, gespeicherten Prozeduren und Triggern, die alle in den Dokumenten in einer Datenbanksammlung ausgeführt werden. Die Kosten für jeden dieser Vorgänge variieren je nach CPU, E/A und Arbeitsspeicher, die zum Abschließen des Vorgangs erforderlich sind. Anstatt Hardwareressourcen zu berücksichtigen und zu verwalten, können Sie sich eine Anforderungseinheit (RU) als einzelne Maßnahme für die Ressourcen vorstellen, die zum Ausführen verschiedener Datenbankvorgänge und des Diensts einer Anwendungsanforderung erforderlich sind.

Der Durchsatz wird basierend auf der für jeden Container festgelegten Anzahl von Anforderungseinheiten bereitgestellt. Der Anforderungseinheitsverbrauch wird als Rate pro Sekunde ausgewertet. Anwendungen, die die bereitgestellte Anforderungseinheitsrate für ihren Container überschreiten, sind begrenzt, bis die Rate unter die bereitgestellte Ebene für den Container fällt. Wenn Ihre Anwendung einen höheren Durchsatz erfordert, können Sie den Durchsatz erhöhen, indem Sie zusätzliche Anforderungseinheiten bereitstellen.

Die Komplexität einer Abfrage wirkt sich auf die Anzahl der Anforderungseinheiten aus, die für einen Vorgang verbraucht werden. Die Anzahl der Prädikate, die Art der Prädikate, die Anzahl der UDFs und die Größe des Quelldatensatzes beeinflussen alle die Kosten von Abfragevorgängen.

Um den Aufwand eines Vorgangs (Erstellen, Aktualisieren oder Löschen) zu messen, prüfen Sie den x-ms-request-charge-Header (oder die entsprechende RequestCharge Eigenschaft im ResourceResponse\<T>FeedResponse\<T> .NET SDK), um die Anzahl der von den Vorgängen verbrauchten Anforderungseinheiten zu messen:

// Measure the performance (Request Units) of writes
ResourceResponse<Document> response = await client.CreateDocumentAsync(collectionSelfLink, myDocument);
Console.WriteLine("Insert of document consumed {0} request units", response.RequestCharge);
// Measure the performance (Request Units) of queries
IDocumentQuery<dynamic> queryable = client.CreateDocumentQuery(collectionSelfLink, queryString).AsDocumentQuery();
while (queryable.HasMoreResults)
    {
        FeedResponse<dynamic> queryResponse = await queryable.ExecuteNextAsync<dynamic>();
        Console.WriteLine("Query batch consumed {0} request units", queryResponse.RequestCharge);
    }

Die in diesem Header zurückgegebene Anforderungsgebühr ist ein Bruchteil des bereitgestellten Durchsatzes (d. h. 2.000 RUs / Sekunde). Falls die obige Abfrage also beispielsweise 1.000 Dokumente mit einer Größe von 1 KB zurückgibt, fallen für den Vorgang Kosten in Höhe von 1.000 an. Somit werden vom Server innerhalb einer Sekunde nur zwei solcher Anforderungen berücksichtigt, und für weitere Anforderungen wird die Rate begrenzt. Weitere Informationen finden Sie unter Anforderungseinheiten sowie unter dem Rechner für Anforderungseinheiten.

Behandeln von Ratenbeschränkungen/zu hohen Anforderungsraten

Wenn ein Client versucht, den für ein Konto reservierten Durchsatz zu überschreiten, wird die Serverleistung nicht beeinträchtigt, und es wird kein über die reservierte Kapazität hinausgehender Durchsatz in Anspruch genommen. Der Server beendet die Anforderung vorab mit RequestRateTooLarge (HTTP-Statuscode 429). Es wird ein x-ms-retry-after-ms Header zurückgegeben, der die Zeitspanne in Millisekunden angibt, die der Benutzer warten muss, ehe er die Anforderung erneut versuchen kann.

HTTP Status 429,
Status Line: RequestRateTooLarge
x-ms-retry-after-ms :100

Alle SDKs fangen diese Antwort implizit ab, berücksichtigen den vom Server angegebenen Header vom Typ „retry-after“ und wiederholen die Anforderung. Wenn nicht mehrere Clients gleichzeitig auf Ihr Konto zugreifen, wird die nächste Wiederholung erfolgreich ausgeführt.

Wenn mehr als ein Client kumulativ und konstant über der Anforderungsrate betrieben wird, reicht die standardmäßige Wiederholungsanzahl, die derzeit vom Client intern auf 9 festgelegt ist, möglicherweise nicht aus. In diesem Fall löst der Client eine DocumentClientException mit Statuscode 429 an die Anwendung aus.

Sie können die Standardanzahl von Wiederholungsversuchen ändern, indem Sie die RetryOptions für die ConnectionPolicy-Instanz festlegen. Standardmäßig wird die DocumentClientException mit Dem Statuscode 429 nach einer kumulierten Wartezeit von 30 Sekunden zurückgegeben, wenn die Anforderung weiterhin über der Anforderungsrate ausgeführt wird. Dieser Fehler tritt auf, selbst wenn die aktuelle Wiederholungsanzahl kleiner als die maximale Wiederholungsanzahl ist, unabhängig davon, ob der aktuelle Wert der Standardwert 9 oder ein userdefinierter Wert ist.

Das automatisierte Wiederholungsverhalten trägt dazu bei, die Resilienz und Benutzerfreundlichkeit für die meisten Anwendungen zu verbessern. Dies stellt jedoch möglicherweise nicht das beste Verhalten dar, wenn Sie Leistungsbenchmarks durchführen, und insbesondere nicht beim Messen der Latenz. Die Wartezeit für den Client nimmt stark zu, wenn das Experiment die Serverdrosselung erreicht und damit die automatische Wiederholung durch das Client-SDK auslöst. Ermitteln Sie zur Vermeidung von Latenzspitzenwerten bei Leistungsexperimenten die von den einzelnen Vorgängen zurückgegebene Belastung, und stellen Sie sicher, dass die Anforderungen die reservierte Anforderungsrate nicht überschreiten. Weitere Informationen finden Sie unter Anforderungseinheiten.

Verwenden eines auf kleinere Dokumente ausgerichteten Designs für einen höheren Durchsatz

Die Anforderungsgebühr (d. h. die Kosten für die Anforderungsverarbeitung) eines bestimmten Vorgangs korreliert direkt mit der Größe des Dokuments. Vorgänge für große Dokumente sind teurer als Vorgänge für kleine Dokumente.

Nächste Schritte

Eine Beispielanwendung, die zum Auswerten von Azure Cosmos DB für Hochleistungsszenarien auf einigen Clientcomputern verwendet wird, finden Sie unter Performance- und Skalierungstests mit Azure Cosmos DB.

Weitere Informationen zum Entwerfen einer auf Skalierung und hohe Leistung ausgelegten Anwendung finden Sie unter Partitionieren und Skalieren in Azure Cosmos DB.

  • Last updated on