Tips voor betere prestaties van Azure Cosmos DB en .NET SDK v2

VAN TOEPASSING OP: SQL-API

Azure Cosmos DB is een snelle en flexibele gedistribueerde database die naadloos kan worden geschaald met gegarandeerde latentie en doorvoer. 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. Maar omdat Azure Cosmos DB via netwerkoproepen wordt gebruikt, zijn er optimalisaties aan de clientzijde die u kunt maken om piekprestaties te bereiken wanneer u de SQL .NET SDK gebruikt.

Als u de prestaties van uw database wilt verbeteren, kunt u de volgende opties overwegen:

Upgraden naar de .NET V3 SDK

De .NET v3 SDK wordt uitgebracht. Als u de .NET v3 SDK gebruikt, bekijkt u de .NET v3-prestatiehandleiding voor de volgende informatie:

• De standaardinstelling is Direct TCP-modus
• Ondersteuning voor Stream-API
• Ondersteuning voor aangepaste serialisatie voor het toestaan System.Text.JSON-gebruik
• Geïntegreerde batch- en bulkondersteuning

Hostingaanbevelingen

Gebruik voor query-intensieve workloads Windows 64-bits in plaats van Linux of Windows 32-bits hostverwerking

We raden u Windows 64-bits hostverwerking te maken voor betere prestaties. De SQL SDK bevat een systeemeigen ServiceInterop.dll om query's lokaal te parseren en te optimaliseren. ServiceInterop.dll wordt alleen ondersteund op het Windows x64-platform. Voor Linux en andere niet-ondersteunde platforms waar ServiceInterop.dll beschikbaar is, wordt een extra netwerkaanroep naar de gateway uitgevoerd om de geoptimaliseerde query op te halen. De volgende typen toepassingen maken standaard gebruik van 32-bits hostverwerking. Als u de hostverwerking wilt wijzigen in 64-bits verwerking, volgt u deze stappen op basis van het type van uw toepassing:

• Voor uitvoerbare toepassingen kunt u de verwerking van de host wijzigen door het platformdoel in te stellen op x64 in het venster Project Properties op het tabblad Build.

• Voor op VSTest gebaseerde testprojecten kunt u hostverwerking wijzigen door Test > Test Instellingen Default Processor Architecture as > X64 te selecteren in het menu Visual Studio Test.

• Voor lokaal geïmplementeerde ASP.NET webtoepassingen kunt u de verwerking van de host wijzigen door Use the 64-bits version of IIS Express for websites and projects onder Tools > Options > Projects and Solutions Web Projects te > selecteren.

• Voor ASP.NET webtoepassingen die zijn geïmplementeerd in Azure, kunt u de verwerking van de host wijzigen door het 64-bits platform te selecteren in Toepassingsinstellingen in de Azure Portal.

Garbage collection (GC) aan de serverzijde inroepen

Het verminderen van de frequentie van garbage collection kan in sommige gevallen helpen. Stel in .NET gcServer in op true .

De workload van uw client uitschalen

Als u test op een hoog doorvoerniveau (meer dan 50.000 RU/s), kan de clienttoepassing het knelpunt worden omdat de machine te veel CPU- of netwerkgebruik heeft. Als u dit punt bereikt, kunt u het Azure Cosmos DB blijven pushen door uw clienttoepassingen uit te schalen op meerdere servers.

Networking

Verbindingsbeleid: De modus voor directe verbinding gebruiken

De standaardverbindingsmodus voor .NET V2 SDK is gateway. U configureert de verbindingsmodus tijdens het bouwen van het DocumentClient exemplaar met behulp van de parameter ConnectionPolicy . Als u de directe modus gebruikt, moet u ook de instellen Protocol met behulp van de parameter ConnectionPolicy . Zie het artikel connectiviteitsmodi voor meer informatie over verschillende connectiviteitsopties.

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

Tijdelijke poortuitputting

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

Wanneer de client wordt uitgevoerd op het TCP-protocol, optimaliseert deze voor latentie door gebruik te maken van de langdurige verbindingen in plaats van het HTTPS-protocol, waardoor de verbindingen na 2 minuten inactiviteit worden beëindigd.

In scenario's met verspreide toegang en als u een hoger aantal verbindingen ziet in vergelijking met de toegang tot de gatewaymodus, kunt u het volgende doen:

• Configureer de eigenschap ConnectionPolicy.PortReuseMode naar (van kracht met PrivatePortPool frameworkversie>= 4.6.1 en .NET Core-versie >= 2.0): met deze eigenschap kan de SDK een kleine pool tijdelijke poorten gebruiken voor verschillende Azure Cosmos DB-eindpunten.
• Configureer de eigenschap ConnectionPolicy.IdleConnectionTimeout moet groter zijn dan of gelijk zijn aan 10 minuten. De aanbevolen waarden liggen tussen 20 minuten en 24 uur.

OpenAsync aanroepen om opstartlatentie bij eerste aanvraag te voorkomen

De eerste aanvraag heeft standaard een hogere latentie omdat deze de adresrouteringstabel moet ophalen. Wanneer u SDK V2 gebruikt,roept u eenmaal aan tijdens de initialisatie om OpenAsync() deze opstartlatentie bij de eerste aanvraag te voorkomen. De aanroep ziet er als volgende uit: await client.OpenAsync();

Voor prestaties collocate clients in dezelfde Azure-regio

Plaats indien mogelijk alle toepassingen die aanroepen Azure Cosmos DB in dezelfde regio als de Azure Cosmos DB database. Hier is een geschatte vergelijking: aanroepen naar Azure Cosmos DB binnen dezelfde regio worden binnen 1 ms tot 2 ms voltooid, maar de latentie tussen de oostkust en de oostkust van de VS is meer dan 50 ms. Deze latentie kan per aanvraag verschillen, afhankelijk van de route die door de aanvraag wordt genomen wanneer deze van de client naar de grens van het Azure-datacenter wordt overgebracht. U kunt de laagst mogelijke latentie krijgen door ervoor te zorgen dat de aanroepende toepassing zich binnen dezelfde Azure-regio bevindt als het Azure Cosmos DB eindpunt. Zie Azure-regio's voor een lijst met beschikbare regio's.

Het aantal threads/taken verhogen

Omdat aanroepen Azure Cosmos DB via het netwerk worden gedaan, moet u mogelijk de mate van parallelle uitvoering van uw aanvragen variëren, zodat de clienttoepassing zo min mogelijk tijd hoeft te wachten tussen aanvragen. Als u bijvoorbeeld de parallelle bibliotheek voor .NET-taken gebruikt, maakt u in de volgorde van honderden taken die lezen van of schrijven naar Azure Cosmos DB.

Versneld netwerken inschakelen

Om latentie en CPU-jitter te verminderen, raden we u aan versneld netwerken in te stellen op virtuele clientmachines. Zie Create a Windows virtual machine with accelerated networking (Een virtuele Linux-machine met versneld netwerken maken) of Create a Linux virtual machine with accelerated networking (Een virtuele Linux-machine met versneld netwerken maken).

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-pagina's om de meest recente SDK te bepalen en verbeteringen te bekijken.

Gebruik een singleton Azure Cosmos DB client voor de levensduur van uw toepassing

Elk DocumentClient exemplaar is thread-veilig en voert efficiënt verbindingsbeheer en adres-caching uit bij gebruik in de directe modus. Om efficiënt verbindingsbeheer en betere SDK-clientprestaties mogelijk te maken, raden we u aan één exemplaar per te gebruiken voor de AppDomain levensduur van de toepassing.

Blokkerende aanroepen voorkomen

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 blokkerende aanroepen. In plaats van te wachten op een langlopende synchrone taak, kan de thread op een andere aanvraag werken.

Een veelvoorkomende prestatieprobleem in apps die de Cosmos DB SDK gebruiken, is het blokkeren van aanroepen die asynchroon kunnen zijn. Veel synchrone blokkeringsaanroepen leiden tot het uitsterden van de threadpool en de reactietijden verslechteren.

Niet doen:

• Blokkeer asynchrone uitvoering door Task.Wait of Task.Result aan te roepen.
• Gebruik Task.Run om een synchrone API asynchroon te maken.
• Vergrendelingen verkrijgen in algemene codepaden. Cosmos DB .NET SDK presteert het beste wanneer u code parallel wilt uitvoeren.
• Roep Task.Run aan en wacht er onmiddellijk op. ASP.NET Core app-code al wordt uitgevoerd op normale threadpoolthreads, resulteert het aanroepen van Task.Run alleen in extra onnodige threadgroepplanning. Zelfs als de geplande code een thread blokkeert, voorkomt Task.Run dat niet.
• Gebruik ToList() niet waarvoor blokkeringsaanroepen worden gebruikt om de DocumentClient.CreateDocumentQuery(...) query synchroon leeg te maken. Gebruik AsDocumentQuery() om de query asynchroon te verwijderen.

Doen:

• Roep de Cosmos DB .NET-API's asynchroon aan.
• De hele aanroepstack is asynchroon om te profiteren van async/await-patronen.

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

De System.Net MaxConnections per host verhogen bij gebruik van de gatewaymodus

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

Parallelle query's voor gepartities afstemmen

SQL .NET SDK 1.9.0 en hoger ondersteunen parallelle query's, waarmee u parallel een query kunt uitvoeren op een gepartitiese verzameling. Zie codevoorbeelden met betrekking tot het werken met de SDK's voor meer informatie. Parallelle query's zijn ontworpen om een betere querylatentie en doorvoer te bieden dan hun seriële tegenhanger. Parallelle query's bieden twee parameters die u kunt afstemmen om aan uw vereisten te voldoen:

• MaxDegreeOfParallelism bepaalt het maximum aantal partities dat parallel kan worden opgevraagd.
• MaxBufferedItemCount bepaalt het aantal vooraf opgehaalde resultaten.

De mate van parallellisme afstemmen

Parallelle query werkt door meerdere partities parallel op te vragen. Maar gegevens van een afzonderlijke partitie worden serieel opgehaald met betrekking tot de query. Als MaxDegreeOfParallelism u in SDK V2 instelt op het aantal partities, is de beste kans op het bereiken van de best presterende query, mits alle andere systeemvoorwaarden hetzelfde blijven. Als u het aantal partities niet weet, kunt u de mate van parallellisme instellen op een groot aantal. Het systeem kiest het minimum (aantal partities, door de gebruiker opgegeven invoer) als de mate van parallellelisme.

Parallelle query's leveren het meeste voordeel op als de gegevens gelijkmatig worden verdeeld over alle partities met betrekking tot de query. Als de gepartitiese verzameling zo is gepartitiefd dat alle of de meeste gegevens die door een query worden geretourneerd, zijn gericht op een paar partities (één partitie is het ergste geval), knelpunt deze partities de prestaties van de query.

MaxBufferedItemCount afstemmen

Parallelle query is ontworpen om vooraf resultaten op te halen terwijl de huidige batch met resultaten wordt verwerkt door de client. Dit vooraf ophalen helpt de algehele latentie van een query te verbeteren. De MaxBufferedItemCount parameter beperkt het aantal vooraf opgehaalde resultaten. Stel MaxBufferedItemCount in op het verwachte aantal geretourneerde resultaten (of een hoger aantal) zodat de query maximaal voordeel kan halen uit vooraf ophalen.

Vooraf ophalen werkt op dezelfde manier, ongeacht de mate van parallellisme, en er is één buffer voor de gegevens van alle partities.

Implementatie van back-off bij intervallen van RetryAfter

Tijdens het testen van de prestaties moet u de belasting verhogen totdat een klein aantal aanvragen wordt beperkt. Als aanvragen worden beperkt, moet de clienttoepassing bij vertraging een back-off maken voor het door de server opgegeven interval voor opnieuw proberen. Als u de back-off respecteert, zorgt u ervoor dat u zo min mogelijk tijd moet wachten tussen nieuwe keren dat er wordt gewacht.

Ondersteuning voor beleid voor opnieuw proberen is opgenomen in deze SDK's:

• Versie 1.8.0 en hoger van de .NET SDK voor SQL en de Java-SDK voor SQL
• Versie 1.9.0 en hoger van de Node.js SDK voor SQL en de Python SDK voor SQL
• Alle ondersteunde versies van de .NET Core SDK's

Zie RetryAftervoor meer informatie.

In versie 1.19 en hoger van de .NET SDK is er een mechanisme voor het vastleggen van aanvullende diagnostische gegevens en het oplossen van latentieproblemen, zoals wordt weergegeven in het volgende voorbeeld. U kunt de diagnostische tekenreeks voor aanvragen met een hogere leeslatentie aanmelden. De vastgelegde diagnostische tekenreeks helpt u te begrijpen hoe vaak u 429-fouten hebt ontvangen voor een bepaalde aanvraag.

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

Document-URI's in cache opslaan voor een lagere leeslatentie

Cache document-URI's indien mogelijk voor de beste leesprestaties. U moet logica definiëren om de resource-id in de cache op te nemen wanneer u een resource maakt. Zoekups op basis van resource-ID's zijn sneller dan op naam gebaseerde zoekups, dus het in deaching van deze waarden verbetert de prestaties.

Het paginaformaat voor query's/leesfeeds afstemmen voor betere prestaties

Wanneer u documenten bulksgewijs leest met behulp van de functionaliteit van de leesfeed (bijvoorbeeld ) of wanneer u een SQL-query uitvoert, worden de resultaten gesegmenteerd geretourneerd als de resultatenset te groot ReadDocumentFeedAsync is. Standaard worden resultaten geretourneerd in segmenten van 100 items of 1 MB, welke limiet het eerst wordt bereikt.

Als u het aantal netwerkrondes wilt verminderen dat nodig is om alle toepasselijke resultaten op te halen, kunt u de paginagrootte vergroten door x-ms-max-item-count te gebruiken om maximaal 1000 headers aan te vragen. Als u bijvoorbeeld slechts enkele resultaten wilt weergeven als uw gebruikersinterface of toepassings-API slechts 10 resultaten tegelijk retourneert, kunt u de paginagrootte ook verkleinen tot 10 om de doorvoer te verminderen die wordt gebruikt voor lees- en query's.

U kunt ook het paginaformaat instellen met behulp van de beschikbare Azure Cosmos DB SDK's. Met de eigenschap MaxItemCount in kunt u het maximum aantal items instellen dat moet worden geretourneerd FeedOptions in de optellingsbewerking. Wanneer maxItemCount is ingesteld op -1, vindt de SDK automatisch de optimale waarde, afhankelijk van de documentgrootte. Bijvoorbeeld:

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

Wanneer een query wordt uitgevoerd, worden de resulterende gegevens verzonden binnen een TCP-pakket. Als u een te lage waarde opgeeft voor , is het aantal ritten dat nodig is om de gegevens binnen het TCP-pakket te verzenden hoog, wat van invloed maxItemCount is op de prestaties. Dus als u niet zeker weet welke waarde u moet instellen voor de eigenschap, kunt u deze het beste instellen op -1 en de maxItemCount SDK de standaardwaarde laten kiezen.

Het aantal threads/taken verhogen

Zie Increase the number of threads/tasks (Het aantal threads/taken verhogen) in de sectie netwerken van dit artikel.

Indexeringsbeleid

Niet-gebruikte paden uitsluiten van indexering voor snellere schrijfbewerkingen

Met Azure Cosmos DB indexeringsbeleid kunt u ook opgeven welke documentpaden moeten worden opgenomen in of uitgesloten van indexering met behulp van indexeringspaden (IndexingPolicy.IncludedPaths en IndexingPolicy.ExcludedPaths). Indexeringspaden kunnen de schrijfprestaties verbeteren en de 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. Deze code laat bijvoorbeeld zien hoe u een volledige sectie van de documenten (een subteken) uitsluit van indexering met behulp van het jokerteken *:

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

Zie indexeringsbeleid voor Azure Cosmos DB meer informatie.

Doorvoer

Meten en afstemmen voor lagere aanvraageenheden/tweede gebruik

Azure Cosmos DB biedt een uitgebreide set databasebewerkingen. Deze bewerkingen omvatten relationele en hiërarchische query's met UF's, opgeslagen procedures en triggers, die allemaal worden uitgevoerd op de documenten in een databaseverzameling. De kosten voor elk van deze bewerkingen variëren, afhankelijk van de CPU, I/O en het geheugen die nodig zijn om de bewerking te voltooien. In plaats van na te denken over hardwarebronnen en deze te beheren, kunt u een aanvraageenheid (RU) zien als een enkele meting voor de resources die nodig zijn om verschillende databasebewerkingen uit te voeren en een toepassingsaanvraag te verwerken.

De doorvoer wordt ingericht op basis van het aantal aanvraageenheden dat is ingesteld voor elke container. Het verbruik van aanvraageenheden wordt geëvalueerd als een tarief per seconde. Toepassingen die het inrichten van aanvraageenheden voor hun container overschrijden, worden beperkt totdat de snelheid onder het inrichtende niveau voor de container zakt. Als uw toepassing een hoger doorvoerniveau vereist, kunt u uw doorvoer verhogen door extra aanvraageenheden in terichten.

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

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

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

De aanvraagkosten die in deze header worden geretourneerd, zijn een fractie van de inrichtende doorvoer (2000 AANVRAAG/seconde). Als de voorgaande query bijvoorbeeld 1000 documenten van 1 kB retourneert, zijn de kosten van de bewerking 1000. Dus binnen één seconde respecteert de server slechts twee dergelijke aanvragen voordat de snelheid van latere aanvragen wordt beperkt. Zie Aanvraageenheden en de calculator voor aanvraageenheden voor meer informatie.

Snelheidsbeperking verwerken/aanvraagsnelheid is te hoog

Wanneer een client de gereserveerde doorvoer voor een account probeert te overschrijden, is er geen prestatievermindering op de server en wordt er geen gebruik gemaakt van de doorvoercapaciteit buiten het gereserveerde niveau. De server zal de aanvraag preventief beëindigen met RequestRateTooLarge (HTTP-statuscode 429). Er wordt een x-ms-retry-after-ms-header retourneert die aangeeft hoe lang de gebruiker in milliseconden moet wachten voordat de aanvraag opnieuw wordt geprobeerd.

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

De SDK's ondervangen dit antwoord impliciet, respecteren de door de server opgegeven header retry-after en proberen de aanvraag opnieuw. Tenzij uw account gelijktijdig wordt gebruikt door meerdere clients, slaagt de volgende nieuwe poging.

Als u meer dan één client hebt die cumulatief consistent boven de aanvraagsnelheid werkt, voldoet het standaard aantal nieuwe pogingen dat momenteel is ingesteld op 9 intern door de client mogelijk niet. In dit geval wordt door de client een DocumentClientException met statuscode 429 naar de toepassing overgebracht.

U kunt het standaard aantal nieuwe proberen wijzigen door de in RetryOptions te stellen op het ConnectionPolicy exemplaar. De DocumentClientException met statuscode 429 wordt standaard geretourneerd na een cumulatieve wachttijd van 30 seconden als de aanvraag blijft werken boven de aanvraagsnelheid. Deze fout retourneert zelfs wanneer het huidige aantal nieuwe poging kleiner is dan het maximale aantal nieuwe poging, ongeacht of de huidige waarde de standaardwaarde van 9 of een door de gebruiker gedefinieerde waarde is.

Het geautomatiseerde gedrag voor opnieuw proberen helpt de tolerantie en bruikbaarheid voor de meeste toepassingen te verbeteren. Maar dit is mogelijk niet het beste gedrag wanneer u prestatiebenchmarks doet, met name wanneer u de latentie meet. De latentie van de client zal pieken als het experiment de serververtraging raakt en ervoor zorgt dat de client-SDK het op de stille kracht opnieuw doet. Om latentiepieken tijdens prestatie-experimenten te voorkomen, meet u de kosten die door elke bewerking worden geretourneerd en zorgt u ervoor dat aanvragen worden uitgevoerd onder het tarief voor gereserveerde aanvragen. Zie Aanvraageenheden voor meer informatie.

Ontwerp voor kleinere documenten voor een hogere doorvoer

De aanvraagkosten (dat wil zeggen de kosten voor de verwerking van aanvragen) van een bepaalde bewerking correleren rechtstreeks met de grootte van het document. Bewerkingen op grote documenten kosten meer dan bewerkingen op kleine documenten.

Volgende stappen

Zie Performance and scale testing with Azure Cosmos DB (Prestatie- en schaaltests met Azure Cosmos DB) voor een voorbeeldtoepassing die wordt gebruikt voor het evalueren van Azure Cosmos DB voor high performance-scenario's op een paar clientmachines.

Zie Partitioneren en schalen in Azure Cosmos DB voor meer informatie over het ontwerpen van uw toepassing voor schaalbaarheid en Azure Cosmos DB.