Sdílet prostřednictvím

Tipy pro zvýšení výkonu pro službu Azure Cosmos DB a sadu .NET SDK v2

PLATÍ PRO: NoSQL

Azure Cosmos DB je rychlá a flexibilní distribuovaná databáze, která se bezproblémově škáluje s garantovanou latencí a propustností. 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. Škálování nahoru a dolů je stejně snadné jako provedení jediného volání rozhraní API. Další informace najdete v tématu zřízení propustnosti kontejneru nebo zřízení propustnosti databáze. Protože je ale služba Azure Cosmos DB přístupná prostřednictvím síťových volání, existují optimalizace na straně klienta, kterými můžete dosáhnout maximálního výkonu při použití sady SQL .NET SDK.

Pokud se tedy pokoušíte zlepšit výkon databáze, zvažte tyto možnosti:

Upgrade na sadu .NET SDK V3

.NET v3 SDK je vydán. Pokud používáte sadu .NET v3 SDK, projděte si průvodce výkonem .NET v3 s následujícími informacemi:

  • Výchozí nastavení režimu Direct TCP
  • Podpora rozhraní API služby Stream
  • Podpora vlastního serializátoru k umožnění využití System.Text.JSON
  • Integrovaná podpora pro dávkové a hromadné zpracování

Doporučení pro hostování

Zapněte uvolňování paměti na straně serveru (GC)

Snížení frekvence garbage collection může v některých případech pomoci. V .NET nastavte gcServer na true.

Rozšíření klientské pracovní zátěže

Pokud testujete na vysokých úrovních propustnosti (více než 50 000 RU/s), může se klientská aplikace stát kritickým bodem kvůli omezování využití procesoru nebo sítě. Pokud se k tomuto bodu dostanete, můžete účet služby Azure Cosmos DB dál rozšiřovat škálováním klientských aplikací horizontálně na více serverů.

Poznámka:

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

Operace s metadaty

Neověřujte, že databáze nebo kolekce existuje voláním Create...IfNotExistsAsync nebo Read...Async v kritické části nebo před provedením operace s položkou. Ověření by se mělo provést pouze při spuštění aplikace, pokud očekáváte, že se odstraní (jinak není potřeba). Tyto operace metadat generují dodatečnou komplexní latenci, nemají žádnou smlouvu SLA a 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 pro vaši aplikaci zakázán DefaultTraceListener odebráním z TraceListeners v produkčních prostředích.

Nejnovější verze sady SDK (větší než 2.16.2) ji automaticky odeberou, když ji zjistí, ve starších verzích ji můžete odebrat:

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

Sítě

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

Výchozí režim připojení sady .NET SDK V2 je brána. Režim připojení nakonfigurujete během vytváření DocumentClient instance pomocí parametru ConnectionPolicy . Pokud používáte přímý režim, musíte také nastavit Protocol pomocí parametru ConnectionPolicy . Další informace o různých možnostech připojení najdete v článku o režimech připojení.

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

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

Pokud u vaší instance pozorujete vysoký objem připojení nebo vysoké využití portů, nejprve ověřte, že instance klienta je singletonem. Jinými slovy, instance klienta by měly být jedinečné po celou dobu života aplikace.

Při spuštění protokolu TCP klient optimalizuje latenci pomocí dlouhotrvajících připojení na rozdíl od protokolu HTTPS, který ukončí připojení po 2 minutách nečinnosti.

Ve scénářích, kdy 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:

Zavolejte OpenAsync, aby se při prvním požadavku vyhnuli latenci spouštění

Ve výchozím nastavení má první požadavek vyšší latenci, protože potřebuje načíst směrovací tabulku adres. Při použití sady SDK V2 zavolejte OpenAsync() jednou během inicializace, abyste se vyhnuli této latenci spouštění při prvním požadavku. Volání vypadá takto: await client.OpenAsync();

Poznámka:

OpenAsync vygeneruje požadavky na získání směrovací tabulky adres pro všechny kontejnery v účtu. Pro účty, které mají mnoho kontejnerů, ale jejichž aplikace přistupuje k podmnožině z nich, OpenAsync by vygenerovalo nepotřebné množství provozu, což by zpomalovalo inicializaci. OpenAsync Použití proto nemusí být v tomto scénáři užitečné, protože zpomaluje spouštění aplikace.

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 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 tím, ž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.

Zásady připojení ke službě Azure Cosmos DB

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

Vzhledem k tomu, že se volání služby Azure Cosmos DB provádí přes síť, možná budete muset měnit stupeň paralelismu 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.

Povolit akcelerované síťování

Pokud chcete snížit latenci a zpoždění procesoru, doporučujeme povolit akcelerované síťové služby na klientských virtuálních počítačích. Viz Vytvoření virtuálního počítače s Windows s akcelerovanými síťovými službami nebo Vytvoření virtuálního počítače s Linuxem s akcelerovanými síťovými službami.

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. Pro zjištění nejnovější sady SDK a přehledu vylepšení navštivte stránky sady SDK služby Azure Cosmos DB.

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

Každá DocumentClient 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 při provozu v přímém režimu. Pokud chcete umožnit efektivní správu připojení a lepší výkon klienta sady SDK, doporučujeme po celou dobu životnosti aplikace použít jednu instanci AppDomain .

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 (Thread Pool) a zhoršení doby odezvy.

Nepoužívejte:

  • Zablokujte asynchronní provádění voláním Task.Wait nebo Task.Result.
  • Použijte Task.Run k tomu, aby se synchronní API stalo asynchronním.
  • Získejte zamykací mechanismy ve společných úsecí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ě na to čekejte. 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 blokoval vlákno, Task.Run tomu nezabrání.
  • Použijte ToList() na DocumentClient.CreateDocumentQuery(...), který používá blokující volání k synchronnímu vyprázdnění dotazu. Pomocí AsDocumentQuery() 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í, aby se mohly využít 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.

Zvyšte MaxConnections pro System.Net na jeden hostitel 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í pro název hostitele nebo IP adresu. Možná budete muset nastavit MaxConnections vyšší hodnotu (100 až 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 nastavit Documents.Client.ConnectionPolicy.MaxConnectionLimit na vyšší hodnotu.

Implementujte backoff při intervalech RetryAfter

Během testování výkonu byste měli zvýšit zatížení, dokud nedojde k omezení malého počtu požadavků. Pokud dojde k omezení požadavků, měla by klientská aplikace snížit frekvenci odesílání požadavků po dobu opakování zadanou serverem. Dodržování backoffu zajišťuje, že strávíte minimální dobu čekáním mezi opakovanými pokusy.

Podpora zásady opakování je zahrnuta v těchto sadách SDK:

Další informace naleznete v tématu RetryAfter.

V sadě .NET SDK verze 1.19 a novější existuje mechanismus protokolování dalších diagnostických informací a řešení potíží s latencí, jak je znázorněno v následující ukázce. Diagnostický řetězec můžete zaznamenat pro požadavky s vyšší latencí při čtení. Zachycený diagnostický řetězec vám pomůže pochopit, kolikrát jste u daného požadavku obdrželi chyby 429.

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

Ukládejte URI dokumentů do mezipaměti pro snížení latence čtení

Identifikátory URI dokumentů můžete ukládat do mezipaměti, kdykoli je to možné pro nejlepší výkon čtení. Při vytváření prostředku je potřeba definovat logiku pro ukládání ID prostředku do mezipaměti. Vyhledávání založená na ID prostředků jsou rychlejší než vyhledávání založená na názvu, takže ukládání těchto hodnot do mezipaměti zvyšuje výkon.

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

Další informace najdete v části Zvýšení počtu vláken a úloh v části Sítě tohoto článku.

Dotazovací operace

Pro operace dotazů se podívejte na tipy pro zlepšení 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). Cesty indexování můžou zlepšit výkon 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. Tento kód například ukazuje, jak vyloučit celý oddíl dokumentů (podstrom) z indexování pomocí zástupného znaku *:

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

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

Propustnost

Optimalizace a ladění pro nižší spotřebu dotazovacích jednotek za sekundu

Azure Cosmos DB nabízí bohatou sadu databázových operací. Mezi tyto operace patří relační a hierarchické dotazy s funkcemi definovanými uživatelem, uloženými procedurami a spouštěmi, všechny tyto operace se týkají dokumentů 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 potřebné k dokončení operace. Místo posuzování a správy hardwarových prostředků můžete jako jedno opatření pro prostředky požadované k provádění různých databázových operací a požadavku na službu pro aplikaci použít jednotku požadavku (RU).

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

Složitost dotazů ovlivňuje, kolik jednotek žádostí se pro operace spotřebuje. Počet predikátů, povaha predikátů, počet funkcí definovaných uživatelem 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 jednotek žádostí spotřebovaných operacemi:

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

Poplatek za požadavek vrácený v této hlavičce je zlomek zřízené propustnosti (to znamená 2 000 RU za sekundu). 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 omezováním rychlosti pozdějších požadavků. Pro další informace viz Jednotky požadavků a kalkulačku jednotek požadavků.

Řešení omezování rychlosti nebo příliš vysoké rychlosti 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 pokusí znovu.

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

Všechny sady SDK implicitně zachytí tuto odpověď, respektují hlavičku 'retry-after' určenou serverem a opakují požadavek. Pokud k vašemu účtu současně nepřistupuje více klientů, bude další opakování úspěšné.

Pokud máte více klientů, kteří svou činností společně konzistentně překračují rychlost požadavků, nemusí stačit výchozí počet opakování, který je interně stanoven klientem na 9. V tomto případě klient vyvolá do aplikace výjimku DocumentClientException se stavovým kódem 429.

Výchozí počet opakování můžete změnit nastavením instance RetryOptionsConnectionPolicy . Ve výchozím nastavení se výjimka DocumentClientException 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í hodnotou 9 nebo uživatelem 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 prudce vzroste, pokud experiment narazí na omezení výkonu serveru a způsobí, že klientské SDK se tiše pokusí o opakování. Aby se předešlo špičkám latence 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í požadavků. Další informace najdete v tématu Žádostní jednotky.

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

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

Další kroky

Ukázkovou aplikaci, která se používá k vyhodnocení služby Azure Cosmos DB pro vysoce výkonné scénáře na několika klientských počítačích, najdete v tématu Testování výkonu a škálování pomocí služby Azure Cosmos DB.

Další informace o návrhu aplikace pro škálování a vysoký výkon najdete v tématu Dělení a škálování ve službě Azure Cosmos DB.

  • Last updated on