Sdílet prostřednictvím

Tipy pro zvýšení výkonu pro Azure Cosmos DB a .NET

PLATÍ PRO: NoSQL

Azure Cosmos DB je rychlá a flexibilní distribuovaná databáze, která se bezproblémově škáluje s garantovanou latencí a úrovněmi propustnosti. Nemusíte provádět významné změny architektury ani psát složitý kód pro škálování databáze pomocí služby Azure Cosmos DB. Přizpůsobení kapacity nahoru a dolů je stejně snadné jako jediný hovor na API. Další informace najdete v tématu zřízení propustnosti kontejneru nebo zřízení propustnosti databáze.

Vzhledem k tomu, že ke službě Azure Cosmos DB se přistupuje přes síťová volání, můžete provést optimalizace na straně klienta, abyste dosáhli maximálního výkonu při použití sady SQL .NET SDK.

Pokud se pokoušíte zlepšit výkon databáze, zvažte možnosti uvedené v následujících částech.

Doporučení pro hostování

Zapněte garbage collection na straně serveru

Omezení frekvence uvolňování paměti může v některých případech pomoci. V .NET nastavte gcServer na true.

Rozšiřte klientskou zátěž

Pokud testujete s vysokými úrovněmi datového průtoku nebo rychlostí vyšší než 50 000 jednotek žádostí za sekundu (RU/s), klientská aplikace by se mohla stát úzkým místem zátěže, protože stroj může dosáhnout maximálního využití CPU nebo sítě. Pokud se k tomuto bodu dostanete, můžete účet služby Azure Cosmos DB dál nabízet horizontálním navýšením kapacity klientských aplikací na více serverů.

Poznámka:

Vysoké využití procesoru může způsobit zvýšenou latenci a výjimky z překročení časového limitu požadavků.

Operace s metadaty

Neověřujte, že databáze nebo kontejner existuje, zavoláním Create...IfNotExistsAsync nebo Read...Async v kritické cestě nebo před provedením operace s položkou. Ověření by se mělo provést jenom při spuštění aplikace, pokud je to potřeba, pokud očekáváte, že se odstraní (jinak není potřeba). Tyto operace s metadaty generují dodatečnou komplexní latenci, nemají žádnou smlouvu SLA a mají vlastní samostatná omezení , která se nedají škálovat, jako jsou operace s daty.

Protokolování a trasování

Některá prostředí mají povolenou technologii .NET DefaultTraceListener . DefaultTraceListener představuje problémy s výkonem v produkčních prostředích, což způsobuje vysoké kritické body procesoru a vstupně-výstupních operací. Zkontrolujte a ujistěte se, že je DefaultTraceListener pro vaši aplikaci zakázán tak, že jej odeberete z TraceListeners v produkčních prostředích.

Verze sady SDK větší než 3.23.0 ji po zjištění automaticky odeberou. Ve starších verzích ho můžete odebrat pomocí následujících příkazů:

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
}

Vysoká dostupnost

Obecné pokyny ke konfiguraci vysoké dostupnosti ve službě Azure Cosmos DB najdete v tématu Vysoká dostupnost ve službě Azure Cosmos DB.

Kromě dobrého základního nastavení v databázové platformě existují specifické techniky, které je možné implementovat v samotné sadě .NET SDK, což může pomoct ve scénářích výpadků. Dvě velmi vhodné strategie jsou strategie dostupnosti založená na prahové hodnotě a jistič na úrovni oddílů.

Strategie dostupnosti založená na prahových hodnotách

Strategie dostupnosti založená na prahových hodnotách může zlepšit koncovou latenci a dostupnost odesláním paralelních žádostí o čtení do sekundárních oblastí (jak je definováno ApplicationPreferredRegions) a přijetím nejrychlejší odpovědi. Tento přístup může výrazně snížit vliv regionálních výpadků nebo podmínek s vysokou latencí na výkon aplikace.

Příklad konfigurace:

Tuto konfiguraci můžete provést pomocí 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();

Nebo konfigurací možností a jejich přidáním do 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);

Jak to funguje:

  1. Počáteční požadavek: V okamžiku T1 se požadavek na čtení provede v primární oblasti (například USA – východ). Sada SDK čeká na odpověď až na 500 milisekund ( threshold hodnota).

  2. Druhý požadavek: Pokud neexistuje odpověď z primární oblasti do 500 milisekund, odešle se paralelní požadavek do další upřednostňované oblasti (například USA – východ 2).

  3. Třetí žádost: Pokud primární ani sekundární oblast nereaguje do 600 milisekund (500 ms + 100 ms, thresholdStep hodnota), sada SDK odešle další paralelní požadavek do třetí upřednostňované oblasti (například USA – západ).

  4. Nejrychlejší odezva vyhrává: Podle toho, která oblast odpoví jako první, přijme se odpověď a ostatní paralelní požadavky se ignorují.

Poznámka:

Pokud první upřednostňovaná oblast vrátí netransientní stavový kód chyby (například dokument nebyl nalezen, chyba autorizace nebo konflikt), operace sama selže rychle, protože strategie dostupnosti v tomto scénáři nemá žádnou výhodu.

Jistič na úrovni oddílů

Jistič na úrovni oddílů (PPCB) je funkce v sadě .NET SDK, která vylepšuje dostupnost a latenci sledováním fyzických oddílů, které nejsou v pořádku. Když je tato možnost povolená, pomáhá přesměrovávat požadavky do spolehlivějších oblastí, což zabraňuje kaskádovým selháním kvůli regionálním nebo dílčím specifickým problémům. Tato funkce je nezávislá na převzetí služeb při selhání, které aktivuje backend, a je řízena prostřednictvím proměnných prostředí.

Tato funkce je ve výchozím nastavení zakázaná, ale se automaticky povolí při povolení převzetí služeb při selhání na úrovni oddílu.

Jak to funguje

  1. Detekce selhání: Pokud jsou zjištěny konkrétní chyby, například 503 Service Unavailable, 408 Request Timeout, nebo tokeny zrušení, sada SDK počítá po sobě jdoucí selhání v oddílu.
  2. Aktivace převzetí služeb při selhání: Jakmile se dosáhne nakonfigurované prahové hodnoty po sobě jdoucích selhání, SDK přesměruje požadavky tohoto rozsahu klíče oddílu do další preferované oblasti pomocí GlobalPartitionEndpointManagerCore.TryMarkEndpointUnavailableForPartitionKeyRange.
  3. Obnovení na pozadí: Během převzetí služeb při selhání se zahájí úloha na pozadí, která pravidelně znovu vyhodnocuje stav selhaného oddílu, a to pokaždé pokusem o připojení ke všem čtyřem replikám. Jakmile je sada SDK stabilní, odebere přepsání a vrátí se do primární oblasti.

Chování podle typu účtu

  • Zápis do jedné oblasti (jeden hlavní server): V logice převzetí služeb při selhání PPCB se účastní pouze požadavky na čtení.
  • Zápis do více regionů (multi-master): Požadavky na čtení i zápis používají logiku převzetí služeb při selhání PPCB.

Možnosti konfigurace

Ke konfiguraci PPCB použijte následující proměnné prostředí:

Proměnná prostředí Popis Výchozí
AZURE_COSMOS_CIRCUIT_BREAKER_ENABLED Povolí nebo zakáže funkci PPCB. false
AZURE_COSMOS_PPCB_CONSECUTIVE_FAILURE_COUNT_FOR_READS Opakované chyby při čtení k aktivaci přepnutí při selhání. 10
AZURE_COSMOS_PPCB_CONSECUTIVE_FAILURE_COUNT_FOR_WRITES Opakovaná selhání zápisu vyvolají převzetí služeb při selhání 5
AZURE_COSMOS_PPCB_ALLOWED_PARTITION_UNAVAILABILITY_DURATION_IN_SECONDS Čas před opětovným přehodnocením stavu oddílu 5 sekundy
AZURE_COSMOS_PPCB_STALE_PARTITION_UNAVAILABILITY_REFRESH_INTERVAL_IN_SECONDS Interval pro aktualizaci stavu oddílu na pozadí. 60 sekundy

Poznámka:

Sada SDK v současné době nemá spolehlivý mechanismus pro návrat k primárnímu systému při čtení. Místo toho se nástroj pro kontrolu stavu na pozadí postupně pokusí znovu povolit původní oblast, když reagují všechny čtyři repliky.

Porovnání optimalizací dostupnosti

  • Strategie dostupnosti založená na prahových hodnotách:

    • Výhoda: Snižuje zpoždění na konci spojení odesíláním paralelních žádostí o čtení do sekundárních oblastí a zlepšuje dostupnost předcházením požadavkům, které vedou k vypršení časového limitu sítě.
    • Kompromis: V porovnání s jističem se účtují další náklady na jednotky žádostí (RU) vzhledem k dalším paralelním požadavkům napříč oblastmi (i když pouze během období, kdy dojde k porušení prahových hodnot).
    • Případ použití: Ideální pro úlohy náročné na čtení, u kterých je kritické snížení latence, a některé další náklady (z hlediska poplatků za RU i zatížení procesoru klienta) jsou přijatelné. Operace zápisu mohou mít výhody, pokud se rozhodnete pro zásady opakování zápisů bez idempotence a účet má zápisy do více oblastí.

  • Jistič na úrovni oddílu:

    • Výhoda: Zlepšuje dostupnost a odezvu tím, že se vyhnete nezdravým partitionům a zajišťuje směrování požadavků do zdravějších oblastí.
    • Kompromis: Nezvyšují se náklady na RU, ale u požadavků, které mohou vést k vypršení časového limitu sítě, může dojít ke ztrátě počáteční dostupnosti.
    • Případ použití: Ideální pro úlohy náročné na zápis nebo smíšené úlohy, kde je nezbytný konzistentní výkon, zejména při práci s oddíly, které můžou občas být nezdravé.

Obě strategie je možné použít společně k vylepšení dostupnosti čtení a zápisu a snížení koncové latence. Jistič na úrovni oddílů může zpracovávat různé přechodné scénáře selhání, včetně těch, které by mohly způsobit pomalý výkon replik, aniž by bylo nutné odesílat paralelní požadavky. Přidání strategie dostupnosti založené na prahových hodnotách dále minimalizuje koncovou latenci a eliminuje ztrátu dostupnosti, pokud jsou přijatelné další náklady na RU.

Díky implementaci těchto strategií můžou vývojáři zajistit, aby jejich aplikace zůstaly odolné, udržovaly vysoký výkon a poskytovaly lepší uživatelské prostředí i během regionálních výpadků nebo podmínek s vysokou latencí.

Vyloučené oblasti

Funkce vyloučených oblastí umožňuje jemně odstupňovanou kontrolu nad směrováním požadavků tím, že umožňuje vyloučit konkrétní oblasti z upřednostňovaných umístění na základě jednotlivých požadavků. Tato funkce je dostupná v sadě .NET SDK služby Azure Cosmos DB verze 3.37.0 a vyšší.

Klíčové výhody:

  • Zpracování omezování rychlosti: Při výskytu odpovědí 429 (příliš mnoho požadavků) automaticky směrujte požadavky do alternativních oblastí s dostupnou propustností.
  • Cílené směrování: Zajištění obsluhy požadavků z konkrétních oblastí vyloučením všech ostatních
  • Vynechat upřednostňované pořadí: Přepsat výchozí seznam upřednostňovaných oblastí pro jednotlivé požadavky bez nutnosti vytvářet samostatné klienty

Configuration:

Vyloučené oblasti je možné nakonfigurovat na úrovni požadavku pomocí ExcludeRegions vlastnosti:

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

Příklad použití – zpracování omezování rychlosti:

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

Tato funkce také funguje s dotazy a dalšími operacemi:

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

Vyladění konzistence oproti dostupnosti

Funkce vyloučených oblastí poskytuje další mechanismus pro vyvažování kompromisu mezi konzistencí a dostupností ve vaší aplikaci. Tato schopnost je obzvláště cenná v dynamických scénářích, kdy se požadavky můžou posunout na základě provozních podmínek:

Dynamické zpracování výpadku: Pokud dojde k výpadku primární oblasti a prahové hodnoty jističe na úrovni oddílů nejsou dostatečné, vyloučené oblasti umožňují okamžité převzetí služeb při selhání bez změn kódu nebo restartování aplikace. To poskytuje rychlejší reakci na regionální problémy v porovnání s čekáním na automatickou aktivaci jističe.

Předvolby podmíněné konzistence: Aplikace můžou implementovat různé strategie konzistence na základě provozního stavu:

  • Stabilní stav: Stanovení priority konzistentních čtení vyloučením všech oblastí kromě primárního, zajištění konzistence dat za potenciálních nákladů na dostupnost
  • Scénáře výpadku: Upřednostnění dostupnosti před striktní konzistencí tím, že umožňuje směrování mezi oblastmi a přijímá potenciální prodlevu dat výměnou za trvalou dostupnost služby

Tento přístup umožňuje externím mechanismům (například správcům provozu nebo nástrojům pro vyrovnávání zatížení) orchestrovat rozhodování o převzetí služeb při selhání, zatímco aplikace udržuje kontrolu nad požadavky na konzistenci prostřednictvím vzorců vyloučení oblastí.

Pokud jsou vyloučeny všechny oblasti, budou požadavky směrovány do primární nebo centrální oblasti. Tato funkce funguje se všemi typy požadavků, včetně dotazů, a je zvláště užitečná pro údržbu instancí klienta singleton při dosažení flexibilního chování směrování.

Sítě

Zásady připojení: Použití režimu přímého připojení

Výchozí režim připojení sady .NET V3 SDK je přímý s protokolem TCP. Režim připojení nakonfigurujete při vytváření CosmosClient instance v CosmosClientOptions. Další informace o různých možnostech připojení najdete v článku o režimech připojení.

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

Vyčerpání dočasných portů

Pokud ve vašich instancích zaznamenáte vysoké množství připojení nebo vysoké využití portů, nejprve ověřte, že jsou instance klienta singletony. Jinými slovy, instance klienta by měly být jedinečné po celou dobu života aplikace.

Když běží na protokolu TCP, klient optimalizuje latenci pomocí dlouhotrvajících připojení. To je na rozdíl od protokolu HTTPS, který ukončí připojení po dvou minutách nečinnosti.

Ve scénářích, ve kterých máte řídký přístup, a pokud si v porovnání s přístupem v režimu brány všimnete vyššího počtu připojení, můžete:

Z hlediska výkonu shromážděte klienty ve stejné oblasti Azure.

Pokud je to možné, umístěte všechny aplikace, které volají službu Azure Cosmos DB, do stejné oblasti jako databáze Azure Cosmos DB. Tady je přibližné porovnání: Volání služby Azure Cosmos DB ve stejné oblasti se dokončí do 1 milisekund (ms) až 2 ms, ale latence mezi pobřežím USA – západ a východ je větší než 50 ms. Tato latence se může lišit od požadavku na požadavek v závislosti na trase, kterou žádost přijala při průchodu z klienta do hranice datacentra Azure.

Nejnižší možnou latenci získáte tak, že se volající aplikace nachází ve stejné oblasti Azure jako zřízený koncový bod služby Azure Cosmos DB. Seznam dostupných oblastí najdete v tématu Oblasti Azure.

Diagram znázorňující společně umístěné klienty ve stejné oblasti.

Zvýšení počtu vláken nebo úloh

Vzhledem k tomu, že volání do služby Azure Cosmos DB se provádějí přes síť, může být potřeba měnit stupeň souběžnosti vašich požadavků, aby klientská aplikace strávila minimální dobu čekáním mezi požadavky. Pokud například používáte paralelní knihovnu úloh .NET, vytvořte pořadí stovek úloh, které čtou nebo zapisují do služby Azure Cosmos DB.

Povolení akcelerovaných síťových služeb za účelem snížení latence a zpoždění procesoru

Pokud chcete maximalizovat výkon, doporučujeme postupovat podle pokynů k povolení akcelerovaných síťových služeb na virtuálním počítači Azure s Windows nebo Linuxem .

Bez akcelerovaných síťových operací může být vstupně-výstupní operace mezi vaším virtuálním počítačem Azure a dalšími prostředky Azure zbytečně směrována přes hostitele a virtuální přepínač umístěný mezi virtuálním počítačem a jeho síťovou kartou. Pokud je hostitel a virtuální přepínač zařazen do cesty k datům, nejenže zvyšuje latenci a kolísání v komunikačním kanálu, ale také odebírá cykly procesoru z virtuálního počítače. S akcelerovaným síťováním se rozhraní virtuálního počítače přímo připojuje k síťové kartě bez zprostředkovatelů; veškeré podrobnosti o síťových politikách, které byly zpracovány hostitelem a virtuálním přepínačem, se nyní zpracovávají v hardwaru síťové karty; hostitel i virtuální přepínač jsou obejité. Obecně můžete očekávat nižší latenci a vyšší propustnost, stejně jako konzistentnější latenci a snížení využití procesoru, když povolíte akcelerované síťové služby.

Omezení: Akcelerované síťové služby musí být podporovány v operačním systému virtuálního počítače a dají se povolit jenom v případě, že je virtuální počítač zastavený a uvolněný. Virtuální počítač nejde nasadit pomocí Azure Resource Manageru. Služba App Service nemá povolenou akcelerovanou síť.

Další podrobnosti najdete v pokynech pro Windows a Linux .

Využití sady SDK

Instalace nejnovější sady SDK

Sady SDK služby Azure Cosmos DB se neustále vylepšují, aby poskytovaly nejlepší výkon. Chcete-li zjistit nejnovější verzi sady SDK a zkontrolovat vylepšení, podívejte se na Azure Cosmos DB SDK.

Použijte streamová rozhraní API

Sada .NET SDK V3 obsahuje rozhraní API datových proudů, která mohou přijímat a vracet data bez serializace.

Aplikace střední vrstvy, které nespotřebovávají odpovědi přímo ze sady SDK, ale předávají je do jiných aplikačních vrstev, můžou využívat rozhraní API streamu. Příklady zpracování datových proudů najdete v ukázkách správy položek.

Použití jednoúčelového klienta Azure Cosmos DB po celou dobu životnosti vaší aplikace

Každá CosmosClient instance je bezpečná pro přístup z více vláken a provádí efektivní správu připojení a ukládání adres do mezipaměti, když pracuje v přímém režimu. Pokud chcete umožnit efektivní správu připojení a lepší výkon klienta sady SDK, doporučujeme pro každý účet, se kterým vaše aplikace komunikuje, používat jednu instanci po AppDomain celou dobu životnosti aplikace.

Informace o víceklientských aplikacích, které zpracovávají více účtů, najdete v souvisejících osvědčených postupech.

Když pracujete na Azure Functions, instance by také měly dodržovat stávající pokyny a udržovat jednu instanci.

Vyhněte se blokování volání

Sada SDK služby Azure Cosmos DB by měla být navržená tak, aby zpracovávala mnoho požadavků současně. Asynchronní rozhraní API umožňují malému fondu vláken zpracovávat tisíce souběžných požadavků tím, že nečeká na blokující volání. Místo čekání na dokončení dlouhotrvající synchronní úlohy může vlákno fungovat na jiném požadavku.

Běžný problém s výkonem v aplikacích používajících sadu SDK služby Azure Cosmos DB blokuje volání, která by mohla být asynchronní. Mnoho synchronních blokujících volání vede k hladovění fondu vláken a snížení doby odezvy.

Nepoužívejte:

  • Zablokujte asynchronní provádění voláním Task.Wait nebo Task.Result.
  • Použití Task.Run k vytvoření synchronního rozhraní API asynchronní.
  • Získejte zámky v běžných cestách kódu. Sada .NET SDK služby Azure Cosmos DB je nejvýkonnější při paralelním spouštění kódu.
  • Zavolejte Task.Run a okamžitě ho čekáte. ASP.NET Core už spouští kód aplikace na normálních vláknech fondu vláken, takže volání Task.Run vede pouze k nadbytečné plánování fondu vláken. I když by naplánovaný kód zablokoval vlákno, task.Run to nezabrání.
  • Nepoužívejte funkci ToList(), Container.GetItemLinqQueryable<T>()která používá blokující volání k synchronnímu vyprázdnění dotazu. Pomocí toFeedIterator() vyprázdněte dotaz asynchronně.

Udělejte toto:

  • Asynchronní volání rozhraní .NET API služby Azure Cosmos DB
  • Celý zásobník volání je asynchronní, abyste mohli využívat vzory async/await.

Profiler, například PerfView, lze použít k vyhledání vláken často přidávaných do fondu vláken. Událost Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start označuje vlákno přidané do fondu vláken.

Zakázání odpovědi na obsah při operacích zápisu

U úloh, které mají těžké zatížení při vytváření, nastavte EnableContentResponseOnWrite možnost požadavku na false. Služba už nevrací vytvořený nebo aktualizovaný prostředek do sady SDK. Za normálních okolností, protože aplikace má vytvořený objekt, nepotřebuje službu k vrácení. Hodnoty hlaviček jsou stále přístupné, například poplatky za požadavek. Zakázání odpovědi na obsah může přispět ke zlepšení výkonu, protože sada SDK už nemusí přidělovat paměť nebo serializovat tělo odpovědi. Snižuje také využití šířky pásma sítě, aby dále zlepšil výkon.

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

Povolení hromadné optimalizace propustnosti místo latence

Povolte hromadné zpracování pro scénáře, ve kterých pracovní zátěž vyžaduje velkou propustnost a latence není tak důležitá. Další informace o povolení funkce Bulk a informace o tom, pro které scénáře se má použít, najdete v tématu Úvod k hromadné podpoře.

Zvýšení System.Net MaxConnections na hostitele při použití režimu brány

Požadavky služby Azure Cosmos DB se provádějí přes PROTOKOL HTTPS/REST při použití režimu brány. Podléhají výchozímu limitu připojení na název hostitele nebo IP adresu. Možná budete muset nastavit MaxConnections vyšší hodnotu (od 100 do 1 000), aby klientská knihovna mohla používat více souběžných připojení ke službě Azure Cosmos DB. V sadě .NET SDK 1.8.0 a novějších je výchozí hodnota pro ServicePointManager.DefaultConnectionLimit 50. Pokud chcete hodnotu změnit, můžete ji nastavit Documents.Client.ConnectionPolicy.MaxConnectionLimit na vyšší hodnotu.

Zvýšení počtu vláken nebo úloh

Viz Zvýšení počtu vláken nebo úloh v části Sítě tohoto článku.

Správa závislostí Newtonsoft.Json

Přehled

Sada .NET SDK služby Azure Cosmos DB má závislost na Newtonsoft.Json pro operace serializace JSON. Tato závislost se nespravuje automaticky – v projektu musíte explicitně přidat Newtonsoft.Json přímou závislost.

Sada SDK se interně zkompiluje proti Newtonsoft.Json 10.x, která má známé ohrožení zabezpečení. I když je sada SDK technicky kompatibilní s verzí 10.x a použití Newtonsoft.Json sady SDK není náchylné k nahlášenému problému se zabezpečením, přesto doporučujeme použít verzi 13.0.3 nebo vyšší , abyste se vyhnuli potenciálním problémům nebo konfliktům zabezpečení. Verze 13.x zahrnují zásadní změny, ale vzory použití sady SDK jsou s těmito změnami kompatibilní.

Důležité

Tato závislost se vyžaduje i při použití System.Text.Json pro uživatelem definované typy prostřednictvím CosmosClientOptions.UseSystemTextJsonSerializerWithOptions, protože interní operace sady SDK stále používají Newtonsoft.Json pro systémové typy.

Při použití sady .NET SDK služby Azure Cosmos DB v3 vždy explicitně přidejte Newtonsoft.Json jako přímou závislost verzi 13.0.3 nebo vyšší. Nepoužívejte verzi 10.x kvůli známým ohrožením zabezpečení.

Pro projekty typu Standard .csproj

<ItemGroup>
  <PackageReference Include="Microsoft.Azure.Cosmos" Version="3.47.0" />
  <PackageReference Include="Newtonsoft.Json" Version="13.0.4" />
</ItemGroup>

Pro projekty využívající správu centrálních balíčků

Pokud váš projekt používá Directory.Packages.props:

<Project>
  <ItemGroup>
    <PackageVersion Include="Microsoft.Azure.Cosmos" Version="3.47.0" />
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.4" />
  </ItemGroup>
</Project>

Řešení potíží s konflikty verzí

Chybějící referenční položka Newtonsoft.Json

Pokud dojde k chybě sestavení, například:

The Newtonsoft.Json package must be explicitly referenced with version >= 10.0.2. Please add a reference to Newtonsoft.Json or set the 'AzureCosmosDisableNewtonsoftJsonCheck' property to 'true' to bypass this check.

Tato chyba je záměrně generována cíli sestavení sady Cosmos DB SDK, aby se zajistilo, že závislost je správně nakonfigurovaná.

Řešení pro aplikace:

Přidejte explicitní odkaz na Newtonsoft.Json, jak je znázorněno v části Doporučená konfigurace výše.

Řešení pro knihovny:

Pokud vytváříte knihovnu (ne aplikaci) a chcete odložit závislost Newtonsoft.Json na uživatele vaší knihovny, můžete tuto kontrolu obejít nastavením vlastnosti MSBuild v .csproj:

<PropertyGroup>
  <AzureCosmosDisableNewtonsoftJsonCheck>true</AzureCosmosDisableNewtonsoftJsonCheck>
</PropertyGroup>

Výstraha

Tento obchvat použijte pouze při vytváření knihoven, kde koncoví uživatelé poskytnou závislost Newtonsoft.Json. Pro aplikace vždy přidejte explicitní odkaz.

Konflikty verzí balíčku

Pokud dojde k chybám sestavení, například:

error NU1109: Detected package downgrade: Newtonsoft.Json from 13.0.4 to centrally defined 13.0.3

Solution:

  1. Určete požadovanou verzi kontrolou, které balíčky potřebují novější verze:

    dotnet list package --include-transitive | Select-String "Newtonsoft.Json"

  2. Aktualizujte centralizovanou verzi balíčku tak, aby odpovídala nebo překročila nejvyšší požadovanou verzi:

    <PackageVersion Include="Newtonsoft.Json" Version="13.0.4" />

  3. Vyčištění a opětovné sestavení:

    dotnet clean
dotnet restore
dotnet build

Kompatibilita verzí

Následující tabulka uvádí minimální doporučené zabezpečené verze Newtonsoft.Json pro každou verzi sady SDK služby Cosmos DB. I když sada SDK může technicky pracovat s verzí 10.x, tyto verze by se nikdy neměly používat kvůli ohrožením zabezpečení.

Verze sady SDK služby Cosmos DB Minimální zabezpečená verze Doporučeno
3.47.0+ 13.0.3 13.0.4
3.54.0+ 13.0.4 13.0.4

Návod

Pokud používáte .NET Aspire 13.0.0 nebo novější, ujistěte se, že Newtonsoft.Json je ve verzi 13.0.4, abyste se vyhnuli konfliktům s komponentami Azure od Aspire.

Osvědčené postupy

  • Vždy přidat jako přímou závislost – sada SDK tuto závislost automaticky nespravuje za vás.
  • Použití verze 13.0.3 nebo vyšší – nikdy nepoužívejte 10.x bez ohledu na technickou kompatibilitu kvůli známým ohrožením zabezpečení
  • Vyžadováno i v případě System.Text.Json – Musíte zahrnout Newtonsoft.Json i při použití UseSystemTextJsonSerializerWithOptions, protože sada SDK ho interně používá pro systémové typy.
  • Explicitně připnout verzi – Nespoléhejte na přechodné řešení závislostí.
  • Upozornění monitorování – Zacházení s upozorněními downgradu balíčku NuGet (NU1109) jako s chybami v kanálech CI/CD

Dotazové operace

Informace o operacích dotazů najdete v tipech k výkonu dotazů.

Zásady indexování

Vyloučení nepoužívaných cest z indexování za účelem zrychlení zápisu

Zásady indexování služby Azure Cosmos DB také umožňují určit, které cesty k dokumentu se mají zahrnout nebo vyloučit z indexování pomocí cest indexování (IndexingPolicy.IncludedPaths a IndexingPolicy.ExcludedPaths).

Indexování pouze potřebných cest může zlepšit výkon zápisu, snížit poplatky za RU při operacích zápisu a snížit úložiště indexů pro scénáře, ve kterých jsou vzory dotazů známé předem. Důvodem je to, že náklady indexování korelují přímo s počtem indexovaných jedinečných cest. Následující kód například ukazuje, jak vyloučit celý oddíl dokumentů (podstrom) z indexování pomocí zástupného znaku * :

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

Další informace najdete v tématu Zásady indexování služby Azure Cosmos DB.

Propustnost

Měření a ladění pro nižší využití RU/s

Azure Cosmos DB nabízí bohatou sadu databázových operací. Mezi tyto operace patří relační a hierarchické dotazy s uživatelem definovanými funkcemi (UDF), uloženými procedurami a triggery, všechny operace s dokumenty v rámci kolekce databází.

Náklady spojené s každou z těchto operací se liší v závislosti na procesoru, V/V a paměti, které jsou potřeba k dokončení operace. Místo toho, abyste přemýšleli o hardwarových prostředcích a správě hardwarových prostředků, můžete jednotku žádostí považovat za jedinou míru pro prostředky, které jsou potřeba k provádění různých databázových operací a poskytování žádosti o aplikaci.

Propustnost se zřizuje na základě počtu jednotek žádostí nastavených pro každý kontejner. Spotřeba RU se vyhodnocuje jako míra jednotek za sekundu. Aplikace, které překročí přidělenou sazbu RU pro svůj kontejner, jsou omezeny, dokud tato sazba neklesne pod přidělenou úroveň kontejneru. Pokud vaše aplikace vyžaduje vyšší úroveň propustnosti, můžete zvýšit propustnost zřízením dalších RU.

Složitost dotazu ovlivňuje, kolik RU se pro operaci spotřebuje. Počet predikátů, povaha predikátů, počet souborů UDF a velikost zdrojové datové sady ovlivňují náklady na operace dotazů.

Pokud chcete změřit režii jakékoli operace (vytvoření, aktualizace nebo odstranění), zkontrolujte hlavičku x-ms-request-charge (nebo ekvivalentní RequestCharge vlastnost v ResourceResponse<T>FeedResponse<T> sadě .NET SDK) a změřte počet RU spotřebovaných operacemi:

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

Poplatek za požadavek, který je vrácen v této hlavičce, je zlomkem vyhrazené propustnosti (tedy 2 000 RU/s). Pokud například předchozí dotaz vrátí 1 000 1kB dokumentů, náklady na operaci jsou 1 000. Takže během jedné sekundy server dodržuje pouze dva takové požadavky před tím, než omezí rychlost pozdějších požadavků. Další informace naleznete v tématech Jednotky žádostí a Kalkulačka jednotek žádosti.

Zpracování omezování rychlosti nebo příliš velké frekvence požadavků

Když se klient pokusí překročit rezervovanou propustnost pro účet, nedojde na serveru ke snížení výkonu a k žádnému použití kapacity propustnosti nad rezervovanou úroveň. Server předem ukončí požadavek na RequestRateTooLarge (stavový kód HTTP 429). Vrátí hlavičku x-ms-retry-after-ms , která udává dobu v milisekundách, že uživatel musí počkat, než se o požadavek znovu pokusí.

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

Sady SDK implicitně zachytí tuto odpověď, respektují serverem zadanou hlavičku Retry-After a opakují požadavek. Pokud k vašemu účtu současně přistupuje více klientů, bude další opakování úspěšné.

Pokud máte více klientů, kteří souhrnně a konzistentně pracují nad rychlostí požadavků, výchozí počet opakování, který je aktuálně klientem interně nastaven na 9, nemusí stačit. V tomto případě klient vyvolá výjimku CosmosException se stavovým kódem 429 pro aplikaci.

Výchozí počet opakování můžete změnit nastavením instance RetryOptionsCosmosClientOptions . Ve výchozím nastavení se výjimka CosmosException se stavovým kódem 429 vrátí po kumulativní době čekání 30 sekund, pokud požadavek nadále funguje nad rychlostí požadavků. Tato chyba se vrátí i v případě, že je aktuální počet opakování menší než maximální počet opakování, ať už je aktuální hodnota výchozí hodnota 9 nebo uživatelsky definovaná hodnota.

Automatizované chování opakování pomáhá zlepšit odolnost a použitelnost většiny aplikací. Nemusí se ale jednat o nejlepší chování při srovnávacích testech výkonu, zejména při měření latence. Latence pozorovaná klientem se zvýší, pokud experiment narazí na omezení serveru a způsobí, že SDK klienta automaticky zopakuje pokus, aniž by si toho uživatel všiml. Aby nedošlo ke špičkám zpoždění během experimentů s výkonem, změřte náboj vrácený jednotlivými operacemi a zajistěte, aby požadavky fungovaly pod rezervovanou rychlostí.

Další informace najdete v tématu Jednotky požadavků.

Pro zajištění vyšší propustnosti navrhujte menší dokumenty.

Poplatek za požadavek (tj. náklady na zpracování požadavku) zadané operace koreluje přímo s velikostí dokumentu. Operace s velkými dokumenty stojí více než operace s malými dokumenty.

Další kroky

  • Last updated on