Prestandatips för Azure Cosmos DB och .NET

GÄLLER FÖR: NoSQL

Azure Cosmos DB är en snabb, flexibel distribuerad databas som skalar sömlöst med garanterad svarstid och dataflödesnivåer. Du behöver inte göra större arkitekturändringar eller skriva komplex kod för att skala databasen med Azure Cosmos DB. Det är lika enkelt att skala upp och ned som att göra ett enda API-anrop. Mer information finns i etablera containerdataflöde eller etablera databasdataflöde.

Eftersom Azure Cosmos DB nås via nätverksanrop kan du göra optimeringar på klientsidan för att uppnå högsta prestanda när du använder SQL .NET SDK.

Om du försöker förbättra databasens prestanda bör du överväga de alternativ som visas i följande avsnitt.

Värdrekommendationer

Aktivera skräpinsamling på serversidan

Att minska frekvensen för skräpinsamling kan i vissa fall vara till hjälp. I .NET anger du gcServer till true.

Skala ut klientarbetsbelastningen

Om du testar på höga dataflödesnivåer, eller med hastigheter som är större än 50 000 enheter för programbegäran per sekund (RU/s), kan klientprogrammet bli en flaskhals för arbetsbelastningen eftersom datorn kan begränsa processor- eller nätverksanvändningen. Om du når denna fas kan du fortsätta att utöka Azure Cosmos DB-kontot ytterligare genom att skala ut dina klientprogram genom att sprida dem över flera servrar.

Metadataåtgärder

Kontrollera inte att det finns en databas eller container genom att anropa Create...IfNotExistsAsync eller Read...Async i den heta sökvägen eller innan du utför en objektåtgärd. Valideringen bör endast utföras vid programstart när det är nödvändigt, om du förväntar dig att de ska tas bort (annars behövs det inte). Dessa metadataåtgärder genererar extra svarstid från slutpunkt till slutpunkt, har inget serviceavtal och har egna separata begränsningar som inte skalas som dataåtgärder.

Loggning och spårning

I vissa miljöer är .NET DefaultTraceListener aktiverat. DefaultTraceListener medför prestandaproblem i produktionsmiljöer som orsakar höga CPU- och I/O-begränsningar. Kontrollera att DefaultTraceListener är inaktiverat för din applikation genom att ta bort det från TraceListeners i produktionsmiljöer.

SDK-versioner som är större än 3.23.0 tar automatiskt bort det när det identifieras. Med äldre versioner kan du ta bort den med hjälp av följande kommandon:

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>

Hög tillgänglighet

Allmän vägledning om hur du konfigurerar hög tillgänglighet i Azure Cosmos DB finns i Hög tillgänglighet i Azure Cosmos DB.

Förutom en bra grundläggande konfiguration i databasplattformen finns det specifika tekniker som kan implementeras i själva .NET SDK, vilket kan vara till hjälp vid avbrottsscenarier. Två viktiga strategier är den tröskelvärdesbaserade tillgänglighetsstrategin och kretsbrytaren på partitionsnivå.

Strategi för tröskelvärdesbaserad tillgänglighet

Den tröskelvärdesbaserade tillgänglighetsstrategin kan förbättra svarstiden och tillgängligheten genom att skicka parallella läsbegäranden till sekundära regioner (enligt definitionen i ApplicationPreferredRegions) och acceptera det snabbaste svaret. Den här metoden kan drastiskt minska effekten av regionala avbrott eller villkor med hög latens för programprestanda.

Exempelkonfiguration:

Du kan konfigurera detta med hjälp av 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();

Eller genom att konfigurera alternativ och lägga till dem i 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);

Så här fungerar det:

1. Inledande begäran: Vid tidpunkten för T1 görs en läsbegäran till den primära regionen (till exempel USA, östra). SDK väntar på ett svar på upp till 500 millisekunder (värdet threshold ).

2. Andra begäran: Om det inte finns något svar från den primära regionen inom 500 millisekunder skickas en parallell begäran till nästa föredragna region (till exempel USA, östra 2).

3. Tredje begäran: Om varken den primära eller den sekundära regionen svarar inom 600 millisekunder (500 ms + 100 ms, thresholdStep värdet) skickar SDK:t en annan parallell begäran till den tredje önskade regionen (till exempel USA, västra).

4. Snabbaste svar vinner: Oavsett vilken region som svarar först godkänns svaret och de andra parallella begärandena ignoreras.

Kretsbrytare på partitionsnivå

Kretsbrytaren på partitionsnivå (PPCB) är en funktion i .NET SDK som förbättrar tillgängligheten och svarstiden genom att spåra felaktiga fysiska partitioner. När det är aktiverat hjälper det till att dirigera begäranden till hälsosammare regioner, vilket förhindrar sammanhängande fel på grund av regionala eller partitionsspecifika problem. Funktionen är oberoende av backend-utlöst övergång och styrs genom miljövariabler.

Den här funktionen är inaktiverad som standard, men aktiveras automatiskt när redundans på partitionsnivå aktiveras.

Så här fungerar det

1. Felidentifiering: När specifika fel, till exempel 503 Service Unavailable, 408 Request Timeouteller annulleringstoken observeras, räknar SDK:t efterföljande fel för en partition.
2. Utlöser redundans: När ett konfigurerat tröskelvärde för efterföljande fel har nåtts omdirigerar SDK begäranden för partitionsnyckelintervallet till nästa önskade region med hjälp av GlobalPartitionEndpointManagerCore.TryMarkEndpointUnavailableForPartitionKeyRange.
3. Bakgrundsåterställning: En bakgrundsaktivitet initieras under övergången för att regelbundet bedöma hälsan hos den misslyckade partitionen genom att försöka ansluta till alla fyra replikerna. När det är felfritt tar SDK bort åsidosättningen och återgår till den primära regionen.

Beteende efter kontotyp

• Skriv till en enskild region (single master): Endast läs begäranden deltar i PPCB-redundanslogik.
• Skrivning i flera regioner (flera huvudservrar): Både läs- och skrivbegäranden använder PPCB-redundanslogik.

Konfigurationsalternativ

Använd följande miljövariabler för att konfigurera PPCB:

Jämföra tillgänglighetsoptimeringar

• Strategi för tröskelvärdesbaserad tillgänglighet:

  • Fördel: Minskar svarstiden genom att skicka parallella läsbegäranden till sekundära regioner och förbättrar tillgängligheten genom att föregripa begäranden som resulterar i tidsgränser för nätverket.
  • Kompromiss: Medför extra kostnader för enheter för begäranden (RU: er) jämfört med kretsbrytare, på grund av ytterligare parallella begäranden mellan regioner (men endast under perioder då tröskelvärden överskrids).
  • Användningsfall: Optimalt för läsintensiva arbetsbelastningar där det är viktigt att minska svarstiden och en viss extra kostnad (både när det gäller RU-debitering och cpu-belastning för klienten) är acceptabelt. Skrivåtgärder kan också vara till nytta om man väljer en återföringsprincip för icke-idempotenta skrivningar och kontot har skrivmöjligheter i flera regioner.

• Kretsbrytare på partitionsnivå:

  • Fördel: Förbättrar tillgängligheten och svarstiden genom att undvika partitioner som inte är felfria, vilket säkerställer att begäranden dirigeras till hälsosammare regioner.
  • Kompromiss: Medför inte fler RU-kostnader, men kan fortfarande tillåta viss initial tillgänglighetsförlust för begäranden som resulterar i tidsgränser för nätverket.
  • Användningsfall: Perfekt för skrivintensiva eller blandade arbetsbelastningar där konsekventa prestanda är viktiga, särskilt när du hanterar partitioner som tillfälligt kan bli felaktiga.

Båda strategierna kan användas tillsammans för att förbättra läs- och skrivtillgängligheten och minska svarstiden. Kretsbrytare på partitionsnivå kan hantera olika tillfälliga felscenarier, inklusive sådana som kan leda till långsamma repliker utan att behöva utföra parallella begäranden. Att lägga till en tröskelbaserad tillgänglighetsstrategi minimerar dessutom svarstiden och eliminerar tillgänglighetsförlust, om extra RU-kostnad är acceptabel.

Genom att implementera dessa strategier kan utvecklare se till att deras program förblir motståndskraftiga, har höga prestanda och ger en bättre användarupplevelse även under regionala avbrott eller långa svarstider.

Undantagna regioner

Funktionen exkluderade regioner ger detaljerad kontroll över begärandedirigering genom att tillåta att du exkluderar specifika regioner från önskade platser per begäran. Den här funktionen är tillgänglig i Azure Cosmos DB .NET SDK version 3.37.0 och senare.

Viktiga fördelar:

• Hantera hastighetsbegränsning: När du stöter på svar på 429 (för många begäranden) dirigerar du automatiskt begäranden till alternativa regioner med tillgängligt dataflöde
• Riktad routning: Se till att begäranden hanteras från specifika regioner genom att exkludera alla andra
• Kringgå önskad ordning: Åsidosätt standardlistan för prioriterade regioner för enskilda begäranden utan att skapa separata klienter

Configuration:

Exkluderade regioner kan konfigureras på begärandenivå med hjälp av ExcludeRegions egenskapen:

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" }
  });

Exempel på användningsfall – hanteringsfrekvensbegränsning:

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);
}

Funktionen fungerar även med frågor och andra åtgärder:

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();
    }
}

Finjustering av konsistens och tillgänglighet

Funktionen exkluderade regioner ger ytterligare en mekanism för att balansera konsekvens- och tillgänglighetsutjämningar i ditt program. Den här funktionen är särskilt värdefull i dynamiska scenarier där kraven kan ändras baserat på driftsförhållanden:

Dynamisk avbrottshantering: När en primär region upplever ett avbrott och tröskelvärden för kretsbrytare på partitionsnivå visar sig vara otillräckliga möjliggör exkluderade regioner omedelbar redundans utan kodändringar eller programomstarter. Detta ger snabbare svar på regionala problem jämfört med att vänta på automatisk aktivering av kretsbrytare.

Inställningar för villkorsstyrd konsekvens: Program kan implementera olika konsekvensstrategier baserat på drifttillstånd:

• Stabilt tillstånd: Prioritera konsekvent dataläsning genom att utesluta alla regioner utom den primära, vilket säkerställer datakonsistens även om det påverkar tillgängligheten.
• Avbrottsscenarier: Prioritera tillgänglighet framför strikt konsekvens genom att tillåta routning mellan regioner, acceptera potentiell datafördröjning i utbyte mot fortsatt tjänsttillgänglighet

Den här metoden gör det möjligt för externa mekanismer (till exempel trafikhanterare eller lastbalanserare) att samordna redundansbeslut medan programmet har kontroll över konsekvenskraven genom mönster för regionsundantag.

När alla regioner undantas dirigeras begäranden till den primära/hubbregionen. Den här funktionen fungerar med alla typer av begäranden, inklusive frågor och är särskilt användbar för att underhålla singleton-klientinstanser samtidigt som du uppnår ett flexibelt routningsbeteende.

Nätverk

Anslutningsprincip: Använd direktanslutningsläge

Standardanslutningsläget för .NET V3 SDK är direkt med TCP-protokollet. Du konfigurerar anslutningsläget när du skapar instansen CosmosClient i CosmosClientOptions. Mer information om olika anslutningsalternativ finns i artikeln om anslutningslägen .

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

Tillfällig portöverbelastning

Om du ser en hög anslutningsvolym eller hög portanvändning på dina instanser kontrollerar du först att klientinstanserna är singletons. Med andra ord bör klientinstanserna vara unika för programmets livslängd.

När den körs på TCP-protokollet optimerar klienten för latens genom att använda de långvariga anslutningarna. Detta står i kontrast till HTTPS-protokollet, som avslutar anslutningarna efter två minuters inaktivitet.

I scenarier där du har gles åtkomst, och om du ser ett högre antal anslutningar jämfört med åtkomst i gatewayläge, kan du:

• Konfigurera egenskapen CosmosClientOptions.PortReuseMode till PrivatePortPool (gäller med ramverksversionerna 4.6.1 och senare och .NET Core version 2.0 och senare). Med den här egenskapen kan SDK använda en liten pool med tillfälliga portar för olika Azure Cosmos DB-målslutpunkter.
• Konfigurera egenskapen CosmosClientOptions.IdleTcpConnectionTimeout som större än eller lika med 10 minuter. De rekommenderade värdena är från 20 minuter till 24 timmar.

För prestanda kan du samla klienter i samma Azure-region

När det är möjligt placerar du alla program som anropar Azure Cosmos DB i samma region som Azure Cosmos DB-databasen. Här är en ungefärlig jämförelse: anrop till Azure Cosmos DB inom samma region avslutas inom 1 millisekunder (ms) till 2 ms, men svarstiden mellan USA:s västra och östra kust är mer än 50 ms. Den här svarstiden kan variera från begäran till begäran, beroende på vilken väg begäran tar när den skickas från klienten till Azures datacentergräns.

Du kan få lägsta möjliga svarstid genom att se till att det anropande programmet finns inom samma Azure-region som den etablerade Azure Cosmos DB-slutpunkten. En lista över tillgängliga regioner finns i Azure-regioner.

Öka antalet trådar/uppgifter

Eftersom anrop till Azure Cosmos DB görs via nätverket kan du behöva variera graden av samtidighet för dina begäranden så att klientprogrammet ägnar minimal tid åt att vänta mellan begäranden. Om du till exempel använder .NET-aktivitetsparallellt bibliotek skapar du i ordningen hundratals aktiviteter som läser från eller skriver till Azure Cosmos DB.

Aktivera accelererat nätverk för att minska svarstiden och CPU-jitter

Vi rekommenderar att du följer anvisningarna för att aktivera accelererat nätverk i din virtuella Windows- eller Linux Azure-dator för att maximera prestandan.

Utan accelererat nätverk kan I/O som överförs mellan din virtuella Azure-dator och andra Azure-resurser i onödan dirigeras via en värd och en virtuell växel mellan den virtuella datorn och dess nätverkskort. Att ha värden och den virtuella växeln infogade i dataflödet ökar inte bara latensen och jitter i kommunikationskanalen, utan stjäl även CPU-cykler från den virtuella datorn (VM). Med accelererat nätverk gränssnittar den virtuella datorn direkt med nätverkskortet utan mellanhänder. All information om nätverkspolicy som hanterades av värden och den virtuella växeln hanteras nu i nätverkskortets maskinvara. Värden och den virtuella växeln kringgås. Vanligtvis kan du förvänta dig lägre svarstid och högre dataflöde, samt mer konsekvent svarstid och minskad CPU-användning när du aktiverar accelererat nätverk.

Begränsningar: Accelererat nätverk måste stödjas på det virtuella datoroperativsystemet och kan bara aktiveras när den virtuella datorn stoppas och frigörs. Det går inte att distribuera den virtuella datorn med Azure Resource Manager. App Service har inget accelererat nätverk aktiverat.

Mer information finns i Windows- och Linux-instruktionerna .

SDK-användning

Installera den senaste SDK:en

Azure Cosmos DB SDK:er förbättras ständigt för att ge bästa möjliga prestanda. Information om de senaste SDK:erna och granska förbättringar finns i Azure Cosmos DB SDK.

Använda stream-API:er

.NET SDK V3 innehåller stream-API:er som kan ta emot och returnera data utan serialisering.

Mellannivåprogram som inte använder svar direkt från SDK men vidarebefordrar dem till andra programnivåer kan dra nytta av stream-API:erna. Exempel på dataströmhantering finns i exempel på objekthantering .

Använda en Singleton Azure Cosmos DB-klient under programmets livslängd

Varje CosmosClient instans är trådsäker och utför effektiv anslutningshantering och adresscachelagring när den körs i direktläge. För att möjliggöra effektiv anslutningshantering och bättre SDK-klientprestanda rekommenderar vi att du använder en enda instans per AppDomain under programmets livslängd för varje konto som ditt program interagerar med.

Information om program med flera klienter som hanterar flera konton finns i de relaterade metodtipsen.

När du arbetar med Azure Functions bör instanser också följa de befintliga riktlinjerna och underhålla en enda instans.

Undvik blockeringsanrop

Azure Cosmos DB SDK bör utformas för att bearbeta många begäranden samtidigt. Asynkrona API:er gör det möjligt för en liten pool med trådar att hantera tusentals samtidiga begäranden genom att inte vänta på blockeringsanrop. I stället för att vänta på att en långvarig synkron uppgift ska slutföras kan tråden fungera på en annan begäran.

Ett vanligt prestandaproblem i appar som använder Azure Cosmos DB SDK blockerar anrop som kan vara asynkrona. Många synkrona blockeringsanrop leder till utsvulten trådpool och försämrade svarstider.

Gör inte så här:

• Blockera asynkron körning genom att anropa Task.Wait eller Task.Result.
• Använd Task.Run för att göra ett synkront API asynkront.
• Skaffa lås i vanliga kodvägar. Azure Cosmos DB .NET SDK är mest högpresterande när det är konstruerat för att köra kod parallellt.
• Anropa Task.Run och vänta omedelbart på det. ASP.NET Core kör redan appkod på vanliga trådpoolstrådar, så att anropa Task.Run resulterar endast i extra onödig schemaläggning av trådpooler. Även om den schemalagda koden skulle blockera en tråd förhindrar Task.Run inte det.
• Använd inte ToList() på Container.GetItemLinqQueryable<T>(), som använder blockeringsanrop för att synkront tömma frågan. Använd ToFeedIterator() för att tömma frågan asynkront.

Gör:

• Anropa API:erna i Azure Cosmos DB:s .NET-bibliotek asynkront.
• Hela anropsstacken är asynkron för att dra nytta av asynkrona/väntande mönster.

En profilerare, till exempel PerfView, kan användas för att hitta trådar som ofta läggs till i trådpoolen. Händelsen Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start anger en tråd som lagts till i trådpoolen.

Inaktivera innehållssvar vid skrivåtgärder

För arbetsbelastningar som har tunga nyttolaster anger du EnableContentResponseOnWrite alternativet för begäran till false. Tjänsten returnerar inte längre den skapade eller uppdaterade resursen till SDK:n. Eftersom programmet har objektet som skapas behöver det normalt inte tjänsten för att returnera det. Huvudvärdena är fortfarande tillgängliga, till exempel en begärandeavgift. Om du inaktiverar innehållssvaret kan du förbättra prestandan eftersom SDK:n inte längre behöver allokera minne eller serialisera svarets brödtext. Det minskar också användningen av nätverksbandbredd för att ytterligare hjälpa prestanda.

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

Aktivera Bulk för att optimera för genomströmning istället för latens

Aktivera Bulk för scenarier där arbetsbelastningen kräver en stor mängd dataflöde, och latens inte är lika viktig. Mer information om hur du aktiverar massfunktionen och vilka scenarier den ska användas för finns i Introduktion till masssupport.

Öka System.Net MaxConnections per värd när du använder Gateway-läge

Azure Cosmos DB-begäranden görs via HTTPS/REST när du använder gatewayläge. De omfattas av standardanslutningsgränsen per värdnamn eller IP-adress. Du kan behöva ange MaxConnections ett högre värde (från 100 till 1 000) så att klientbiblioteket kan använda flera samtidiga anslutningar till Azure Cosmos DB. I .NET SDK 1.8.0 och senare är standardvärdet för ServicePointManager.DefaultConnectionLimit 50. Om du vill ändra värdet kan du ange Documents.Client.ConnectionPolicy.MaxConnectionLimit ett högre värde.

Öka antalet trådar/uppgifter

Se Öka antalet trådar/uppgifter i avsnittet Nätverk i den här artikeln.

Frågeoperationer

Information om frågeåtgärder finns i prestandatipsen för frågor.

Indexeringsprincip

Utesluta sökvägar som inte används från indexering för att få snabbare skrivning

Med Azure Cosmos DB-indexeringsprincipen kan du också ange vilka dokumentsökvägar som ska inkluderas eller undantas från indexering med hjälp av indexeringssökvägar (IndexingPolicy.IncludedPaths och IndexingPolicy.ExcludedPaths).

Indexering av endast de sökvägar du behöver kan förbättra skrivprestanda, minska RU-avgifter för skrivåtgärder och minska indexlagringen för scenarier där frågemönstren är kända i förväg. Det beror på att indexeringskostnaderna korrelerar direkt med antalet indexerade unika sökvägar. Följande kod visar till exempel hur du undantar en hel del av dokumenten (ett underträd) från indexering med hjälp * av jokertecknet:

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);

Mer information finns i Azure Cosmos DB-indexeringsprinciper.

Genomflöde

Mät och justera för lägre RU/s-användning

Azure Cosmos DB erbjuder en omfattande uppsättning databasåtgärder. Dessa åtgärder omfattar relations- och hierarkiska frågor med användardefinierade funktioner (UDF: er), lagrade procedurer och utlösare, som alla körs på dokumenten i en databassamling.

Kostnaderna för var och en av dessa åtgärder varierar beroende på processor, I/O och minne som krävs för att slutföra åtgärden. I stället för att tänka på och hantera maskinvaruresurser kan du betrakta en enhet för begäran som ett enda mått för de resurser som krävs för att utföra olika databasåtgärder och hantera en programbegäran.

Dataflödet försörjs baserat på antalet förfrågningsenheter som angetts för varje container. RU-förbrukning utvärderas som enheter per sekund. Applikationer som överskrider den tilldelade RU-hastigheten för sin container begränsas tills hastigheten sjunker under den tilldelade nivån för containern. Om ditt program kräver en högre dataflödesnivå kan du öka dataflödet genom att etablera fler RU:er.

Komplexiteten i en fråga påverkar hur många RU:er som används för en åtgärd. Antalet predikat, predikatens natur, antalet UDF-filer och storleken på källdatauppsättningen påverkar alla kostnaden för frågeåtgärder.

Om du vill mäta omkostnaderna för en åtgärd (skapa, uppdatera eller ta bort) kontrollerar du rubriken x-ms-request-charge (eller motsvarande RequestCharge egenskap i ResourceResponse<T> eller FeedResponse<T> i .NET SDK) för att mäta antalet RU:er som förbrukas av åtgärderna:

// 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);
    }

Den begärankostnad som returneras i detta huvud är en bråkdel av din etablerade kapacitet (det vill säga: 2 000 RU/s). Om den föregående frågan till exempel returnerar 1 000 1 KB-dokument är kostnaden för åtgärden 1 000. Så inom en sekund respekterar servern bara två sådana begäranden innan den hastighetsbegränsar senare begäranden. Mer information finns i Enheter för begäran och kalkylatorn för begärandeenheten.

Hantering av hastighetsbegränsning/begärandefrekvens för hög

När en klient försöker överskrida det reserverade dataflödet för ett konto sker ingen prestandaförsämring på servern och ingen användning av dataflödeskapacitet utöver den reserverade nivån. Servern avslutar begäran i förebyggande syfte med RequestRateTooLarge (HTTP-statuskod 429). Den returnerar ett x-ms-retry-after-ms-huvud som anger hur lång tid, i millisekunder, som användaren måste vänta innan begäran görs igen.

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

SDK:erna fångar alla implicit detta svar, respektera retry-after-headern som servern angett och göra begäran igen. Om inte ditt konto används samtidigt av flera klienter kommer nästa återförsök att lyckas.

Om du har fler än en klient som kumulativt fungerar konsekvent över begärandefrekvensen räcker det kanske inte med det standardantal för återförsök som för närvarande är inställt på 9 internt av klienten. I det här fallet genererar klienten en CosmosException med statuskod 429 till programmet.

Du kan ändra standardantalet för återförsök genom att ställa in RetryOptions på CosmosClientOptions-instansen. Som standard returneras CosmosException med statuskod 429 efter en kumulativ väntetid på 30 sekunder om begäran fortsätter att fungera över begärandefrekvensen. Det här felet returneras även om det aktuella antalet återförsök är mindre än det maximala antalet återförsök, oavsett om det aktuella värdet är standardvärdet 9 eller ett användardefinierat värde.

Det automatiserade återförsöksbeteendet hjälper till att förbättra återhämtning och användbarhet för de flesta program. Men det kanske inte är det bästa beteendet när du utför prestandamått, särskilt när du mäter svarstiden. Den av klienten observerade latensen kommer att öka om experimentet når serverbegränsningen och gör att klient-SDK:t tyst gör ett nytt försök. För att undvika latensspikar under prestandaexperiment mäter du den belastning som returneras av varje åtgärd och ser till att begäranden fungerar under den reserverade begärandefrekvensen.

Mer information finns i Enheter för begäran.

Design för mindre dokument för högre dataflöde

Begärandeavgiften (dvs. kostnaden för bearbetning av begäran) för en angiven åtgärd korrelerar direkt med dokumentets storlek. Åtgärder på stora dokument kostar mer än åtgärder för små dokument.

Nästa steg

• Mäta Azure Cosmos DB för NoSQL-prestanda med ett benchmarking-ramverk
• Partitionering och horisontell skalning i Azure Cosmos DB