Teljesítménnyel kapcsolatos tippek az Azure Cosmos DB Java SDK v2-höz

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Az Azure Cosmos DB egy gyors és rugalmas elosztott adatbázis, amely zökkenőmentesen méretezhető, garantált késéssel és átviteli sebességgel. Nem kell jelentős architektúramódosításokat végeznie, és nem kell összetett kódot írnia az adatbázis Azure Cosmos DB-vel való skálázásához. A vertikális fel- és leskálázás ugyanolyan egyszerű, mint egyetlen API-hívás. További információkért tekintse meg a tároló átviteli sebességének kiépítését vagy az adatbázis átviteli sebességének kiépítését. Mivel azonban az Azure Cosmos DB hálózati hívásokon keresztül érhető el, az SQL .NET SDK használatakor az ügyféloldali optimalizálásokkal csúcsteljesítmény érhető el.

Ha tehát javítani szeretné az adatbázis teljesítményét, fontolja meg az alábbi lehetőségeket:

Frissítés a .NET V3 SDK-ra

A .NET v3 SDK ki van adva. Ha a .NET v3 SDK-t használja, tekintse meg a .NET v3 teljesítménymutatóját a következő információkért:

  • Alapértelmezett beállítások a Közvetlen TCP módba
  • Stream API-támogatás
  • Egyéni szerializáló támogatása System.Text.JSON használat engedélyezéséhez
  • Integrált köteg- és tömeges támogatás

Üzemeltetési javaslatok

A kiszolgálóoldali szemétgyűjtés (GC) bekapcsolása

A szemétgyűjtés gyakoriságának csökkentése bizonyos esetekben segíthet. A .NET-ben állítsa a gcServert a következőretrue: .

Az ügyfél számítási feladatainak vertikális felskálázása

Ha nagy átviteli sebességen (több mint 50 000 RU/s) tesztel, az ügyfélalkalmazás szűk keresztmetszetté válhat, mivel a gép túllépi a processzor- vagy hálózati kihasználtságot. Ha eléri ezt a pontot, folytathatja az Azure Cosmos DB-fiók további leküldését az ügyfélalkalmazások több kiszolgálón való skálázásával.

Feljegyzés

A magas processzorhasználat nagyobb késést és időtúllépési kivételeket okozhat.

Metaadat-műveletek

Ne ellenőrizze, hogy létezik-e Create...IfNotExistsAsync adatbázis és/vagy gyűjtemény a gyakori elérési úton és/vagy Read...Async az elemművelet végrehajtása előtt. Az ellenőrzést csak akkor kell elvégezni az alkalmazás indításakor, ha szükséges, ha azt várja, hogy töröljék őket (ellenkező esetben nincs rá szükség). Ezek a metaadat-műveletek további végpontok közötti késést okoznak, nem rendelkeznek SLA-val és saját, nem adatműveletekhez hasonló skálázási korlátozásokkal .

Naplózás és nyomkövetés

Egyes környezetekben engedélyezve van a .NET DefaultTraceListener . A DefaultTraceListener teljesítményproblémákat okoz az éles környezetekben, ami magas processzor- és I/O-szűk keresztmetszeteket okoz. Ellenőrizze és győződjön meg arról, hogy a DefaultTraceListener le van tiltva az alkalmazáshoz úgy, hogy eltávolítja azt az éles környezetekben lévő TraceListenersből .

A legújabb (2.16.2-nél nagyobb) SDK-verziók automatikusan eltávolítják azt, amikor észlelik. A régebbi verziók esetén a következő módszerekkel távolíthatja el:

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
}

Hálózat

Csatlakozás ion szabályzat: Közvetlen kapcsolati mód használata

A .NET V2 SDK alapértelmezett kapcsolati módja az átjáró. A kapcsolati módot a példány felépítése DocumentClient során a paraméterrel ConnectionPolicy konfigurálhatja. Ha közvetlen módot használ, a Protocol paramétert ConnectionPolicy is be kell állítania. A különböző csatlakozási lehetőségekről a kapcsolati módokról szóló cikkből tudhat meg többet.

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

Rövid élettartamú portok elfogyása

Ha magas kapcsolati hangerőt vagy magas porthasználatot lát a példányokon, először ellenőrizze, hogy az ügyfélpéldányok egytonnák-e. Más szóval az ügyfélpéldányoknak egyedinek kell lenniük az alkalmazás teljes élettartama során.

A TCP protokollon való futtatáskor az ügyfél a https protokoll helyett a hosszú élettartamú kapcsolatok használatával optimalizálja a késést, ami 2 perc inaktivitás után leállítja a kapcsolatokat.

Olyan helyzetekben, ahol ritkán fér hozzá, és ha magasabb kapcsolatszámot észlel az átjáró módú hozzáféréshez képest, a következőket teheti:

Az OpenAsync meghívása az első kérés indítási késésének elkerülése érdekében

Alapértelmezés szerint az első kérés nagyobb késéssel rendelkezik, mert le kell kérnie a cím-útválasztási táblát. Az SDK V2 használatakor az inicializálás során egyszeri hívással OpenAsync() elkerülheti az első kérés indítási késését. A hívás a következőképpen néz ki: await client.OpenAsync();

Feljegyzés

OpenAsync kéréseket generál a fiókban lévő összes tároló címútválasztási táblájának lekéréséhez. A sok tárolóval rendelkező fiókok esetében, amelyek alkalmazásának egy részhalmazához fér hozzá, OpenAsync szükségtelen mennyiségű forgalmat generálna, ami lelassítaná az inicializálást. Ezért a használat OpenAsync ebben a forgatókönyvben nem feltétlenül hasznos, mert lelassítja az alkalmazás indítását.

A teljesítmény érdekében helyezze el az ügyfeleket ugyanabban az Azure-régióban

Ha lehetséges, helyezzen el minden olyan alkalmazást, amely meghívja az Azure Cosmos DB-t ugyanabban a régióban, mint az Azure Cosmos DB-adatbázis. Íme egy hozzávetőleges összehasonlítás: az ugyanabban a régióban lévő Azure Cosmos DB-be irányuló hívások 1–2 ms-on belül befejeződnek, de az USA nyugati és keleti partja közötti késés több mint 50 ms. Ez a késés kérésenként eltérő lehet attól függően, hogy a kérés milyen útvonalon halad át az ügyfélről az Azure-adatközpont határára. A lehető legkisebb késést úgy érheti el, ha biztosítja, hogy a hívó alkalmazás ugyanabban az Azure-régióban legyen, mint a kiépített Azure Cosmos DB-végpont. Az elérhető régiók listájáért tekintse meg az Azure-régiókat.

Az Azure Cosmos DB kapcsolati szabályzata

Szálak/tevékenységek számának növelése

Mivel az Azure Cosmos DB-be irányuló hívások a hálózaton keresztül jönnek létre, előfordulhat, hogy a kérések párhuzamosságát módosítania kell, hogy az ügyfélalkalmazás minimális időt töltsön a kérések közötti várakozással. Ha például a .NET-feladat párhuzamos kódtárát használja, több száz olyan feladat sorrendjében hozzon létre, amelyek az Azure Cosmos DB-ből olvasnak vagy írnak.

Gyorsított hálózatkezelés engedélyezése

A késés és a PROCESSZOR-jitter csökkentése érdekében javasoljuk, hogy engedélyezze a gyorsított hálózatkezelést az ügyfél virtuális gépeken. Lásd: Windows rendszerű virtuális gép létrehozása gyorsított hálózatkezeléssel vagy Linux rendszerű virtuális gép létrehozása gyorsított hálózatkezeléssel.

SDK-használat

A legújabb SDK telepítése

Az Azure Cosmos DB SDK-k folyamatosan fejlődnek a legjobb teljesítmény érdekében. Tekintse meg az Azure Cosmos DB SDK lapjait a legújabb SDK meghatározásához és a fejlesztések áttekintéséhez.

Egyetlen azure Cosmos DB-ügyfél használata az alkalmazás teljes élettartama alatt

Minden DocumentClient példány szálbiztos, és hatékony kapcsolatkezelést és cím gyorsítótárazást végez a közvetlen módban való működés során. A hatékony kapcsolatkezelés és az SDK-ügyfél teljesítményének javítása érdekében javasoljuk, hogy az alkalmazás teljes élettartama alatt egyetlen példányt AppDomain használjon.

A hívások blokkolásának elkerülése

Az Azure Cosmos DB SDK-t úgy kell megtervezni, hogy egyszerre több kérést is feldolgozz. Az aszinkron API-k lehetővé teszik, hogy egy kis szálkészlet több ezer egyidejű kérést kezeljen azáltal, hogy nem várakozik a blokkoló hívásokra. Ahelyett, hogy egy hosszú ideig futó szinkron feladatra várna, a szál egy másik kérésen is működhet.

Az Azure Cosmos DB SDK-t használó alkalmazások gyakori teljesítményproblémája az aszinkron hívások blokkolása. Számos szinkron blokkoló hívás a szálkészlet éhezéséhez és a válaszidő romlásához vezet.

Ne tegye:

  • Az aszinkron végrehajtás letiltása a Task.Wait vagy a Task.Result meghívásával.
  • A Task.Run használatával szinkronizált API-t készíthet aszinkron módon.
  • Zárolások beszerzése a közös kódútvonalakban. Az Azure Cosmos DB .NET SDK akkor a leghatékonyabb, ha a kód párhuzamos futtatására van kiállítva.
  • Hívja meg a Task.Run parancsot , és azonnal várja meg. ASP.NET Core már futtatja az alkalmazáskódot normál szálkészlet-szálakon, így a Task.Run meghívása csak extra szükségtelen szálkészlet-ütemezést eredményez. Még ha az ütemezett kód blokkolna is egy szálat, a Task.Run ezt nem akadályozza meg.
  • Használja a DocumentClient.CreateDocumentQuery(...) ToList() parancsot, amelyen blokkoló hívások használatával szinkronizálja a lekérdezést. A lekérdezés aszinkron kiürítéséhez használja az AsDocumentQuery() parancsot.

Tegye:

  • Az Azure Cosmos DB .NET API-k aszinkron meghívása.
  • A teljes hívásverem aszinkron, hogy kihasználhassa az aszinkron/várakozási mintákat.

A profilkészítő, például a PerfView segítségével megtalálhatja a szálkészlethez gyakran hozzáadott szálakat. Az Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start esemény a szálkészlethez hozzáadott szálat jelzi.

Gazdagépenkénti System.Net maximális Csatlakozás növelése átjáró mód használatakor

Az Azure Cosmos DB-kérések HTTPS/REST protokollon keresztül lesznek intézve, amikor átjárómódot használ. Ezekre az alapértelmezett kapcsolati korlát vonatkozik állomásnév vagy IP-cím szerint. Előfordulhat, hogy magasabb értékre (100–1000) kell beállítania MaxConnections , hogy az ügyfélkódtár több egyidejű kapcsolatot használjon az Azure Cosmos DB-hez. A .NET SDK 1.8.0-s és újabb verzióiban a ServicePointManager.Default Csatlakozás ionLimit alapértelmezett értéke 50. Az érték módosításához beállíthatja a Documents.Client.Csatlakozásaz ionPolicy.Max Csatlakozás ionLimit értéke magasabb.

Backoff implementálása újrapróbálkozási időközökkel

A teljesítménytesztelés során növelnie kell a terhelést, amíg a kérések kis száma nem lesz szabályozva. Ha a kérések szabályozottak, az ügyfélalkalmazásnak vissza kell kapcsolnia a szabályozást a kiszolgáló által megadott újrapróbálkozási időközhöz. A visszalépés betartása biztosítja, hogy minimális időt töltsön várakozással az újrapróbálkozások között.

Az újrapróbálkozások szabályzattámogatása az alábbi SDK-kban található:

További információ: RetryAfter.

A .NET SDK 1.19-es és újabb verziójában van egy mechanizmus a további diagnosztikai információk naplózására és a késési problémák elhárítására, ahogy az az alábbi példában is látható. Naplózhatja a diagnosztikai sztringet a nagyobb olvasási késéssel rendelkező kérések esetében. A rögzített diagnosztikai sztring segít megérteni, hogy hányszor kapott 429 hibát egy adott kéréshez.

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

Dokumentum URL-címeinek gyorsítótárazása az alacsonyabb olvasási késés érdekében

A legjobb olvasási teljesítmény érdekében lehetőség szerint gyorsítótárazza a dokumentum URI-jait. Az erőforrás létrehozásakor meg kell határoznia az erőforrás-azonosító gyorsítótárazásához szükséges logikát. Az erőforrás-azonosítókon alapuló keresések gyorsabbak, mint a névalapú keresések, így ezeknek az értékeknek a gyorsítótárazása javítja a teljesítményt.

Szálak/tevékenységek számának növelése

A cikk hálózatkezelési szakaszában további információt a szálak/tevékenységek számának növelése című témakörben talál.

Lekérdezési műveletek

A lekérdezési műveletekhez tekintse meg a lekérdezések teljesítményére vonatkozó tippeket.

Indexelési szabályzat

Nem használt útvonalak kizárása az indexelésből a gyorsabb írás érdekében

Az Azure Cosmos DB indexelési szabályzata azt is lehetővé teszi, hogy az indexelési útvonalak (IndexingPolicy.IncludedPaths és IndexingPolicy.ExcludedPaths) használatával megszűrje, hogy mely dokumentum elérési útjai szerepeljenek az indexelésben, vagy kizárják az indexelésből. Az indexelési útvonalak javíthatják az írási teljesítményt, és csökkenthetik az indextárolást olyan forgatókönyvek esetében, amelyekben a lekérdezési minták előre ismertek. Ennek az az oka, hogy az indexelési költségek közvetlenül korrelálnak az indexelt egyedi útvonalak számával. Ez a kód például azt mutatja be, hogyan zárhatja ki a dokumentumok egy teljes szakaszát (egy részösszeget) az indexelésből a "*" helyettesítő karakterrel:

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

További információ: Azure Cosmos DB indexelési szabályzatok.

Átfutás

Kisebb kérelemegységek/másodperces használat mérése és finomhangolása

Az Azure Cosmos DB számos adatbázisműveletet kínál. Ezek a műveletek közé tartoznak a relációs és hierarchikus lekérdezések az UDF-ekkel, a tárolt eljárásokkal és az eseményindítókkal, amelyek az adatbázis-gyűjtemény dokumentumain működnek. Az egyes műveletekhez kapcsolódó költségek a művelet végrehajtásához szükséges processzortól, I/O-tól és memóriától függően változnak. A hardveres erőforrások megteremtése és felügyelete helyett egy ilyen kérelemegység (RU) az igényelt, különböző adatbázis-műveletek és -szolgáltatások végrehajtásának egyetlen mértékegységeként vehető figyelembe.

Az átviteli sebesség az egyes tárolókhoz beállított kérelemegységek száma alapján van kiépítve. A kérelemegység-felhasználás másodpercenkénti sebességként lesz kiértékelve. A tárolóhoz kiosztott kérelemegység-mértéket meghaladó alkalmazások korlátozottak, amíg a sebesség nem csökken a tárolóhoz kiosztott szint alá. Ha az alkalmazás magasabb átviteli sebességet igényel, további kérelemegységek kiépítésével növelheti az átviteli sebességet.

A lekérdezés összetettsége hatással van arra, hogy egy művelethez hány kérelemegység szükséges. A predikátumok száma, a predikátumok jellege, az UDF-ek száma és a forrásadatkészlet mérete mind befolyásolják a lekérdezési műveletek költségeit.

Bármely művelet (létrehozás, frissítés vagy törlés) többletterhelésének méréséhez vizsgálja meg az x-ms-request-charge fejlécet (vagy a .NET SDK-ban ResourceResponse\<T> vagy FeedResponse\<T> annak megfelelő RequestCharge tulajdonságát) a műveletek által felhasznált kérelemegységek számának méréséhez:

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

Az ebben a fejlécben visszaadott kérelemdíj a kiosztott átviteli sebesség töredéke (azaz 2000 kérelemegység /másodperc). Ha például az előző lekérdezés 1000 1 KB dokumentumot ad vissza, a művelet költsége 1000. Tehát egy másodpercen belül a kiszolgáló csak két ilyen kérést tart tiszteletben, mielőtt a későbbi kéréseket sebességkorlátozásra korlátozná. További információ: Kérelemegységek és a kérelemegység-kalkulátor.

Túl nagy sebességkorlátozás/kérési sebesség kezelése

Amikor egy ügyfél megkísérli túllépni egy fiók fenntartott átviteli sebességét, a kiszolgálón nincs teljesítménycsökkenés, és az átviteli sebesség nem használható a fenntartott szinten túl. A kiszolgáló előzetesen a RequestRateTooLarge (HTTP állapotkód: 429) paranccsal fejezi be a kérést. Visszaad egy x-ms-retry-after-ms fejlécet, amely ezredmásodpercben jelzi, hogy a felhasználónak ki kell várnia a kérés ismételt megkísérlése előtt.

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

Az SDK-k implicit módon elkapják ezt a választ, tiszteletben tartják a kiszolgáló által megadott újrapróbálkozási fejlécet, és újrapróbálkoznak a kéréssel. Ha a fiókját nem éri el egyszerre több ügyfél, a következő újrapróbálkozás sikeres lesz.

Ha több ügyfél kumulatív működése következetesen meghaladja a kérések arányát, előfordulhat, hogy az ügyfél által belsőleg jelenleg 9-re beállított alapértelmezett újrapróbálkozási szám nem elegendő. Ebben az esetben az ügyfél egy DocumentClientException 429-as állapotkódot ad az alkalmazásnak.

Az alapértelmezett újrapróbálkozás számát a példány beállításával RetryOptionsConnectionPolicy módosíthatja. Alapértelmezés szerint a 429-es állapotkódú DocumentClientException 30 másodperces kumulatív várakozási idő után lesz visszaadva, ha a kérés továbbra is a kérési sebesség felett működik. Ez a hiba akkor is visszaadható, ha az újrapróbálkozások aktuális száma kisebb, mint a maximális újrapróbálkozások száma, függetlenül attól, hogy az aktuális érték az alapértelmezett érték 9 vagy egy felhasználó által megadott érték.

Az automatikus újrapróbálkozási viselkedés segít a legtöbb alkalmazás rugalmasságának és használhatóságának javításában. De lehet, hogy nem ez a legjobb viselkedés, ha teljesítménymutatókat végez, különösen akkor, ha a késést méri. Az ügyfél által megfigyelt késés megnő, ha a kísérlet eléri a kiszolgálót, és az ügyfél SDK-jának csendes újrapróbálkozását okozza. A teljesítménykísérletek során fellépő késési csúcsok elkerülése érdekében mérje meg az egyes műveletek által visszaadott díjat, és győződjön meg arról, hogy a kérések a fenntartott kérések aránya alatt működnek. További információ: Kérelemegységek.

A nagyobb átviteli sebesség érdekében kisebb dokumentumok tervezése

Egy adott művelet kérelemdíja (vagyis a kérelemfeldolgozás költsége) közvetlenül a dokumentum méretével függ össze. A nagyméretű dokumentumokon végzett műveletek többe kerülnek, mint a kis méretű dokumentumokon végzett műveletek.

Következő lépések

Az Azure Cosmos DB néhány ügyfélgépen történő nagy teljesítményű forgatókönyvek kiértékeléséhez használt mintaalkalmazásért tekintse meg az Azure Cosmos DB teljesítmény- és méretezési tesztelését.

Ha többet szeretne megtudni az alkalmazás méretezéshez és nagy teljesítményhez való tervezéséről, tekintse meg a particionálást és a skálázást az Azure Cosmos DB-ben.