Tips voor betere prestaties van Azure Cosmos DB en .NET

VAN TOEPASSING OP: NoSQL

Azure Cosmos DB is een snelle, flexibele gedistribueerde database die naadloos kan worden geschaald met gegarandeerde latentie- en doorvoerniveaus. U hoeft geen belangrijke architectuurwijzigingen aan te brengen of complexe code te schrijven om uw database te schalen met Azure Cosmos DB. Omhoog en omlaag schalen is net zo eenvoudig als het maken van één API-aanroep. Zie containerdoorvoer inrichten of databasedoorvoer inrichten voor meer informatie.

Omdat Azure Cosmos DB toegankelijk is via netwerkaanroepen, kunt u optimalisaties aan de clientzijde uitvoeren om piekprestaties te bereiken wanneer u de SQL .NET SDK gebruikt.

Als u de prestaties van uw database wilt verbeteren, kunt u de opties in de volgende secties overwegen.

Aanbevelingen voor hosting

Garbagecollection aan serverzijde inschakelen

Het verminderen van de frequentie van garbagecollection kan in sommige gevallen helpen. In .NET, stel gcServer in op true.

Uw clientworkload uitschalen

Als u test op hoge doorvoerniveaus of met een snelheid die groter is dan 50.000 aanvraageenheden per seconde (RU/s), kan de clienttoepassing een knelpunt voor de werkbelasting worden omdat de computer mogelijk een limiet voor CPU- of netwerkgebruik heeft. Als u dit punt bereikt, kunt u het Azure Cosmos DB-account verder pushen door uw clienttoepassingen uit te schalen op meerdere servers.

Metagegevensbewerkingen

Controleer niet of een database of container bestaat door Create...IfNotExistsAsync of Read...Async aan te roepen in de hot path of voordat u een itembewerking uitvoert. De validatie moet alleen worden uitgevoerd bij het opstarten van de toepassing wanneer dit nodig is, als u verwacht dat ze worden verwijderd (anders is deze niet nodig). Deze metagegevensbewerkingen genereren extra end-to-end latentie, hebben geen SLA en hebben hun eigen afzonderlijke beperkingen die niet worden geschaald, zoals gegevensbewerkingen.

Logboekregistratie en tracering

Voor sommige omgevingen is . NET DefaultTraceListener ingeschakeld. De DefaultTraceListener veroorzaakt prestatieproblemen in productieomgevingen die een hoog CPU- en I/O-knelpunt veroorzaken. Controleer en zorg ervoor dat defaultTraceListener is uitgeschakeld voor uw toepassing door deze uit de TraceListeners in productieomgevingen te verwijderen.

SDK-versies hoger dan 3.23.0 verwijderen deze automatisch zodra ze gedetecteerd worden. Met oudere versies kunt u deze verwijderen met behulp van de volgende opdrachten:

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

<configuration>
  <system.diagnostics>
    <sources>
      <source name="DocDBTrace" switchName="SourceSwitch" switchType="System.Diagnostics.SourceSwitch" >
        <listeners>
          <remove name="Default" />
          <!--Add your own trace listeners-->
          <add name="myListener" ... />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
<configuration>

Hoge beschikbaarheid

Zie Hoge beschikbaarheid in Azure Cosmos DB voor algemene richtlijnen voor het configureren van hoge beschikbaarheid in Azure Cosmos DB.

Naast een goede basisinstallatie in het databaseplatform zijn er specifieke technieken die kunnen worden geïmplementeerd in de .NET SDK zelf, wat kan helpen bij storingsscenario's. Twee belangrijke strategieën zijn de beschikbaarheidsstrategie op basis van drempelwaarden en de circuitonderbreker op partitieniveau.

Beschikbaarheidsstrategie op basis van drempelwaarden

De strategie voor beschikbaarheid op basis van drempelwaarden kan de latentie en beschikbaarheid verbeteren door parallelle leesaanvragen te verzenden naar secundaire regio's (zoals gedefinieerd in ApplicationPreferredRegions) en het snelste antwoord te accepteren. Deze aanpak kan het effect van regionale storingen of omstandigheden met hoge latentie op de prestaties van toepassingen drastisch verminderen.

voorbeeldconfiguratie:

U kunt dit configureren met behulp van CosmosClientBuilder:

CosmosClient client = new CosmosClientBuilder("connection string")
    .WithApplicationPreferredRegions(
        new List<string> { "East US", "East US 2", "West US" } )
    .WithAvailabilityStrategy(
        AvailabilityStrategy.CrossRegionHedgingStrategy(
        threshold: TimeSpan.FromMilliseconds(500),
        thresholdStep: TimeSpan.FromMilliseconds(100)
     ))
    .Build();

Of door opties te configureren en toe te voegen aan CosmosClient:

CosmosClientOptions options = new CosmosClientOptions()
{
    AvailabilityStrategy
     = AvailabilityStrategy.CrossRegionHedgingStrategy(
        threshold: TimeSpan.FromMilliseconds(500),
        thresholdStep: TimeSpan.FromMilliseconds(100)
     )
      ApplicationPreferredRegions = new List<string>() { "East US", "East US 2", "West US"},
};

CosmosClient client = new CosmosClient(
    accountEndpoint: "account endpoint",
    authKeyOrResourceToken: "auth key or resource token",
    clientOptions: options);

Hoe werkt het:

1. Eerste aanvraag: Op het moment T1 wordt een leesaanvraag ingediend bij de primaire regio (bijvoorbeeld VS - oost). De SDK wacht op een antwoord van maximaal 500 milliseconden (de threshold waarde).

2. Tweede aanvraag: Als er geen reactie van de primaire regio binnen 500 milliseconden is, wordt een parallelle aanvraag verzonden naar de volgende voorkeursregio (bijvoorbeeld VS - oost 2).

3. Derde aanvraag: Als de primaire of secundaire regio niet binnen 600 milliseconden reageert (500 ms + 100 ms, de thresholdStep waarde), verzendt de SDK een andere parallelle aanvraag naar de derde voorkeursregio (bijvoorbeeld VS - west).

4. Snelste reactie wint: Welke regio het eerst reageert, dat antwoord wordt geaccepteerd en de andere parallelle aanvragen worden genegeerd.

Circuitonderbreker op partitieniveau

De circuitonderbreker op partitieniveau (PPCB) is een functie in de .NET SDK die de beschikbaarheid en latentie verbetert door beschadigde fysieke partities bij te houden. Wanneer deze optie is ingeschakeld, helpt het aanvragen naar gezondere regio's te routeren, waardoor trapsgewijze fouten worden voorkomen vanwege regionale of partitiespecifieke problemen. De functie is onafhankelijk van door back-end geactiveerde failover en wordt beheerd via omgevingsvariabelen.

Deze functie is standaard uitgeschakeld, maar wordt automatisch ingeschakeld wanneer failover op partitieniveau is ingeschakeld.

Hoe het werkt

1. Foutdetectie: Wanneer specifieke fouten zoals 503 Service Unavailable, 408 Request Timeoutof annuleringstokens worden waargenomen, telt de SDK opeenvolgende fouten voor een partitie.
2. Failover activeren: Zodra een geconfigureerde drempelwaarde voor opeenvolgende fouten is bereikt, stuurt de SDK aanvragen voor dat partitiesleutelbereik om naar de volgende voorkeursregio met behulp van GlobalPartitionEndpointManagerCore.TryMarkEndpointUnavailableForPartitionKeyRange.
3. Herstel op de achtergrond: Een achtergrondtaak wordt gestart tijdens een failover om de status van de mislukte partitie periodiek opnieuw te evalueeren door verbinding te maken met alle vier de replica's. Zodra de status hersteld is, verwijdert de SDK de override en keert terug naar de primaire regio.

Gedrag per accounttype

• Schrijven in één regio (één master): Alleen leesaanvragen nemen deel aan de PPCB-failoverlogica.
• Schrijven in meerdere regio's (meerdere masters): Zowel lees- als schrijfaanvragen maken gebruik van PPCB-failoverlogica.

Configuratieopties

Gebruik de volgende omgevingsvariabelen om PPCB te configureren:

Beschikbaarheidsoptimalisaties vergelijken

• Beschikbaarheidsstrategie op basis van drempelwaarden:

  • Voordeel: vermindert de staartlatentie door parallelle leesaanvragen naar secundaire regio's te verzenden en verbetert de beschikbaarheid door aanvragen te verminderen die leiden tot netwerktime-outs.
  • Trade-off: Er worden extra kosten in rekening gebracht voor aanvraageenheden (RU's) in vergelijking met de circuitonderbreker, vanwege extra parallelle aanvragen tussen regio's (hoewel alleen tijdens perioden waarin drempelwaarden worden overschreden).
  • Use case: Optimaal voor leesintensieve workloads waarbij het verminderen van de latentie kritiek is en een aantal extra kosten (zowel qua RU-kosten als cpu-druk van de client) acceptabel is. Schrijfbewerkingen kunnen ook voordeel hebben als u bent aangemeld voor beleid voor niet-idempotente schrijfbewerkingen en het account schrijfbewerkingen voor meerdere regio's heeft.

• Circuitonderbreker op partitieniveau:

  • Voordeel: verbetert de beschikbaarheid en latentie door beschadigde partities te voorkomen, zodat aanvragen worden doorgestuurd naar gezondere regio's.
  • Trade-off: Er worden geen extra RU-kosten in rekening gebracht, maar er kan nog steeds enig verlies van initiële beschikbaarheid optreden voor aanvragen die tot netwerktime-outs leiden.
  • Use case: Ideaal voor schrijfintensieve of gemengde workloads waarbij consistente prestaties essentieel zijn, vooral bij partities die af en toe ongezond kunnen worden.

Beide strategieën kunnen samen worden gebruikt om de beschikbaarheid van lees- en schrijfbewerkingen te verbeteren en de latentie van de staart te verminderen. Circuitonderbreker op partitieniveau kan verschillende tijdelijke foutscenario's verwerken, waaronder scenario's die kunnen leiden tot trage uitvoering van replica's, zonder parallelle aanvragen uit te voeren. Bovendien vermindert het toevoegen van een beschikbaarheidsstrategie op basis van drempelwaarden de tail-latentie verder en elimineert het beschikbaarheidsverlies, als extra RU-kosten acceptabel zijn.

Door deze strategieën te implementeren, kunnen ontwikkelaars ervoor zorgen dat hun toepassingen tolerant blijven, hoge prestaties behouden en een betere gebruikerservaring bieden, zelfs tijdens regionale storingen of omstandigheden met hoge latentie.

Uitgesloten regio's

Met de functie uitgesloten regio's kunt u nauwkeurig controle krijgen over aanvraagroutering door specifieke regio's uit te sluiten van uw voorkeurslocaties per aanvraag. Deze functie is beschikbaar in Azure Cosmos DB .NET SDK versie 3.37.0 en hoger.

Belangrijkste voordelen:

• Snelheidsbeperking verwerken: wanneer er 429 (Te veel aanvragen) antwoorden optreden, worden aanvragen automatisch doorgestuurd naar alternatieve regio's met beschikbare doorvoer
• Gerichte routering: Zorg ervoor dat aanvragen worden verwerkt vanuit specifieke regio's door alle andere regio's uit te sluiten
• Voorkeursvolgorde overslaan: de standaardlijst met voorkeursregio's voor afzonderlijke aanvragen overschrijven zonder afzonderlijke clients te maken

Configuration:

Uitgesloten regio's kunnen worden geconfigureerd op aanvraagniveau met behulp van de ExcludeRegions eigenschap:

CosmosClientOptions clientOptions = new CosmosClientOptions()
{
    ApplicationPreferredRegions = new List<string> {"West US", "Central US", "East US"}
};

CosmosClient client = new CosmosClient(connectionString, clientOptions);

Database db = client.GetDatabase("myDb");
Container container = db.GetContainer("myContainer");

//Request will be served out of the West US region
await container.ReadItemAsync<dynamic>("item", new PartitionKey("pk"));

//By using ExcludeRegions, we are able to bypass the ApplicationPreferredRegions list
// and route a request directly to the East US region
await container.ReadItemAsync<dynamic>(
  "item", 
  new PartitionKey("pk"),
  new ItemRequestOptions()
  {
    ExcludeRegions = new List<string>() { "West US", "Central US" }
  });

Voorbeeld van use-case: snelheidsbeperking verwerken:

ItemResponse<CosmosItem> item;
item = await container.ReadItemAsync<CosmosItem>("id", partitionKey);

if (item.StatusCode == HttpStatusCode.TooManyRequests)
{
    ItemRequestOptions requestOptions = new ItemRequestOptions()
    {
        ExcludeRegions = new List<string>() { "East US" }
    };

    item = await container.ReadItemAsync<CosmosItem>("id", partitionKey, requestOptions);
}

De functie werkt ook met query's en andere bewerkingen:

QueryRequestOptions queryRequestOptions = new QueryRequestOptions()
{
    ExcludeRegions = new List<string>() { "East US" }
};

using (FeedIterator<CosmosItem> queryFeedIterator = container.GetItemQueryIterator<CosmosItem>(
    queryDefinition, 
    requestOptions: queryRequestOptions))
{
    while(queryFeedIterator.HasMoreResults)
    {
        var item = await queryFeedIterator.ReadNextAsync();
    }
}

Consistentie afstemmen versus beschikbaarheid

De functie uitgesloten regio's biedt een extra mechanisme voor het verdelen van consistentie en beschikbaarheid in uw toepassing. Deze mogelijkheid is met name waardevol in dynamische scenario's waarbij de vereisten kunnen veranderen op basis van operationele omstandigheden:

Dynamische verwerking van storingen: Wanneer een primaire regio te maken krijgt met een storing en de drempelwaarden voor circuitonderbrekers op partitieniveau ontoereikend zijn, maken uitgesloten regio's onmiddellijke failover mogelijk zonder codewijzigingen of het herstarten van toepassingen. Dit biedt een snellere reactie op regionale problemen vergeleken met wachten op automatische activering van circuitonderbrekers.

Voorkeuren voor voorwaardelijke consistentie: toepassingen kunnen verschillende consistentiestrategieën implementeren op basis van de operationele status:

• Stabiele status: prioriteit geven aan consistente leesbewerkingen door alle regio's behalve de primaire regio's uit te sluiten, waardoor gegevensconsistentie wordt gegarandeerd tegen de mogelijke beschikbaarheidskosten
• Storingsscenario's: voorkeur geven aan beschikbaarheid boven strikte consistentie door routering tussen regio's mogelijk te maken, mogelijke gegevensvertraging te accepteren in ruil voor continue beschikbaarheid van services

Met deze aanpak kunnen externe mechanismen (zoals traffic managers of load balancers) failoverbeslissingen organiseren terwijl de toepassing controle houdt over consistentievereisten via uitsluitingspatronen voor regio's.

Wanneer alle regio's worden uitgesloten, worden aanvragen doorgestuurd naar de primaire/hubregio. Deze functie werkt met alle aanvraagtypen, waaronder query's, en is met name handig voor het onderhouden van singleton-clientexemplaren en het bereiken van flexibel routeringsgedrag.

Netwerken

Verbindingsbeleid: de modus Directe verbinding gebruiken

De standaardverbindingsmodus van .NET V3 SDK is rechtstreeks met tcp-protocol. U configureert de verbindingsmodus wanneer u het CosmosClient exemplaar maakt in CosmosClientOptions. Zie het artikel over connectiviteitsmodi voor meer informatie over verschillende connectiviteitsopties .

CosmosClient client = new CosmosClient(
  "<nosql-account-endpoint>",
  tokenCredential
  new CosmosClientOptions
  {
      ConnectionMode = ConnectionMode.Gateway // ConnectionMode.Direct is the default
  }
);

Tijdelijke poortuitputting

Als u een hoog verbindingsvolume of hoog poortgebruik op uw exemplaren ziet, controleert u eerst of uw clientexemplaren singletons zijn. Met andere woorden, de clientexemplaren moeten uniek zijn voor de levensduur van de toepassing.

Wanneer deze wordt uitgevoerd op het TCP-protocol, optimaliseert de client voor latentie met behulp van de langdurige verbindingen. Dit is in tegenstelling tot het HTTPS-protocol, dat de verbindingen na twee minuten van inactiviteit beëindigt.

In scenario's waarin u sparse-toegang hebt en als u een hoger aantal verbindingen ziet in vergelijking met gatewaymodustoegang, kunt u het volgende doen:

• Stel de eigenschap CosmosClientOptions.PortReuseMode in op PrivatePortPool (effectief met framework versie 4.6.1 en hoger en .NET Core-versies 2.0 en hoger). Met deze eigenschap kan de SDK een kleine groep tijdelijke poorten gebruiken voor verschillende Azure Cosmos DB-doeleindpunten.
• Configureer de eigenschap CosmosClientOptions.IdleTcpConnectionTimeout als groter dan of gelijk aan 10 minuten. De aanbevolen waarden zijn van 20 minuten tot 24 uur.

Voor prestaties plaatst u clients in dezelfde Azure-regio

Plaats indien mogelijk toepassingen die Azure Cosmos DB aanroepen in dezelfde regio als de Azure Cosmos DB-database. Hier volgt een geschatte vergelijking: aanroepen naar Azure Cosmos DB binnen dezelfde regio eindigen binnen 1 milliseconden (ms) tot 2 ms, maar de latentie tussen de west- en oostkust van de VS is meer dan 50 ms. Deze latentie kan variëren van aanvraag tot aanvraag, afhankelijk van de route die door de aanvraag wordt genomen wanneer deze wordt doorgegeven van de client naar de grens van het Azure-datacenter.

U kunt de laagst mogelijke latentie krijgen door ervoor te zorgen dat de aanroepende toepassing zich in dezelfde Azure-regio bevindt als het ingerichte Azure Cosmos DB-eindpunt. Zie Azure-regio's voor een lijst met beschikbare regio's.

Het aantal threads/taken verhogen

Omdat aanroepen naar Azure Cosmos DB via het netwerk worden uitgevoerd, moet u mogelijk de mate van gelijktijdigheid van uw aanvragen variëren, zodat de clienttoepassing zo min mogelijk tijd besteedt aan het wachten tussen aanvragen. Als u bijvoorbeeld de .NET Task Parallel Library gebruikt, maakt u honderden taken aan die lezen van of schrijven naar Azure Cosmos DB.

Versneld netwerken inschakelen om latentie en CPU-jitter te verminderen

U wordt aangeraden de instructies te volgen om versneld netwerken in te schakelen op uw Virtuele Windows- of Linux-machine in Azure om de prestaties te maximaliseren.

Zonder versneld netwerken kan IO die tussen uw Azure-VM en andere Azure-resources wordt verzonden, onnodig via een host en een virtuele switch tussen de virtuele machine en zijn netwerkkaart worden gerouteerd. Als de host en virtuele switch inline in het gegevenspad worden geplaatst, neemt niet alleen de latentie en jitter in het communicatiekanaal toe, maar wordt ook de CPU-cyclus van de virtuele machine aangetast. Met versneld netwerken, de VM-interfaces rechtstreeks met de NIC zonder tussenpersonen; alle netwerkbeleidsgegevens die door de host en virtuele switch zijn verwerkt, worden nu verwerkt in hardware op de NIC; de host en virtuele switch worden omzeild. Over het algemeen kunt u lagere latentie en hogere doorvoer verwachten, evenals consistentere latentie en een lager CPU-gebruik wanneer u versneld netwerken inschakelt.

Beperkingen: versnelde netwerkverbinding moet worden ondersteund op het vm-besturingssysteem en kan alleen worden ingeschakeld wanneer de virtuele machine wordt gestopt en gedealloceerd. De VM kan niet worden geïmplementeerd met Azure Resource Manager. App Service heeft geen versneld netwerk ingeschakeld.

Zie de instructies voor Windows en Linux voor meer informatie.

SDK-gebruik

De meest recente SDK installeren

De Azure Cosmos DB SDK's worden voortdurend verbeterd om de beste prestaties te bieden. Zie De Azure Cosmos DB SDK om de meest recente SDK te bepalen en verbeteringen te bekijken.

Stream-API's gebruiken

.NET SDK V3 bevat stream-API's die gegevens kunnen ontvangen en retourneren zonder te serialiseren.

Toepassingen in de middelste laag die geen reacties rechtstreeks van de SDK gebruiken, maar deze doorsturen naar andere toepassingslagen, kunnen profiteren van de stream-API's. Zie de voorbeelden van stroomverwerking in de voorbeelden van itembeheer.

Een Singleton Azure Cosmos DB-client gebruiken voor de levensduur van uw toepassing

Elk CosmosClient exemplaar is thread-veilig en voert efficiënt verbindingsbeheer en adrescaching uit wanneer het werkt in de directe modus. Om efficiënt verbindingsbeheer en betere SDK-clientprestaties mogelijk te maken, raden we u aan één exemplaar per AppDomain levensduur van de toepassing te gebruiken voor elk account waarmee uw toepassing communiceert.

Zie de gerelateerde aanbevolen procedures voor multitenant-toepassingen die meerdere accounts verwerken.

Wanneer u aan Azure Functions werkt, moeten instanties ook de bestaande richtlijnen volgen en één exemplaar onderhouden.

Voorkomen dat oproepen worden geblokkeerd

Azure Cosmos DB SDK moet zijn ontworpen om veel aanvragen tegelijkertijd te verwerken. Met asynchrone API's kan een kleine groep threads duizenden gelijktijdige aanvragen verwerken door niet te wachten op blokkeringsaanroepen. In plaats van te wachten op een langlopende synchrone taak om te voltooien, kan de thread aan een andere aanvraag werken.

Een veelvoorkomend prestatieprobleem in apps die gebruikmaken van de Azure Cosmos DB SDK blokkeert aanroepen die asynchroon kunnen zijn. Veel synchrone blokkeringsaanroepen leiden tot starvatie van threadpools en verminderde reactietijden.

Niet:

• Blokkeer asynchrone uitvoering door Task.Wait of Task.Result aan te roepen.
• Gebruik Task.Run om een synchrone API asynchroon te maken.
• Verkrijg vergrendelingen in algemene codepaden. Azure Cosmos DB .NET SDK is het meest presterend wanneer deze is ontworpen om code parallel uit te voeren.
• Roep Task.Run aan en wacht er onmiddellijk op. ASP.NET Core al app-code uitvoert op normale Thread Pool-threads, waardoor het aanroepen van Task.Run alleen resulteert in extra onnodige threadpoolplanning. Zelfs als de geplande code een thread blokkeert, voorkomt Task.Run dat niet.
• Gebruik ToList() Container.GetItemLinqQueryable<T>()niet, waarbij blokkeringsaanroepen worden gebruikt om de query synchroon leeg te maken. Gebruik ToFeedIterator() om de query asynchroon leeg te maken.

Doe het volgende:

• Roep de Azure Cosmos DB .NET API's asynchroon aan.
• De volledige aanroepstack is asynchroon om te profiteren van asynchrone/wachtende patronen.

Een profiler, zoals PerfView, kan worden gebruikt om threads te vinden die vaak worden toegevoegd aan de threadpool. De Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start gebeurtenis geeft een thread aan die is toegevoegd aan de threadgroep.

Inhoudsreactie uitschakelen voor schrijfbewerkingen

Voor workloads met zware nettoladingen kunt u de EnableContentResponseOnWrite aanvraagoptie instellen op false. De service retourneert de gemaakte of bijgewerkte resource niet meer naar de SDK. Normaal gesproken, omdat de toepassing het object heeft dat wordt gemaakt, heeft het niet de service nodig om het te retourneren. De headerwaarden zijn nog steeds toegankelijk, zoals een aanvraagkosten. Als u het antwoord op inhoud uitschakelt, kunt u de prestaties verbeteren, omdat de SDK geen geheugen meer hoeft toe te wijzen of de hoofdtekst van het antwoord serialiseert. Het vermindert ook het netwerkbandbreedtegebruik om de prestaties verder te helpen.

ItemRequestOptions requestOptions = new ItemRequestOptions() { EnableContentResponseOnWrite = false };
ItemResponse<Book> itemResponse = await this.container.CreateItemAsync<Book>(book, new PartitionKey(book.pk), requestOptions);
// Resource will be null
itemResponse.Resource

Bulk inschakelen om te optimaliseren voor doorvoer in plaats van latentie

Schakel bulksgewijs in voor scenario's waarbij de workload een grote hoeveelheid doorvoer vereist en latentie niet zo belangrijk is. Voor meer informatie over hoe de Bulk-functie ingeschakeld kan worden en voor welk soort scenario's deze geschikt is, zie Inleiding tot Bulkondersteuning.

Verhoog System.Net MaxConnections per host wanneer u de gatewaymodus gebruikt

Azure Cosmos DB-aanvragen worden uitgevoerd via HTTPS/REST wanneer u de gatewaymodus gebruikt. Ze zijn onderworpen aan de standaardverbindingslimiet per hostnaam of IP-adres. Mogelijk moet u instellen MaxConnections op een hogere waarde (van 100 tot en met 1000), zodat de clientbibliotheek meerdere gelijktijdige verbindingen met Azure Cosmos DB kan gebruiken. In .NET SDK 1.8.0 en hoger is de standaardwaarde voor ServicePointManager.DefaultConnectionLimit 50. Als u de waarde wilt wijzigen, kunt u instellen Documents.Client.ConnectionPolicy.MaxConnectionLimit op een hogere waarde.

Het aantal threads/taken verhogen

Zie Het aantal threads/taken verhogen in de sectie Netwerken van dit artikel.

Querybewerkingen

Zie de prestatietips voor querybewerkingen.

Indexeringsbeleid

Niet-gebruikte paden uitsluiten van indexering voor snellere schrijfbewerkingen

Met het indexeringsbeleid van Azure Cosmos DB kunt u ook opgeven welke documentpaden moeten worden opgenomen of uitgesloten van indexering met behulp van indexeringspaden (IndexingPolicy.IncludedPaths en IndexingPolicy.ExcludedPaths).

Door alleen de paden te indexeren die u nodig hebt, kunt u schrijfprestaties verbeteren, RU-kosten voor schrijfbewerkingen verminderen en indexopslag verminderen voor scenario's waarin de querypatronen vooraf bekend zijn. Dit komt doordat indexeringskosten rechtstreeks correleren met het aantal unieke paden dat is geïndexeerd. De volgende code laat bijvoorbeeld zien hoe u een hele sectie van de documenten (een substructuur) kunt uitsluiten van indexering met behulp van het * jokerteken:

var containerProperties = new ContainerProperties(id: "excludedPathCollection", partitionKeyPath: "/pk" );
containerProperties.IndexingPolicy.IncludedPaths.Add(new IncludedPath { Path = "/*" });
containerProperties.IndexingPolicy.ExcludedPaths.Add(new ExcludedPath { Path = "/nonIndexedContent/*");
Container container = await this.cosmosDatabase.CreateContainerAsync(containerProperties);

Zie Het indexeringsbeleid van Azure Cosmos DB voor meer informatie.

Doorvoer

Meten en afstemmen voor lager RU/s-gebruik

Azure Cosmos DB biedt een uitgebreide set databasebewerkingen. Deze bewerkingen omvatten relationele en hiërarchische query's met door de gebruiker gedefinieerde functies (UDF's), opgeslagen procedures en triggers, die allemaal op de documenten in een databaseverzameling werken.

De kosten die aan elk van deze bewerkingen zijn gekoppeld, variëren afhankelijk van de CPU, IO en het geheugen die nodig zijn om de bewerking te voltooien. In plaats van aan hardwareresources te denken en te beheren, kunt u een aanvraageenheid beschouwen als één meting voor de resources die nodig zijn voor het uitvoeren van verschillende databasebewerkingen en het uitvoeren van een toepassingsaanvraag.

Doorvoer wordt ingericht op basis van het aantal aanvraageenheden dat is ingesteld voor elke container. RU-verbruik wordt geëvalueerd als een snelheid van eenheden per seconde. Toepassingen die de ingerichte RU-snelheid voor hun container overschrijden, worden beperkt totdat de snelheid lager is dan het ingerichte niveau voor de container. Als uw toepassing een hoger doorvoerniveau vereist, kunt u de doorvoer verhogen door meer RU's in te richten.

De complexiteit van een query is van invloed op het aantal RU's dat wordt verbruikt voor een bewerking. Het aantal predicaten, de aard van de predicaten, het aantal UDF-bestanden en de grootte van de brongegevensset zijn allemaal van invloed op de kosten van querybewerkingen.

Als u de overhead van een bewerking wilt meten (maken, bijwerken of verwijderen), inspecteert u de header x-ms-request-charge (of de equivalente RequestCharge eigenschap in ResourceResponse<T> of FeedResponse<T> in de .NET SDK) om het aantal RU's te meten dat door de bewerkingen wordt gebruikt:

// Measure the performance (Request Units) of writes
ItemResponse<Book> response = await container.CreateItemAsync<Book>(myBook, new PartitionKey(myBook.PkValue));
Console.WriteLine("Insert of item consumed {0} request units", response.RequestCharge);
// Measure the performance (Request Units) of queries
FeedIterator<Book> queryable = container.GetItemQueryIterator<ToDoActivity>(queryString);
while (queryable.HasMoreResults)
    {
        FeedResponse<Book> queryResponse = await queryable.ExecuteNextAsync<Book>();
        Console.WriteLine("Query batch consumed {0} request units", queryResponse.RequestCharge);
    }

De aanvraagkosten die in deze header worden geretourneerd, zijn een fractie van uw ingerichte doorvoercapaciteit, namelijk 2.000 RU/s. Als de voorgaande query bijvoorbeeld 1000 1 KB-documenten retourneert, zijn de kosten van de bewerking 1000. Binnen één seconde verwerkt de server slechts twee van dergelijke aanvragen voordat deze de latere aanvragen beperkt. Zie Aanvraageenheden en de rekenmachine voor aanvraageenheden voor meer informatie.

Omgaan met snelheidsbeperking/aanvraagsnelheid te hoog

Wanneer een client de gereserveerde doorvoer voor een account probeert te overschrijden, is er geen prestatievermindering op de server en is er geen gebruik van doorvoercapaciteit buiten het gereserveerde niveau. De server beëindigt de aanvraag met RequestRateTooLarge (HTTP-statuscode 429). Het retourneert een header x-ms-retry-after-ms die de hoeveelheid tijd aangeeft, in milliseconden, dat de gebruiker moet wachten voordat de aanvraag opnieuw wordt uitgevoerd.

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

De SDK's vangen dit antwoord impliciet op, respecteren de door de server gespecificeerde retry-after header, en dienen het verzoek opnieuw in. Tenzij uw account gelijktijdig wordt geopend door meerdere clients, slaagt de volgende nieuwe poging.

Als u meerdere clients hebt die cumulatief en consistent boven de aanvraagsnelheid opereren, is het standaard aantal herhaalde pogingen dat momenteel intern door de client is ingesteld op 9 mogelijk niet voldoende. In dit geval genereert de client een CosmosException met statuscode 429 aan de toepassing.

U kunt het standaardaantal nieuwe pogingen wijzigen door het RetryOptions in te stellen op de CosmosClientOptions instantie. De CosmosException met statuscode 429 wordt standaard geretourneerd na een cumulatieve wachttijd van 30 seconden als de aanvraag blijft werken boven de aanvraagsnelheid. Deze fout wordt geretourneerd, zelfs wanneer het huidige aantal nieuwe pogingen kleiner is dan het maximumaantal nieuwe pogingen, of de huidige waarde de standaardwaarde is van 9 of een door de gebruiker gedefinieerde waarde.

Het geautomatiseerde gedrag voor opnieuw proberen helpt de tolerantie en bruikbaarheid voor de meeste toepassingen te verbeteren. Maar het is misschien niet het beste gedrag wanneer u prestatiebenchmarks uitvoert, met name wanneer u latentie meet. De latentie zoals ervaren door de cliënt zal pieken als het experiment de serverlimiet bereikt en ervoor zorgt dat de client-SDK ongemerkt herhaalt. Als u latentiepieken wilt voorkomen tijdens prestatieexperimenten, meet u de belasting die door elke bewerking teruggegeven wordt en zorgt u ervoor dat aanvragen onder de gereserveerde aanvraagfrequentie worden uitgevoerd.

Zie Aanvraageenheden voor meer informatie.

Ontwerp voor kleinere documenten voor een hogere doorvoer

De aanvraagkosten (de kosten voor aanvraagverwerking) van een opgegeven bewerking komen rechtstreeks overeen met de grootte van het document. Bewerkingen op grote documenten kosten meer dan bewerkingen op kleine documenten.

Volgende stappen

• Azure Cosmos DB for NoSQL-prestaties meten met een benchmarking-framework
• Partitioneren en horizontaal schalen in Azure Cosmos DB