Porady dotyczące wydajności dla zestawu Java SDK asynchronicznego usługi Azure Cosmos DB w wersji 2

Azure Cosmos DB to szybka i elastyczna rozproszona baza danych, która bezproblemowo skaluje się z gwarantowanym opóźnieniem i przepływnością. Nie musisz wprowadzać istotnych zmian architektury ani pisać złożonego kodu w celu skalowania bazy danych za pomocą usługi Azure Cosmos DB. Skalowanie w górę i w dół jest tak proste, jak tworzenie pojedynczego wywołania interfejsu API lub wywołania metody zestawu SDK. Jednak ze względu na to, że usługa Azure Cosmos DB jest dostępna za pośrednictwem wywołań sieciowych, można dokonać optymalizacji po stronie klienta, aby osiągnąć szczytową wydajność podczas korzystania z zestawu Azure Cosmos DB Async Java SDK w wersji 2.

Jeśli więc zadajesz pytanie "Jak mogę poprawić wydajność bazy danych?", rozważ następujące opcje:

Sieć

• Tryb połączenia: użyj trybu bezpośredniego

  Sposób, w jaki klient nawiązuje połączenie z usługą Azure Cosmos DB, ma ważne konsekwencje dla wydajności, zwłaszcza w zakresie opóźnienia po stronie klienta. ConnectionMode to ustawienie konfiguracji klucza dostępne do konfigurowania zasad połączenia klienta. W przypadku zestawu Java SDK asynchronicznego usługi Azure Cosmos DB w wersji 2 dostępne są dwa dostępne tryby połączenia:

  • Brama (wartość domyślna)
  • Bezpośredni

  Tryb bramy jest obsługiwany na wszystkich platformach SDK i jest domyślnie skonfigurowaną opcją. Jeśli aplikacje działają w sieci firmowej z rygorystycznymi ograniczeniami zapory, tryb bramy jest najlepszym wyborem, ponieważ używa standardowego portu HTTPS i pojedynczego punktu końcowego. Kompromisem wydajności jest jednak to, że tryb Gateway obejmuje dodatkowy krok w sieci za każdym razem, gdy dane są odczytywane lub zapisywane w usłudze Azure Cosmos DB. W związku z tym tryb bezpośredni zapewnia lepszą wydajność z powodu mniejszej liczby przeskoków sieciowych.

  Parametr ConnectionMode jest konfigurowany podczas budowy wystąpienia DocumentClient z parametrem ConnectionPolicy.

Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

    public ConnectionPolicy getConnectionPolicy() {
        ConnectionPolicy policy = new ConnectionPolicy();
        policy.setConnectionMode(ConnectionMode.Direct);
        policy.setMaxPoolSize(1000);
        return policy;
    }

    ConnectionPolicy connectionPolicy = new ConnectionPolicy();
    DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);

• Sortowanie klientów w tym samym regionie świadczenia usługi Azure pod kątem wydajności

  Jeśli to możliwe, umieść wszystkie aplikacje wywołujące usługę Azure Cosmos DB w tym samym regionie co baza danych usługi Azure Cosmos DB. Aby uzyskać przybliżone porównanie, wywołania usługi Azure Cosmos DB w tym samym regionie są kompletne w ciągu 1–2 ms, ale opóźnienie między zachodnim i wschodnim wybrzeżem STANÓW Zjednoczonych wynosi >50 ms. To opóźnienie może się różnić z zapytania na zapytanie w zależności od trasy, którą żądanie pokonuje od klienta do granicy centrum danych platformy Azure. Najmniejsze możliwe opóźnienie jest osiągane przez zapewnienie, że aplikacja wywołująca znajduje się w tym samym regionie świadczenia usługi Azure, co aprowizowany punkt końcowy usługi Azure Cosmos DB. Aby uzyskać listę dostępnych regionów, zobacz Regiony świadczenia usługi Azure.

  

Użycie zestawu SDK

• Instalowanie najnowszego zestawu SDK

  Zestawy SDK usługi Azure Cosmos DB są stale ulepszane, aby zapewnić najlepszą wydajność. Zobacz informacje o wersji usługi Azure Cosmos DB Async Java SDK w wersji 2, aby określić najnowszy zestaw SDK i zapoznać się z ulepszeniami.

• Używanie pojedynczego klienta usługi Azure Cosmos DB przez cały okres istnienia aplikacji

  Każde wystąpienie AsyncDocumentClient jest bezpieczne wątkowo i wykonuje wydajne zarządzanie połączeniami i buforowanie adresów. Aby umożliwić wydajne zarządzanie połączeniami i lepszą wydajność przez klasę AsyncDocumentClient, zaleca się użycie pojedynczego wystąpienia klasy AsyncDocumentClient na element AppDomain w okresie istnienia aplikacji.

• Dostrajanie Polityki Połączenia

  Domyślnie żądania trybu bezpośredniego usługi Azure Cosmos DB są wykonywane za pośrednictwem protokołu TCP podczas korzystania z zestawu Async Java SDK usługi Azure Cosmos DB w wersji 2. Zestaw SDK używa specjalnej architektury trybu bezpośredniego do dynamicznego zarządzania zasobami sieciowymi i uzyskania najlepszej wydajności.

  W wersji 2 Azure Cosmos DB Async Java SDK, tryb bezpośredni jest najlepszym wyborem do poprawy wydajności bazy danych przy większości obciążeń.

  • Omówienie trybu bezpośredniego

  

  Architektura po stronie klienta zastosowana w trybie bezpośrednim umożliwia przewidywalne wykorzystanie sieci i multipleksowany dostęp do replik usługi Azure Cosmos DB. Na powyższym diagramie pokazano, jak tryb bezpośredni kieruje żądania klientów do replik w zapleczu usługi Azure Cosmos DB. Architektura trybu bezpośredniego przydziela maksymalnie 10 kanałów po stronie klienta na replikę bazy danych. Kanał to połączenie TCP poprzedzone buforem żądań o głębokości 30 żądań. Kanały należące do repliki są dynamicznie przydzielane zgodnie z potrzebami przez punkt końcowy usługi repliki. Gdy użytkownik wysyła żądanie w trybie bezpośrednim, klient TransportClient kieruje żądanie do odpowiedniego punktu końcowego usługi na podstawie klucza partycji. Kolejka żądań buforuje żądania przed punktem końcowym usługi.

  • Opcje konfiguracji ConnectionPolicy dla trybu bezpośredniego

    W pierwszym kroku użyj poniższych zalecanych ustawień konfiguracji. Skontaktuj się z zespołem usługi Azure Cosmos DB , jeśli wystąpią problemy w tym konkretnym temacie.

    Jeśli korzystasz z usługi Azure Cosmos DB jako bazy danych referencyjnej (oznacza to, że baza danych jest używana w przypadku wielu operacji odczytu punktowego i kilku operacji zapisu), może być dopuszczalne ustawienie idleEndpointTimeout na 0 (czyli bez limitu czasu).

    Opcja konfiguracji	Default
    rozmiar strony bufora	8192
    connectionTimeout	"PT1M"
    limit czasu bezczynności kanału	"PT0S"
    idleEndpointTimeout	"PT1M10S"
    maksymalnaPojemnośćBufora	8388608
    maxChannelsPerEndpoint	10
    maxRequestsPerChannel	30
    OdbiórCzasDetekcjiZawieszenia (only if a descriptive translation is appropriate, otherwise maintain the original)	"PT1M5S"
    requestExpiryInterval	"PT5S"
    requestTimeout	"PT1M"
    requestTimerResolution	"PT0.5S"
    sendHangDetectionTime (wyślijCzasWykrywaniaZawieszenia)	"PT10S"
    CzasWyłączenia	"PT15S"

• Porady dotyczące programowania dla trybu bezpośredniego

  Zapoznaj się z artykułem dotyczącym rozwiązywania problemów dla Azure Cosmos DB Async Java SDK v2 jako punkt odniesienia przy rozwiązywaniu wszelkich problemów z SDK.

  Niektóre ważne porady dotyczące programowania podczas korzystania z trybu bezpośredniego:

  • Używaj wielowątkowości w aplikacji do wydajnego transferu danych TCP — po złożeniu żądania aplikacja powinna subskrybować na odbieranie danych w innym wątku. Nie zrobienie tego wymusza niezamierzoną operację "półdupleksu", co skutkuje zablokowaniem kolejnych żądań w oczekiwaniu na odpowiedź poprzedniego żądania.

  • Wykonywanie obciążeń intensywnie korzystających z obliczeń w dedykowanym wątku — z podobnych powodów do poprzedniej porady operacje, takie jak złożone przetwarzanie danych, najlepiej umieścić w osobnym wątku. ** Żądanie ściągające dane z innego magazynu danych (na przykład, jeśli wątek korzysta z magazynów danych usługi Azure Cosmos DB i Spark jednocześnie) może doświadczać zwiększonego opóźnienia i zaleca się utworzenie dodatkowego wątku oczekującego na odpowiedź z innego magazynu danych.

    • Podstawowe operacje wejścia/wyjścia sieci w Azure Cosmos DB Async Java SDK v2 są zarządzane przez platformę Netty. Zapoznaj się z tymi wskazówkami dotyczącymi unikania schematów kodowania, które blokują wątki wejścia/wyjścia Netty.

  • Modelowanie danych — umowa SLA usługi Azure Cosmos DB zakłada, że rozmiar dokumentu będzie mniejszy niż 1 KB. Optymalizacja modelu danych i programowania w celu faworyzowania mniejszego rozmiaru dokumentu zwykle doprowadzi do zmniejszenia opóźnienia. Jeśli potrzebujesz magazynu i pobierania dokumentów większych niż 1 KB, zalecane jest, aby dokumenty łączyły się z danymi w usłudze Azure Blob Storage.

• Dostosowanie zapytań równoległych dla zbiorów partycjonowanych

  Zestaw Java SDK asynchronicznego usługi Azure Cosmos DB w wersji 2 obsługuje zapytania równoległe, które umożliwiają równoległe wykonywanie zapytań dotyczących kolekcji partycjonowanej. Aby uzyskać więcej informacji, zobacz przykłady kodu związane z pracą z zestawami SDK. Zapytania równoległe zostały zaprojektowane w celu zwiększenia opóźnienia zapytań i przepływności w porównaniu z ich odpowiednikami seryjnymi.

  • Dostrajanie parametru setMaxDegreeOfParallelism:

    Zapytania równoległe działają poprzez jednoczesne wykonywanie zapytań o wiele partycji. Jednak dane z pojedynczej kolekcji partycjonowanej są pobierane szeregowo w odniesieniu do zapytania. Dlatego należy użyć setMaxDegreeOfParallelism, aby ustawić liczbę partycji, które mają maksymalną szansę osiągnięcia najbardziej wydajnego zapytania, pod warunkiem, że wszystkie inne warunki systemowe pozostają takie same. Jeśli nie znasz liczby partycji, możesz użyć funkcji setMaxDegreeOfParallelism, aby ustawić dużą liczbę, a system wybierze minimalną (liczbę partycji, podaną przez użytkownika dane wejściowe) jako maksymalny stopień równoległości.

    Należy pamiętać, że zapytania równoległe dają najlepsze korzyści, jeśli dane są równomiernie dystrybuowane we wszystkich partycjach w odniesieniu do zapytania. Jeśli kolekcja partycjonowana jest w taki sposób, że wszystkie lub większość danych zwracanych przez zapytanie koncentruje się w kilku partycjach (lub jednej partycji w najgorszym przypadku), wydajność zapytania byłaby ograniczona przez te partycje.

  • Regulacja ustawień maxBufferedItemCount:

    Zapytanie równoległe jest przeznaczone do wstępnego pobierania wyników, gdy bieżąca partia wyników jest przetwarzana przez klienta. Wstępne pobieranie pomaga w ogólnym ulepszeniu wydajności zapytania, przez zmniejszenie jego latencji. setMaxBufferedItemCount ogranicza liczbę wstępnie pobranych wyników. Ustawienie parametru setMaxBufferedItemCount na oczekiwaną liczbę zwróconych wyników (lub wyższą) umożliwia zapytaniu maksymalne wykorzystanie korzyści z wstępnego pobierania.

    Wstępne pobieranie działa tak samo, niezależnie od wartości MaxDegreeOfParallelism, i istnieje jeden bufor dla danych ze wszystkich partycji.

• Implementowanie wycofywania w interwałach getRetryAfterInMilliseconds

  Podczas testowania wydajnościowego należy zwiększyć obciążenie, dopóki nie zostanie ograniczona niewielka liczba żądań. Jeśli zostanie ograniczona, aplikacja kliencka powinna wycofać się z interwału ponawiania prób określonego przez serwer. Przestrzeganie odstępu gwarantuje, że spędzasz minimalną ilość czasu na oczekiwanie między próbami ponowienia.

• Rozszerzanie obciążenia związanego z klientami

  Jeśli testujesz na wysokich poziomach przepływności (>50 000 RU/s), aplikacja kliencka może stać się wąskim gardłem spowodowanym ograniczeniem użycia procesora CPU lub sieci. Jeśli osiągniesz ten punkt, możesz kontynuować wypychanie konta usługi Azure Cosmos DB, skalując aplikacje klienckie na wielu serwerach.

• Używanie adresowania opartego na nazwach

  Użyj adresowania opartego na nazwach, gdzie linki mają format dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId, a nie SelfLinks (_self), które mają format dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> , aby uniknąć pobierania identyfikatorów ResourceId wszystkich zasobów używanych do konstruowania łącza. Ponadto, ponieważ te zasoby są tworzone ponownie (prawdopodobnie o tej samej nazwie), buforowanie ich może nie pomóc.

• Dostosuj rozmiar strony dla zapytań/kanałów informacyjnych, aby poprawić wydajność

  Podczas wykonywania zbiorczego odczytu dokumentów przy użyciu funkcji źródła danych odczytu (na przykład readDocuments) lub podczas wystawiania zapytania SQL wyniki są zwracane w sposób segmentowany, jeśli zestaw wyników jest zbyt duży. Domyślnie wyniki są zwracane we fragmentach 100 elementów lub 1 MB, w zależności od tego, który limit zostanie osiągnięty jako pierwszy.

  Aby zmniejszyć liczbę zapytań sieciowych wymaganych do pobrania wszystkich odpowiednich wyników, można zwiększyć rozmiar strony przy użyciu nagłówka żądania x-ms-max-item-count do 1000. W przypadkach, gdy trzeba wyświetlić tylko kilka wyników, na przykład jeśli interfejs użytkownika lub interfejs API aplikacji zwróci tylko 10 wyników naraz, możesz również zmniejszyć rozmiar strony do 10, aby zmniejszyć przepływność zużywaną dla operacji odczytu i zapytań.

  Rozmiar strony można również ustawić przy użyciu metody setMaxItemCount.

• Użyj odpowiedniego harmonogramu (unikaj kradzieży wątków we/wy pętli zdarzeń)

  Asynchroniczny zestaw Azure Cosmos DB Java SDK w wersji 2 używa netty do nieblokujących operacji we/wy. Zestaw SDK używa do wykonywania operacji we/wy stałej liczby wątków Netty pętli zdarzeń operacji we/wy (równej liczbie rdzeni procesora CPU komputera). Observable zwracane przez API emituje wynik na jednym z udostępnionych wątków pętli zdarzeń IO Netty. Dlatego ważne jest, aby nie blokować współdzielonych wątków Netty pętli zdarzeń operacji we/wy. Wykonywanie intensywnej pracy procesora lub blokowanie operacji na wątku Netty w pętli zdarzeń IO może spowodować zakleszczenie lub znacznie zmniejszyć przepustowość SDK.

  Na przykład poniższy kod wykonuje intensywną pracę związaną z procesorem w wątku pętli zdarzeń Netty.

  Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

    Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument(
      collectionLink, document, null, true);
  
    createDocObs.subscribe(
      resourceResponse -> {
        //this is executed on eventloop IO netty thread.
        //the eventloop thread is shared and is meant to return back quickly.
        //
        // DON'T do this on eventloop IO netty thread.
        veryCpuIntensiveWork();
      });
  

  Po otrzymaniu wyniku, jeśli chcesz wykonać pracę obciążającą procesor, należy unikać robienia tego w wątku IO pętli zdarzeń Netty. Zamiast tego możesz podać własny harmonogram, aby udostępnić własny wątek do uruchamiania pracy.

  Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

    import rx.schedulers;
  
    Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument(
      collectionLink, document, null, true);
  
    createDocObs.subscribeOn(Schedulers.computation())
    subscribe(
      resourceResponse -> {
        // this is executed on threads provided by Scheduler.computation()
        // Schedulers.computation() should be used only when:
        //   1. The work is cpu intensive 
        //   2. You are not doing blocking IO, thread sleep, etc. in this thread against other resources.
        veryCpuIntensiveWork();
      });
  

  Na podstawie typu pracy należy użyć odpowiedniego istniejącego harmonogramu RxJava do pracy. Przeczytaj tutaj Schedulers.

  Aby uzyskać więcej informacji, zapoznaj się ze stroną GitHub dotyczącą asynchronicznego Java SDK dla Azure Cosmos DB w wersji 2.

• Wyłączanie rejestrowania netty

  Rejestrowanie biblioteki Netty jest zbyt szczegółowe i musi być wyłączone (wyłączenie logowania w konfiguracji może nie wystarczyć), aby uniknąć dodatkowych kosztów zużycia CPU. Jeśli nie jesteś w trybie debugowania, wyłącz rejestrowanie netty całkowicie. Jeśli więc używasz usługi log4j do usunięcia dodatkowych kosztów procesora CPU ponoszonych przez org.apache.log4j.Category.callAppenders() netty, dodaj następujący wiersz do bazy kodu:

  org.apache.log4j.Logger.getLogger("io.netty").setLevel(org.apache.log4j.Level.OFF);
  

• Limit zasobów otwartych plików systemu operacyjnego

  Niektóre systemy Linux (takie jak Red Hat) mają górny limit liczby otwartych plików, a co za tym idzie, ograniczają łączną liczbę połączeń. Uruchom następujące polecenie, aby wyświetlić bieżące limity:

  ulimit -a
  

  Liczba otwartych plików (nofile) musi być wystarczająco duża, aby mieć wystarczającą ilość miejsca dla skonfigurowanego rozmiaru puli połączeń i innych otwartych plików przez system operacyjny. Można go zmodyfikować, aby umożliwić większy rozmiar puli połączeń.

  Otwórz plik limits.conf:

  vim /etc/security/limits.conf
  

  Dodaj/zmodyfikuj następujące wiersze:

  * - nofile 100000
  

Zasady indeksowania

• Wyklucz nieużywane ścieżki z indeksowania w celu przyspieszenia operacji zapisu

  Zasady indeksowania usługi Azure Cosmos DB umożliwiają określenie ścieżek dokumentów do uwzględnienia lub wykluczenia z indeksowania przy użyciu ścieżek indeksowania (setIncludedPaths i setExcludedPaths). Użycie ścieżek indeksowania może oferować lepszą wydajność zapisu i niższy magazyn indeksów w scenariuszach, w których wzorce zapytań są znane wcześniej, ponieważ koszty indeksowania są bezpośrednio skorelowane z liczbą indeksowanych unikatowych ścieżek. Na przykład poniższy kod pokazuje, jak wykluczyć całą sekcję dokumentów (znaną również jako poddrzewo) z indeksowania przy użyciu symbolu wieloznakowego "*".

  Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

  Index numberIndex = Index.Range(DataType.Number);
  numberIndex.set("precision", -1);
  indexes.add(numberIndex);
  includedPath.setIndexes(indexes);
  includedPaths.add(includedPath);
  indexingPolicy.setIncludedPaths(includedPaths);
  collectionDefinition.setIndexingPolicy(indexingPolicy);
  

  Aby uzyskać więcej informacji, zobacz Zasady indeksowania usługi Azure Cosmos DB.

Throughput

• Mierzenie i dostrajanie do niższych jednostek żądań na sekundę

  Usługa Azure Cosmos DB oferuje bogaty zestaw operacji bazodanowych, w tym zapytania relacyjne i hierarchiczne z funkcjami zdefiniowanymi przez użytkownika, procedurami przechowywanymi i wyzwalaczami — wszystkie działają na dokumentach w kolekcji bazy danych. Koszt związany z każdą z tych operacji zależy od użycia CPU, operacji wejścia/wyjścia oraz pamięci wymaganej do wykonania operacji. Zamiast myśleć o zasobach sprzętowych i zarządzaniu nimi, możesz traktować jednostkę żądania (RU) jako pojedynczą miarę dla zasobów wymaganych do wykonywania różnych operacji bazy danych i obsługi żądania aplikacji.

  Przepustowość jest przydzielana na podstawie liczby jednostek żądań ustawionych dla każdego kontenera. Konsumpcja jednostek żądania jest oceniana jako prędkość na sekundę. Aplikacje, które przekraczają przydzieloną liczbę jednostek żądań dla kontenera, są ograniczone do chwili, gdy poziom szybkości spadnie poniżej przydzielonego poziomu dla kontenera. Jeśli aplikacja wymaga wyższego poziomu przepływności, możesz zwiększyć przepływność, aprowizując dodatkowe jednostki żądań.

  Złożoność zapytania ma wpływ na liczbę jednostek żądania używanych dla operacji. Liczba predykatów, charakter predykatów, liczba funkcji zdefiniowanych przez użytkownika i rozmiar zestawu danych źródłowych wpływają na koszt operacji zapytań.

  Aby zmierzyć obciążenie dowolnej operacji (tworzenia, aktualizacji lub usuwania), sprawdź nagłówek x-ms-request-charge, aby określić liczbę jednostek żądań zużywanych przez te operacje. Możesz również przyjrzeć się równoważnej właściwości RequestCharge w elemencie ResourceResponse<T> lub FeedResponse<T>.

  Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)

  ResourceResponse<Document> response = asyncClient.createDocument(collectionLink, documentDefinition, null,
                                                   false).toBlocking.single();
  response.getRequestCharge();
  

  Opłata za żądanie zwrócona w tym nagłówku jest ułamkiem przydzielonej przepustowości. Jeśli na przykład masz aprowizowaną wartość 2000 RU/s, a poprzednie zapytanie zwróci 1000 1 KB dokumentów, koszt operacji wynosi 1000. W związku z tym w ciągu jednej sekundy serwer honoruje tylko dwa takie żądania przed ograniczeniem liczby kolejnych żądań. Aby uzyskać więcej informacji, zobacz Request units and the request unit calculator (Jednostki żądań i kalkulator jednostek żądania).

• Obsługa limitowania szybkości żądań/przekroczenie limitu żądań

  Gdy klient próbuje przekroczyć zarezerwowaną przepływność dla konta, nie ma spadku wydajności na serwerze i nie ma użycia pojemności przepływności poza poziomem zarezerwowanym. Serwer zakończy w sposób prewencyjny żądanie z RequestRateTooLarge (kod stanu HTTP 429) i zwróci nagłówek x-ms-retry-after-ms wskazujący czas, jaki użytkownik musi poczekać w milisekundach, przed ponownym wysłaniem żądania.

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

  Wszystkie zestawy SDK niejawnie przechwytują tę odpowiedź, respektują nagłówek retry-after określony przez serwer i ponawiają żądanie. Jeśli twoje konto nie jest używane współbieżnie przez wielu klientów, następne ponowienie próby powiedzie się.

  Jeśli masz więcej niż jednego klienta działających skumulowanie nieprzerwanie powyżej limitu szybkości zapytań, domyślnie ustawiona przez klienta liczba ponownych prób, wynosząca obecnie 9, może nie wystarczyć; w takim przypadku klient wywołuje wyjątek DocumentClientException z kodem stanu 429 do aplikacji. Domyślną liczbę ponownych prób można zmienić przy użyciu polecenia setRetryOptions w wystąpieniu ConnectionPolicy. Domyślnie wyjątek DocumentClientException z kodem stanu 429 jest zwracany po skumulowanym czasie oczekiwania wynoszącym 30 sekund, jeśli żądanie nadal przekracza limit szybkości żądania. Dzieje się tak nawet wtedy, gdy bieżąca liczba ponownych prób jest mniejsza niż maksymalna liczba ponownych prób, może to być wartość domyślna 9 lub wartość zdefiniowana przez użytkownika.

  Chociaż automatyczne zachowanie ponawiania prób pomaga zwiększyć odporność i użyteczność dla większości aplikacji, może to być sprzeczne podczas wykonywania testów porównawczych wydajności, zwłaszcza podczas mierzenia opóźnienia. Obserwowane przez klienta opóźnienie wzrośnie, jeśli eksperyment osiągnie ograniczenie przepustowości serwera i spowoduje, że zestaw SDK klienta ponawia próbę w trybie dyskretnym. Aby uniknąć skoków opóźnień podczas eksperymentów wydajności, zmierz zasoby zwracane przez każdą operację i upewnij się, że żądania działają poniżej zarezerwowanej przepustowości. Aby uzyskać więcej informacji, zobacz Request units (Jednostki żądań).

• Projektowanie mniejszych dokumentów dla większej przepustowości

  Opłata za żądanie (koszt przetwarzania żądań) danej operacji jest bezpośrednio skorelowana z rozmiarem dokumentu. Operacje na dużych dokumentach kosztują więcej niż operacje dla małych dokumentów.

Dalsze kroki

Aby dowiedzieć się więcej na temat projektowania aplikacji pod kątem skalowania i wysokiej wydajności, zobacz Partycjonowanie i skalowanie w usłudze Azure Cosmos DB.