Prestandatips för Azure Cosmos DB och .NET SDK v2Performance tips for Azure Cosmos DB and .NET SDK v2

GÄLLER för: SQL API

Azure Cosmos DB är en snabb och flexibel distribuerad databas som skalar sömlöst med garanterad svars tid och data flöde.Azure Cosmos DB is a fast and flexible distributed database that scales seamlessly with guaranteed latency and throughput. Du behöver inte göra större ändringar i arkitekturen eller skriva komplex kod för att skala databasen med Azure Cosmos DB.You don't have to make major architecture changes or write complex code to scale your database with Azure Cosmos DB. Att skala upp och ned är lika enkelt som att göra ett enda API-anrop.Scaling up and down is as easy as making a single API call. Mer information finns i så här etablerar du behållar data flöde eller hur du etablerar databas data flöde.To learn more, see how to provision container throughput or how to provision database throughput. Men eftersom Azure Cosmos DB nås via nätverks anrop finns det optimeringar på klient sidan som du kan göra för att uppnå högsta prestanda när du använder SQL .NET SDK.But because Azure Cosmos DB is accessed via network calls, there are client-side optimizations you can make to achieve peak performance when you use the SQL .NET SDK.

Om du försöker förbättra databasens prestanda bör du därför överväga följande alternativ:So, if you're trying to improve your database performance, consider these options:

Uppgradera till .NET v3 SDKUpgrade to the .NET V3 SDK

.Net v3 SDK lanseras.The .NET v3 SDK is released. Om du använder .NET v3 SDK, se prestanda guiden för .net v3 för följande information:If you use the .NET v3 SDK, see the .NET v3 performance guide for the following information:

  • Standardinställningar för direkt TCP-lägeDefaults to Direct TCP mode
  • Stream API-stödStream API support
  • Stöd för anpassad serialisering för att tillåta System.Text.JSanvändningSupport custom serializer to allow System.Text.JSON usage
  • Integrerad batch och Mass stödIntegrated batch and bulk support

Värd rekommendationerHosting recommendations

Använd Windows 64-bitar i stället för Linux-eller Windows 32-bitars värd bearbetning för frågor intensiva arbets belastningarFor query-intensive workloads, use Windows 64-bit instead of Linux or Windows 32-bit host processing

Vi rekommenderar Windows 64-bitars värd bearbetning för bättre prestanda.We recommend Windows 64-bit host processing for improved performance. SQL-SDK: n innehåller en intern ServiceInterop.dll för att analysera och optimera frågor lokalt.The SQL SDK includes a native ServiceInterop.dll to parse and optimize queries locally. ServiceInterop.dll stöds endast på Windows x64-plattformen.ServiceInterop.dll is supported only on the Windows x64 platform. För Linux och andra plattformar som inte stöds, där ServiceInterop.dll inte är tillgänglig, görs ytterligare ett nätverks anrop till gatewayen för att hämta den optimerade frågan.For Linux and other unsupported platforms where ServiceInterop.dll isn't available, an additional network call is made to the gateway to get the optimized query. Följande typer av program använder 32-bitars värd bearbetning som standard.The following types of applications use 32-bit host processing by default. Om du vill ändra värd bearbetningen till 64-bitars bearbetning följer du dessa steg baserat på typen av program:To change host processing to 64-bit processing, follow these steps, based on the type of your application:

  • För körbara program kan du ändra värd bearbetningen genom att ange plattforms målet till x64 i fönstret projekt egenskaper på fliken skapa .For executable applications, you can change host processing by setting the platform target to x64 in the Project Properties window, on the Build tab.

  • För VSTest-baserade test projekt kan du ändra värd bearbetningen genom att välja testa > standardinställningar > standard processor arkitektur som x64test menyn i Visual Studio.For VSTest-based test projects, you can change host processing by selecting Test > Test Settings > Default Processor Architecture as X64 on the Visual Studio Test menu.

  • För lokalt distribuerade ASP.NET-webbprogram kan du ändra värd bearbetningen genom att välja Använd 64-bitars versionen av IIS Express för webbplatser och projekt under verktyg > alternativ > projekt och > webb projekt för lösningar.For locally deployed ASP.NET web applications, you can change host processing by selecting Use the 64-bit version of IIS Express for web sites and projects under Tools > Options > Projects and Solutions > Web Projects.

  • För ASP.NET-webbprogram som distribueras i Azure kan du ändra värd bearbetningen genom att välja 64-bitars plattform i program inställningar i Azure Portal.For ASP.NET web applications deployed on Azure, you can change host processing by selecting the 64-bit platform in Application settings in the Azure portal.

Anteckning

Som standard har nya Visual Studio-projekt angetts till valfri processor.By default, new Visual Studio projects are set to Any CPU. Vi rekommenderar att du ställer in projektet på x64 så att det inte växlar till x86.We recommend that you set your project to x64 so it doesn't switch to x86. Ett projekt som är inställt på valfri processor kan enkelt växla till x86 om ett x86-endast beroende läggs till.A project set to Any CPU can easily switch to x86 if an x86-only dependency is added.
ServiceInterop.dll måste finnas i mappen som SDK-DLL-filen körs från.ServiceInterop.dll needs to be in the folder that the SDK DLL is being executed from. Detta bör endast vara en risk om du manuellt kopierar dll: er eller har anpassade Bygg-/distributions system.This should be a concern only if you manually copy DLLs or have custom build/deployment systems.

Aktivera skräp insamling på Server sidan (GC)Turn on server-side garbage collection (GC)

Att minska frekvensen skräp insamling kan i vissa fall hjälpa till.Reducing the frequency of garbage collection can help in some cases. I .NET anger du gcServer till true .In .NET, set gcServer to true.

Skala ut din klient arbets belastningScale out your client workload

Om du testar med höga data flödes nivåer (mer än 50 000 RU/s) kan klient programmet bli Flask halsen på grund av att datorn capping ut på processor-eller nätverks användning.If you're testing at high throughput levels (more than 50,000 RU/s), the client application could become the bottleneck due to the machine capping out on CPU or network utilization. Om du når den här punkten kan du fortsätta att skicka det Azure Cosmos DB kontot ytterligare genom att skala ut dina klient program över flera servrar.If you reach this point, you can continue to push the Azure Cosmos DB account further by scaling out your client applications across multiple servers.

Anteckning

Hög CPU-användning kan orsaka ökad latens och begär timeout-undantag.High CPU usage can cause increased latency and request timeout exceptions.

NätverkNetworking

Anslutnings princip: Använd direkt anslutnings lägeConnection policy: Use direct connection mode

.NET v2 SDK: s standard anslutnings läge är Gateway..NET V2 SDK default connection mode is gateway. Du konfigurerar anslutnings läget när DocumentClient instansen konstrueras med hjälp av- ConnectionPolicy parametern.You configure the connection mode during the construction of the DocumentClient instance by using the ConnectionPolicy parameter. Om du använder direkt läge måste du också ställa in med Protocol hjälp av ConnectionPolicy parametern.If you use direct mode, you need to also set the Protocol by using the ConnectionPolicy parameter. Mer information om olika anslutnings alternativ finns i artikeln anslutnings lägen .To learn more about different connectivity options, see the connectivity modes article.

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

Tillfällig portöverbelastningEphemeral port exhaustion

Om du ser en hög anslutnings volym eller hög port användning på dina instanser måste du först kontrol lera att klient instanserna är singleton.If you see a high connection volume or high port usage on your instances, first verify that your client instances are singletons. Med andra ord bör klient instanserna vara unika för programmets livs längd.In other words, the client instances should be unique for the lifetime of the application.

När den körs på TCP-protokollet optimerar klienten för svars tid genom att använda de långsamma anslutningarna i stället för HTTPS-protokollet, vilket avslutar anslutningarna efter 2 minuters inaktivitet.When running on the TCP protocol, the client optimizes for latency by using the long-lived connections as opposed to the HTTPS protocol, which terminates the connections after 2 minutes of inactivity.

I scenarier där du har sparse-åtkomst och om du upptäcker ett högre antal anslutningar jämfört med åtkomst till gateway-läge kan du:In scenarios where you have sparse access and if you notice a higher connection count when compared to the gateway mode access, you can:

  • Konfigurera egenskapen ConnectionPolicy. PortReuseMode till PrivatePortPool (gällande med framework-version>= 4.6.1 och .net core-version >= 2,0): med den här egenskapen kan SDK använda en liten pool av tillfälliga portar för olika Azure Cosmos DB mål slut punkter.Configure the ConnectionPolicy.PortReuseMode property to PrivatePortPool (effective with framework version>= 4.6.1 and .NET core version >= 2.0): This property allows the SDK to use a small pool of ephemeral ports for different Azure Cosmos DB destination endpoints.
  • Konfigurera egenskapen ConnectionPolicy. IdleConnectionTimeout måste vara större än eller lika med 10 minuter.Configure the ConnectionPolicy.IdleConnectionTimeout property must be greater than or equal to 10 minutes. De rekommenderade värdena är mellan 20 minuter och 24 timmar.The recommended values are between 20 minutes and 24 hours.

Anropa openAsync för att undvika start fördröjning för första begäranCall OpenAsync to avoid startup latency on first request

Som standard har den första begäran högre latens eftersom den måste hämta adress routningstabellen.By default, the first request has higher latency because it needs to fetch the address routing table. När du använder SDK v2anropar du OpenAsync() en gång under initieringen för att undvika den här start fördröjningen för den första begäran.When you use SDK V2, call OpenAsync() once during initialization to avoid this startup latency on the first request. Anropet ser ut så här: await client.OpenAsync();The call looks like: await client.OpenAsync();

Anteckning

OpenAsync genererar begär Anden för att hämta adress routningstabellen för alla behållare i kontot.OpenAsync will generate requests to obtain the address routing table for all the containers in the account. För konton som har många behållare men vars program har åtkomst till en delmängd av dem, OpenAsync genererar en onödig mängd trafik som gör initieringen långsam.For accounts that have many containers but whose application accesses a subset of them, OpenAsync would generate an unnecessary amount of traffic, which would make the initialization slow. Det OpenAsync kan vara bra att använda i det här scenariot eftersom det gör att program starten går långsamt.So using OpenAsync might not be useful in this scenario because it slows down application startup.

Samordna-klienter i samma Azure-region för prestanda.For performance, collocate clients in same Azure region

Placera eventuella program som anropar Azure Cosmos DB i samma region som Azure Cosmos DBs databasen när det är möjligt.When possible, place any applications that call Azure Cosmos DB in the same region as the Azure Cosmos DB database. Här är en ungefärlig jämförelse: anrop till Azure Cosmos DB inom samma region slutförs inom 1 ms till 2 MS, men fördröjningen mellan västra USA och östra kust är över 50 ms.Here's an approximate comparison: calls to Azure Cosmos DB within the same region complete within 1 ms to 2 ms, but the latency between the West and East coast of the US is more than 50 ms. Svars tiden kan variera från begäran till begäran, beroende på den väg som tas av begäran när den skickas från klienten till Azure Data Center-gränser.This latency can vary from request to request, depending on the route taken by the request as it passes from the client to the Azure datacenter boundary. Du kan få lägsta möjliga fördröjning genom att se till att det anropande programmet finns i samma Azure-region som den etablerade Azure Cosmos DB slut punkten.You can get the lowest possible latency by ensuring the calling application is located within the same Azure region as the provisioned Azure Cosmos DB endpoint. En lista över tillgängliga regioner finns i Azure-regioner.For a list of available regions, see Azure regions.

Azure Cosmos DB anslutnings princip

Öka antalet trådar/aktiviteter Increase the number of threads/tasks

Eftersom anrop till Azure Cosmos DB görs via nätverket kan du behöva variera graden av parallellitet för dina begär Anden så att klient programmet tillbringar minimal tid i väntan mellan begär Anden.Because calls to Azure Cosmos DB are made over the network, you might need to vary the degree of parallelism of your requests so that the client application spends minimal time waiting between requests. Om du till exempel använder ett parallellt .net-aktivitets bibliotekskapar du i ordningen på hundratals aktiviteter som läser från eller skriver till Azure Cosmos dB.For example, if you're using the .NET Task Parallel Library, create on the order of hundreds of tasks that read from or write to Azure Cosmos DB.

Aktivera accelererat nätverkEnable accelerated networking

För att minska svars tid och CPU-Darr rekommenderar vi att du aktiverar accelererat nätverk på virtuella klient datorer.To reduce latency and CPU jitter, we recommend that you enable accelerated networking on client virtual machines. Se skapa en virtuell Windows-dator med accelererat nätverk eller skapa en virtuell Linux-dator med accelererat nätverk.See Create a Windows virtual machine with accelerated networking or Create a Linux virtual machine with accelerated networking.

SDK-användningSDK usage

Installera den senaste SDK: nInstall the most recent SDK

Azure Cosmos DB SDK: er har ständigt förbättrats för att ge bästa möjliga prestanda.The Azure Cosmos DB SDKs are constantly being improved to provide the best performance. Se de Azure Cosmos DB SDK -sidorna för att fastställa de senaste SDK: er och gransknings förbättringarna.See the Azure Cosmos DB SDK pages to determine the most recent SDK and review improvements.

Använd en singleton Azure Cosmos DB-klient för programmets livs längdUse a singleton Azure Cosmos DB client for the lifetime of your application

Varje DocumentClient instans är tråd säker och utför effektiv anslutnings hantering och cachelagring av adresser när de körs i direkt läge.Each DocumentClient instance is thread-safe and performs efficient connection management and address caching when operating in direct mode. För att möjliggöra effektiv anslutnings hantering och bättre prestanda för SDK-klienten, rekommenderar vi att du använder en enda instans per AppDomain för programmets livs längd.To allow efficient connection management and better SDK client performance, we recommend that you use a single instance per AppDomain for the lifetime of the application.

Öka System.Net MaxConnections per värd när du använder Gateway-lägeIncrease System.Net MaxConnections per host when using gateway mode

Azure Cosmos DB begär Anden görs via HTTPS/REST när du använder Gateway-läge.Azure Cosmos DB requests are made over HTTPS/REST when you use gateway mode. De är underkastade standard anslutnings gränsen per värdnamn eller IP-adress.They're subjected to the default connection limit per hostname or IP address. Du kan behöva ange MaxConnections ett högre värde (100 till 1 000) så att klient biblioteket kan använda flera samtidiga anslutningar till Azure Cosmos dB.You might need to set MaxConnections to a higher value (100 to 1,000) so the client library can use multiple simultaneous connections to Azure Cosmos DB. I .NET SDK-1.8.0 och senare är standardvärdet för ServicePointManager. DefaultConnectionLimit 50.In .NET SDK 1.8.0 and later, the default value for ServicePointManager.DefaultConnectionLimit is 50. Om du vill ändra värdet kan du ange Documents. client. ConnectionPolicy. MaxConnectionLimit till ett högre värde.To change the value, you can set Documents.Client.ConnectionPolicy.MaxConnectionLimit to a higher value.

Justera parallella frågor för partitionerade samlingarTune parallel queries for partitioned collections

SQL .NET SDK-1.9.0 och senare stöder parallella frågor som gör att du kan fråga en partitionerad samling parallellt.SQL .NET SDK 1.9.0 and later support parallel queries, which enable you to query a partitioned collection in parallel. Mer information finns i kod exempel för att arbeta med SDK: er.For more information, see code samples related to working with the SDKs. Parallella frågor är utformade för att ge bättre svars tid och data flöde än deras serie motsvarighet.Parallel queries are designed to provide better query latency and throughput than their serial counterpart. Parallella frågor ger två parametrar som du kan justera för att passa dina behov:Parallel queries provide two parameters that you can tune to fit your requirements:

  • MaxDegreeOfParallelism kontrollerar det högsta antalet partitioner som kan frågas parallellt.MaxDegreeOfParallelism controls the maximum number of partitions that can be queried in parallel.
  • MaxBufferedItemCount styr antalet i förväg hämtade resultat.MaxBufferedItemCount controls the number of pre-fetched results.

Justera graden av parallellitetTuning degree of parallelism

Parallell fråga fungerar genom att fråga flera partitioner parallellt.Parallel query works by querying multiple partitions in parallel. Men data från en enskild partition hämtas seriellt i förhållande till frågan.But data from an individual partition is fetched serially with respect to the query. Inställningen MaxDegreeOfParallelism i SDK v2 till antalet partitioner har den bästa möjligheten att nå den mest utförda frågan, förutsatt att alla andra system villkor är desamma.Setting MaxDegreeOfParallelism in SDK V2 to the number of partitions has the best chance of achieving the most performant query, provided all other system conditions remain the same. Om du inte vet antalet partitioner kan du ange graden av parallellitet till ett högt tal.If you don't know the number of partitions, you can set the degree of parallelism to a high number. Systemet väljer det lägsta (antal partitioner, indata från användaren) som graden av parallellitet.The system will choose the minimum (number of partitions, user provided input) as the degree of parallelism.

Parallella frågor ger flest fördelar om data är jämnt fördelade över alla partitioner med avseende på frågan.Parallel queries produce the most benefit if the data is evenly distributed across all partitions with respect to the query. Om den partitionerade samlingen är partitionerad, så att alla eller de flesta data som returneras av en fråga är koncentrerade i några partitioner (en partition är det värsta fallet), kommer dessa partitioner att översätta prestandan hos frågan.If the partitioned collection is partitioned so that all or most of the data returned by a query is concentrated in a few partitions (one partition is the worst case), those partitions will bottleneck the performance of the query.

Justera MaxBufferedItemCountTuning MaxBufferedItemCount

Parallell fråga är utformad för att hämta resultat när den aktuella gruppen med resultat bearbetas av klienten.Parallel query is designed to pre-fetch results while the current batch of results is being processed by the client. Den här för hämtningen hjälper till att förbättra den övergripande svars tiden för en fråga.This pre-fetching helps improve the overall latency of a query. MaxBufferedItemCountParametern begränsar antalet i förväg hämtade resultat.The MaxBufferedItemCount parameter limits the number of pre-fetched results. Ange MaxBufferedItemCount till det förväntade antalet returnerade resultat (eller ett högre antal) för att tillåta att frågan tar emot den maximala fördelen med för hämtning.Set MaxBufferedItemCount to the expected number of results returned (or a higher number) to allow the query to receive the maximum benefit from pre-fetching.

För hämtning fungerar på samma sätt oavsett graden av parallellitet och det finns en enda buffert för data från alla partitioner.Pre-fetching works the same way regardless of the degree of parallelism, and there's a single buffer for the data from all partitions.

Implementera backoff med RetryAfter-intervallImplement backoff at RetryAfter intervals

Under prestanda testningen bör du öka belastningen tills en låg frekvens av begär Anden begränsas.During performance testing, you should increase load until a small rate of requests are throttled. Om begär Anden begränsas bör klient programmet stängas av vid begränsningen för det Server-angivna återförsöksintervallet.If requests are throttled, the client application should back off on throttle for the server-specified retry interval. Att respektera backoff garanterar att du ägnar en liten stund åt att vänta mellan återförsök.Respecting the backoff ensures you spend a minimal amount of time waiting between retries.

Princip support för återförsök ingår i dessa SDK: er:Retry policy support is included in these SDKs:

Mer information finns i RetryAfter.For more information, see RetryAfter.

I version 1,19 och senare av .NET SDK finns det en mekanism för att logga ytterligare diagnostikinformation och felsöka latens problem, som du ser i följande exempel.In version 1.19 and later of the .NET SDK, there's a mechanism for logging additional diagnostic information and troubleshooting latency issues, as shown in the following sample. Du kan logga den diagnostiska strängen för förfrågningar som har en högre Läs fördröjning.You can log the diagnostic string for requests that have a higher read latency. Den hämtade diagnostikloggar hjälper dig att förstå hur många gånger du fick 429 fel för en specifik begäran.The captured diagnostic string will help you understand how many times you received 429 errors for a given request.

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

Cachelagra dokument-URI: er för lägre Läs fördröjningCache document URIs for lower read latency

Cachelagra dokument-URI: er när det är möjligt för bästa möjliga Läs prestanda.Cache document URIs whenever possible for the best read performance. Du måste definiera logik för att cachelagra resurs-ID när du skapar en resurs.You need to define logic to cache the resource ID when you create a resource. Sökningar baserat på resurs-ID: n är snabbare än namnbaserade sökningar, så cachelagring av dessa värden ger bättre prestanda.Lookups based on resource IDs are faster than name-based lookups, so caching these values improves performance.

Justera sid storleken för frågor/läsa feeds för bättre prestandaTune the page size for queries/read feeds for better performance

När du gör en Mass läsning av dokument med hjälp av funktionen för att läsa feeds (till exempel ReadDocumentFeedAsync ) eller när du skickar en SQL-fråga, returneras resultatet i ett segmenterat läge om resultat mängden är för stor.When you do a bulk read of documents by using read feed functionality (for example, ReadDocumentFeedAsync) or when you issue a SQL query, the results are returned in a segmented fashion if the result set is too large. Som standard returneras resultaten i segment om 100 objekt eller 1 MB, beroende på vilken gräns som nåtts först.By default, results are returned in chunks of 100 items or 1 MB, whichever limit is hit first.

För att minska antalet nätverks fördröjningar som krävs för att hämta alla tillämpliga resultat kan du öka sid storleken genom att använda x-MS-Max-item-Count för att begära så många som 1 000 sidhuvud.To reduce the number of network round trips required to retrieve all applicable results, you can increase the page size by using x-ms-max-item-count to request as many as 1,000 headers. Om du bara behöver visa några få resultat, till exempel om ditt användar gränssnitt eller ditt program-API bara returnerar 10 resultat i taget, kan du också minska sid storleken till 10 för att minska data flödet som används för läsningar och frågor.When you need to display only a few results, for example, if your user interface or application API returns only 10 results at a time, you can also decrease the page size to 10 to reduce the throughput consumed for reads and queries.

Anteckning

maxItemCountEgenskapen bör inte användas bara för sid brytning.The maxItemCount property shouldn't be used just for pagination. Den används huvudsakligen för att förbättra prestandan för frågor genom att minska det maximala antalet objekt som returneras på en enda sida.Its main use is to improve the performance of queries by reducing the maximum number of items returned in a single page.

Du kan också ange sid storlek med hjälp av tillgängliga Azure Cosmos DB SDK: er.You can also set the page size by using the available Azure Cosmos DB SDKs. Med egenskapen MaxItemCount i FeedOptions kan du ange det maximala antalet objekt som ska returneras i uppräknings åtgärden.The MaxItemCount property in FeedOptions allows you to set the maximum number of items to be returned in the enumeration operation. När maxItemCount är inställt på-1 hittar SDK: n automatiskt det optimala värdet, beroende på dokumentets storlek.When maxItemCount is set to -1, the SDK automatically finds the optimal value, depending on the document size. Exempel:For example:

IQueryable<dynamic> authorResults = client.CreateDocumentQuery(documentCollection.SelfLink, "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'", new FeedOptions { MaxItemCount = 1000 });

När en fråga körs skickas resulterande data i ett TCP-paket.When a query is executed, the resulting data is sent within a TCP packet. Om du anger för lågt värde för värdet maxItemCount är antalet resor som krävs för att skicka data i TCP-paketet hög, vilket påverkar prestanda.If you specify too low a value for maxItemCount, the number of trips required to send the data within the TCP packet is high, which affects performance. Så om du inte är säker på vilket värde som ska anges för maxItemCount egenskapen, är det bäst att ange det till-1 och låta SDK: n välja standardvärdet.So if you're not sure what value to set for the maxItemCount property, it's best to set it to -1 and let the SDK choose the default value.

Öka antalet trådar/aktiviteterIncrease the number of threads/tasks

Se öka antalet trådar/aktiviteter i avsnittet nätverk i den här artikeln.See Increase the number of threads/tasks in the networking section of this article.

IndexeringsprincipIndexing policy

Utesluta sökvägar som inte används från indexering för att få snabbare skrivningExclude unused paths from indexing for faster writes

Med Azure Cosmos DB indexerings principen kan du också ange vilka dokument Sök vägar som ska ingå i eller undantas från indexering genom att använda indexerings Sök vägar (IndexingPolicy. IncludedPaths och IndexingPolicy. ExcludedPaths).The Azure Cosmos DB indexing policy also allows you to specify which document paths to include in or exclude from indexing by using indexing paths (IndexingPolicy.IncludedPaths and IndexingPolicy.ExcludedPaths). Indexering av sökvägar kan förbättra skriv prestanda och minska index lagringen för scenarier där fråge mönstren är kända i förväg.Indexing paths can improve write performance and reduce index storage for scenarios in which the query patterns are known beforehand. Detta beror på att indexerings kostnader korrelerar direkt med antalet unika sökvägar.This is because indexing costs correlate directly to the number of unique paths indexed. Den här koden visar till exempel hur du undantar en hel del av dokumenten (ett under träd) från indexering med hjälp av jokertecknet "*":For example, this code shows how to exclude an entire section of the documents (a subtree) from indexing by using the "*" wildcard:

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

Mer information finns i Azure Cosmos DB indexerings principer.For more information, see Azure Cosmos DB indexing policies.

KapacitetThroughput

Mått och justering för lägre enheter för programbegäran/andra användningMeasure and tune for lower Request Units/second usage

Azure Cosmos DB erbjuder en omfattande uppsättning databas åtgärder.Azure Cosmos DB offers a rich set of database operations. Dessa åtgärder omfattar relationella och hierarkiska frågor med UDF: er, lagrade procedurer och utlösare, allt som körs på dokumenten i en databas samling.These operations include relational and hierarchical queries with UDFs, stored procedures, and triggers, all operating on the documents within a database collection. Kostnaden som är kopplad till var och en av dessa åtgärder varierar beroende på processor, IO och minne som krävs för att slutföra åtgärden.The cost associated with each of these operations varies depending on the CPU, IO, and memory required to complete the operation. I stället för att tänka på och hantera maskin varu resurser kan du tänka på en enhet för begäran (RU) som ett enda mått för de resurser som krävs för att utföra olika databas åtgärder och betjäna en programbegäran.Instead of thinking about and managing hardware resources, you can think of a Request Unit (RU) as a single measure for the resources required to perform various database operations and service an application request.

Data flödet har allokerats baserat på antalet enheter för programbegäran som angetts för varje behållare.Throughput is provisioned based on the number of Request Units set for each container. Den begärda enhets förbrukningen utvärderas som en taxa per sekund.Request Unit consumption is evaluated as a rate per second. Program som överskrider den allokerade enhets hastigheten för deras behållare är begränsade tills hastigheten sjunker under den allokerade nivån för behållaren.Applications that exceed the provisioned Request Unit rate for their container are limited until the rate drops below the provisioned level for the container. Om ditt program kräver en högre data flödes nivå kan du öka data flödet genom att tillhandahålla ytterligare enheter för programbegäran.If your application requires a higher level of throughput, you can increase your throughput by provisioning additional Request Units.

En frågas komplexitet påverkar hur många enheter för programbegäran som används för en åtgärd.The complexity of a query affects how many Request Units are consumed for an operation. Antalet predikat, typen av predikat, antalet UDF: er och storleken på käll data uppsättningen påverkar hela kostnaden för frågor.The number of predicates, the nature of the predicates, the number of UDFs, and the size of the source dataset all influence the cost of query operations.

Om du vill mäta omkostnaderna för en åtgärd (skapa, uppdatera eller ta bort) kan du kontrol lera huvudet x-MS-Request-avgift (eller motsvarande RequestCharge egenskap i ResourceResponse\<T> eller FeedResponse\<T> i .NET SDK) för att mäta antalet enheter för programbegäran som används av åtgärderna:To measure the overhead of any operation (create, update, or delete), inspect the x-ms-request-charge header (or the equivalent RequestCharge property in ResourceResponse\<T> or FeedResponse\<T> in the .NET SDK) to measure the number of Request Units consumed by the operations:

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

Begär ande avgiften som returnerades i den här rubriken är en bråkdel av ditt allokerade data flöde (dvs. 2 000 ru: er/sekund).The request charge returned in this header is a fraction of your provisioned throughput (that is, 2,000 RUs / second). Om exempelvis föregående fråga returnerar 1 000 1 KB-dokument, är kostnaden för åtgärden 1 000.For example, if the preceding query returns 1,000 1-KB documents, the cost of the operation is 1,000. Det innebär att servern i en sekund endast besitter två sådana begär Anden innan den hastighet som senare begärs begränsas.So, within one second, the server honors only two such requests before rate limiting later requests. Mer information finns i enheter för programbegäran och Kalkylatorn för begär andeenheter.For more information, see Request Units and the Request Unit calculator.

Hastighets begränsning/begär ande frekvens för storHandle rate limiting/request rate too large

När en klient försöker överskrida det reserverade data flödet för ett konto, finns det ingen prestanda försämring på servern och ingen användning av data flödes kapaciteten utöver den reserverade nivån.When a client attempts to exceed the reserved throughput for an account, there's no performance degradation at the server and no use of throughput capacity beyond the reserved level. Servern kommer att förebyggande syfte avsluta begäran med RequestRateTooLarge (HTTP-status kod 429).The server will preemptively end the request with RequestRateTooLarge (HTTP status code 429). Det returnerar ett x-MS-retry-efter-MS- huvud som anger hur lång tid i millisekunder som användaren måste vänta innan begäran försöker igen.It will return an x-ms-retry-after-ms header that indicates the amount of time, in milliseconds, that the user must wait before attempting the request again.

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

SDK: erna fångar alla implicita dessa svar, med den server-angivna återförsöket-efter-rubriken och gör om begäran.The SDKs all implicitly catch this response, respect the server-specified retry-after header, and retry the request. Om ditt konto inte kan nås samtidigt av flera klienter kommer nästa försök att lyckas.Unless your account is being accessed concurrently by multiple clients, the next retry will succeed.

Om du har mer än en klient ackumulerad på ett konsekvent sätt över begär ande frekvensen är standard antalet nya försök som för närvarande är 9 internt av klienten inte tillräckligt.If you have more than one client cumulatively operating consistently above the request rate, the default retry count currently set to 9 internally by the client might not suffice. I det här fallet genererar klienten en DocumentClientException med status kod 429 i programmet.In this case, the client throws a DocumentClientException with status code 429 to the application.

Du kan ändra standard antalet nya försök genom att ställa in RetryOptionsConnectionPolicy instansen.You can change the default retry count by setting the RetryOptions on the ConnectionPolicy instance. Som standard returneras DocumentClientException med status kod 429 efter en ackumulerad vänte tid på 30 sekunder om begäran fortsätter att köras över begär ande frekvensen.By default, the DocumentClientException with status code 429 is returned after a cumulative wait time of 30 seconds if the request continues to operate above the request rate. Det här felet returnerar även när det aktuella antalet nya försök är mindre än det högsta antalet tillåtna försök, om det aktuella värdet är standardvärdet 9 eller ett användardefinierat värde.This error returns even when the current retry count is less than the maximum retry count, whether the current value is the default of 9 or a user-defined value.

Det automatiska återförsöket hjälper till att förbättra återhämtning och användbarhet för de flesta program.The automated retry behavior helps improve resiliency and usability for most applications. Men det kanske inte är det bästa beteendet när du utför prestandatest, särskilt när du mäter svars tid.But it might not be the best behavior when you're doing performance benchmarks, especially when you're measuring latency. Den klientbaserade svars tiden kommer att inaktive ras om experimentet träffar Server begränsningen och gör att klient-SDK: n kan försöka tyst igen.The client-observed latency will spike if the experiment hits the server throttle and causes the client SDK to silently retry. För att undvika fördröjningar vid prestanda experiment kan du mäta den avgift som returneras av varje åtgärd och se till att förfrågningarna fungerar under den reserverade begär ande frekvensen.To avoid latency spikes during performance experiments, measure the charge returned by each operation and ensure that requests are operating below the reserved request rate. Mer information finns i enheter för programbegäran.For more information, see Request Units.

För högre data flöde kan du utforma för mindre dokumentFor higher throughput, design for smaller documents

Avgiften för begäran (det vill säga bearbetnings kostnaden för bearbetning) för en specifik åtgärd motsvarar direkt till dokumentets storlek.The request charge (that is, the request-processing cost) of a given operation correlates directly to the size of the document. Åtgärder i stora dokument kostar mer än åtgärder på små dokument.Operations on large documents cost more than operations on small documents.

Nästa stegNext steps

Ett exempel program som används för att utvärdera Azure Cosmos DB för scenarier med hög prestanda på ett fåtal klient datorer finns i prestanda-och skalnings testning med Azure Cosmos DB.For a sample application that's used to evaluate Azure Cosmos DB for high-performance scenarios on a few client machines, see Performance and scale testing with Azure Cosmos DB.

Mer information om hur du utformar programmet för skalning och höga prestanda finns i partitionering och skalning i Azure Cosmos DB.To learn more about designing your application for scale and high performance, see Partitioning and scaling in Azure Cosmos DB.