Porady dotyczące wydajności dla zestawu Java SDK asynchronicznego usługi Azure Cosmos DB w wersji 2
DOTYCZY: 
NoSQL
Ważne
Nie jest to najnowszy zestaw Java SDK dla usługi Azure Cosmos DB! Należy uaktualnić projekt do zestawu Java SDK usługi Azure Cosmos DB w wersji 4, a następnie przeczytać przewodnik porady dotyczące wydajności zestawu Java SDK usługi Azure Cosmos DB w wersji 4. Postępuj zgodnie z instrukcjami w przewodniku Migrate to Azure Cosmos DB Java SDK v4 (Migrowanie do zestawu Java SDK usługi Azure Cosmos DB w wersji 4 ) i przewodniku Reactor vs RxJava w celu uaktualnienia.
Porady dotyczące wydajności w tym artykule dotyczą tylko zestawu Java SDK asynchronicznego zestawu Java SDK usługi Azure Cosmos DB w wersji 2. Aby uzyskać więcej informacji, zobacz Przewodnik rozwiązywania problemów z zestawem Java SDK asynchronicznego zestawu Java SDK usługi Azure Cosmos DB w wersji 2, repozytorium Maven i zestaw Azure Cosmos DB Async Java SDK w wersji 2.
Ważne
31 sierpnia 2024 r. zestaw JAVA SDK asynchroniczny usługi Azure Cosmos DB w wersji 2.x zostanie wycofany; zestaw SDK i wszystkie aplikacje korzystające z zestawu SDK będą nadal działać; Usługa Azure Cosmos DB po prostu przestanie zapewniać dalszą konserwację i obsługę tego zestawu SDK. Zalecamy wykonanie powyższych instrukcji, aby przeprowadzić migrację do zestawu Java SDK usługi Azure Cosmos DB w wersji 4.
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łączenie: 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. Połączenie ionMode to ustawienie konfiguracji klucza dostępne do konfigurowania Połączenie ionPolicy klienta. W przypadku zestawu JAVA SDK asynchronicznego usługi Azure Cosmos DB w wersji 2 dostępne są dwa dostępne Połączenie ionModes:
Tryb bramy jest obsługiwany na wszystkich platformach ZESTAWU 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. Kompromis wydajności polega jednak na tym, że tryb bramy obejmuje dodatkowy przeskok sieciowy 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.
Połączenie ionMode jest konfigurowany podczas budowy wystąpienia DocumentClient z parametrem Połączenie ionPolicy.
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ć w zależności od trasy podjętej przez żądanie w zależności od trasy, która przechodzi 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 strony informacji o wersji zestawu Java SDK asynchronicznego zestawu Java SDK w wersji 2 usługi Azure Cosmos DB, 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 Połączenie ionPolicy
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 zestawie Azure Cosmos DB Async Java SDK w wersji 2 tryb bezpośredni jest najlepszym wyborem, aby poprawić wydajność bazy danych przy użyciu 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 żądania, czyli 30 żądań głębokich. 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 Połączenie ionPolicy 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 używasz 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 wartości bezczynnościEndpointTimeout na 0 (czyli bez limitu czasu).
Opcja konfiguracji Wartość domyślna bufferPageSize 8192 Connectiontimeout "PT1M" idleChannelTimeout "PT0S" idleEndpointTimeout "PT1M10S" maxBufferCapacity 8388608 maxChannelsPerEndpoint 10 maxRequestsPerChannel 30 receiveHangDetectionTime "PT1M5S" requestExpiryInterval "PT5S" requestTimeout "PT1M" requestTimerResolution "PT0.5S" sendHangDetectionTime "PT10S" Shutdowntimeout "PT15S"
Porady dotyczące programowania dla trybu bezpośredniego
Zapoznaj się z artykułem dotyczącym rozwiązywania problemów z zestawem Java SDK asynchronicznego języka Java w usłudze Azure Cosmos DB w wersji 2, aby rozwiązać wszelkie problemy z zestawem SDK.
Niektóre ważne porady dotyczące programowania podczas korzystania z trybu bezpośredniego:
Używaj wielowątków w aplikacji do wydajnego transferu danych TCP — po wykonaniu żądania aplikacja powinna subskrybować odbieranie danych w innym wątku. Nie wymusza to niezamierzonej operacji "półdupleksu", a kolejne żądania są blokowane 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 wystąpić zwiększone opóźnienie i zaleca się zduplikować dodatkowy wątek, który oczekuje na odpowiedź z innego magazynu danych.
- Podstawowe operacje we/wy sieci w asynchroniczny zestaw JAVA SDK usługi Azure Cosmos DB w wersji 2 są zarządzane przez platformę Netty. Zapoznaj się z tymi wskazówkami dotyczącymi unikania wzorców kodowania, które blokują wątki we/wy 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.
Dostrajanie zapytań równoległych dla kolekcji 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 setMaxDegreeOfParallelism:
Zapytania równoległe działają równolegle, wykonując zapytania 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 partycjonowana w taki sposób, że wszystkie lub większość danych zwracanych przez zapytanie koncentruje się w kilku partycjach (jedna partycja w najgorszym przypadku), wydajność zapytania byłaby wąskim gardłem dla tych partycji.
Zestaw dostrajaniaMaxBufferedItemCount:
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 ulepszaniu opóźnienia zapytania. setMaxBufferedItemCount ogranicza liczbę wstępnie pobranych wyników. Ustawienie parametru setMaxBufferedItemCount na oczekiwaną liczbę zwróconych wyników (lub wyższej liczby) umożliwia zapytaniu uzyskanie maksymalnej korzyści z pobierania z góry.
Wstępne pobieranie działa tak samo niezależnie od 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 wycofywania gwarantuje, że spędzasz minimalny czas oczekiwania między ponawianiem prób.
Skalowanie w poziomie obciążenia klienta
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ą formatdbs/<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.Dostrajanie rozmiaru strony dla zapytań/kanałów informacyjnych odczytu w celu uzyskania lepszej wydajności
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ę rund sieci 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 JAVA SDK usługi Azure Cosmos DB w wersji 2 używa netty do blokowania 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). Obserwowany zwracany przez interfejs API emituje wynik w jednym z udostępnionych wątków netty pętli zdarzeń we/wy. Dlatego ważne jest, aby nie blokować współdzielonych wątków Netty pętli zdarzeń operacji we/wy. Wykonywanie intensywnej pracy procesora CPU lub blokowanie operacji na wątku netty pętli zdarzeń we/wy może spowodować zakleszczenie lub znaczne zmniejszenie przepływności zestawu SDK.
Na przykład poniższy kod wykonuje pracę intensywnie korzystającą z procesora CPU w wątku netty pętli zdarzeń:
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ę intensywnie korzystającą z procesora CPU w wyniku, należy unikać tego w wątku netty pętli zdarzeń. 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ą usługi GitHub dotyczącą zestawu Java SDK asynchronicznego zestawu Java SDK usługi Azure Cosmos DB w wersji 2.
Wyłączanie rejestrowania netty
Rejestrowanie biblioteki Netty jest czatty i musi być wyłączone (pomijanie logowania w konfiguracji może nie wystarczyć), aby uniknąć dodatkowych kosztów procesora 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, więc łączna liczba połączeń. Uruchom następujące polecenie, aby wyświetlić bieżące limity:
ulimit -aLiczba 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.confDodaj/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.
Produktywność
Mierzenie i dostrajanie do niższych jednostek żądania/drugiego użycia
Usługa Azure Cosmos DB oferuje bogaty zestaw operacji bazy danych, w tym zapytania relacyjne i hierarchiczne z funkcjami zdefiniowanymi przez użytkownika, procedurami składowanymi i wyzwalaczami — wszystkie operacje na dokumentach w kolekcji bazy danych. Koszt związany z każdą z tych operacji zależy od procesora, danych We/Wy i pamięci wymaganej do wykonania danej 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.
Przepływność jest aprowizowana na podstawie liczby jednostek żądań ustawionych dla każdego kontenera. Użycie jednostek żądania jest oceniane jako szybkość na sekundę. Aplikacje, które przekraczają aprowizowaną liczbę jednostek żądań dla kontenera, są ograniczone do momentu spadku szybkości poniżej aprowizowanego 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 (tworzenie, aktualizowanie lub usuwanie), sprawdź nagłówek x-ms-request-charge , aby zmierzyć liczbę jednostek żądań uż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 aprowizowanej przepływnoś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 ograniczania szybkości/szybkości żądań jest zbyt duża
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 z preemptively zakończy żądanie requestRateTooLarge (kod stanu HTTP 429) i zwróci nagłówek x-ms-retry-after-ms wskazujący ilość czasu w milisekundach, że użytkownik musi czekać przed ponownego przypisania żądania.
HTTP Status 429, Status Line: RequestRateTooLarge x-ms-retry-after-ms :100Zestawy SDK przechwytują tę odpowiedź niejawnie, przestrzegają określonego przez serwer nagłówka ponawiania próby i ponów próbę żądania. 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 skumulowanie operacyjnego powyżej szybkości żądań, domyślna liczba ponownych prób jest obecnie ustawiona na 9 wewnętrznie przez klienta może nie wystarczyć; w takim przypadku klient zgłasza 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 Połączenie ionPolicy. Domyślnie wyjątek DocumentClientException z kodem stanu 429 jest zwracany po skumulowanym czasie oczekiwania wynoszącym 30 sekund, jeśli żądanie nadal działa powyżej 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 opłatę zwróconą przez każdą operację i upewnij się, że żądania działają poniżej zarezerwowanej stawki żądań. Aby uzyskać więcej informacji, zobacz Request units (Jednostki żądań).
Projektowanie pod kątem mniejszych dokumentów pod kątem większej przepływnoś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.
Następne 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.