Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
De HTTP 408-fout treedt op als de software development kit (SDK) de aanvraag niet kon voltooien voordat de time-outlimiet optrad.
Stappen voor probleemoplossing
De volgende lijst bevat bekende oorzaken en oplossingen voor time-out uitzonderingen van verzoeken.
End-tot-end time-outbeleid
Er zijn scenario's waarin 408-netwerktijdoverschrijdingsfouten optreden, zelfs wanneer alle preventieve oplossingen hier worden toegepast. Een algemene best practice voor het verminderen van tail-latentie en het verbeteren van de beschikbaarheid in deze scenario's is het implementeren van end-to-end time-outbeleid. Tail-latentie wordt verminderd door sneller te mislukken en aanvraageenheden en rekenkosten aan de clientzijde worden verlaagd door nieuwe pogingen na de time-out te stoppen. De time-outduur kan worden ingesteld op CosmosItemRequestOptions. De opties kunnen vervolgens worden doorgegeven aan elke aanvraag die wordt verzonden naar Azure Cosmos DB for NoSQL:
CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);
container.readItem("id", new PartitionKey("pk"), options, TestObject.class);
Bestaande problemen
Als uw verzoeken voor langere tijd blijven hangen of vaker een time-out krijgen, moet u de Java v4 SDK bijwerken naar de nieuwste versie. OPMERKING: We raden u ten zeerste aan de versie 4.18.0 en hoger te gebruiken. Bekijk de releaseopmerkingen voor java v4 SDK voor meer informatie.
Hoog CPU-gebruik
Hoog CPU-gebruik is het meest voorkomende geval. Voor een optimale latentie moet het CPU-gebruik ongeveer veertig procent zijn. Gebruik 10 seconden als interval om het maximale (niet gemiddelde) CPU-gebruik te bewaken. CPU-pieken komen vaker voor bij query's tussen partities, waarbij meerdere verbindingen voor één query tot stand gebracht kunnen worden.
Solution
De clienttoepassing die gebruikmaakt van de SDK, moet dan omhoog of omlaag worden geschaald.
Verbindingsbeperking
Verbindingsbeperking kan optreden vanwege een verbindingslimiet op een hostcomputer of SNAT-poortuitputting (Azure Source Network Address Translation).
Verbindingslimiet op een hostcomputer
Sommige Linux-systemen, zoals Red Hat, hebben een bovengrens voor het totale aantal geopende bestanden. Sockets in Linux worden geïmplementeerd als bestanden, dus dit aantal beperkt ook het totale aantal verbindingen. Voer de volgende opdracht uit.
ulimit -a
Solution
Het aantal maximaal toegestane geopende bestanden, dat wordt aangeduid als nofile, moet ten minste 10.000 of meer zijn. Zie de prestatietips voor Azure Cosmos DB for NoSQL Java SDK v4 voor meer informatie.
De beschikbaarheid van sockets of poorten is mogelijk laag
Wanneer uw oplossing in Azure draait, kunnen clients die de Java SDK gebruiken Azure SNAT-poortuitputting ondervinden.
Oplossing 1
Als u azure-VM's gebruikt, volgt u de SNAT-poortuitputtingshandleiding.
Oplossing 2
Als u op Azure-app Service werkt, volgt u de handleiding voor het oplossen van verbindingsproblemen en gebruikt u diagnostische gegevens van App Service.
Oplossing 3
Als u azure Functions uitvoert, controleert u of u de aanbeveling van Azure Functions volgt om singleton- of statische clients te onderhouden voor alle betrokken services (inclusief Azure Cosmos DB voor NoSQL). Controleer de servicelimieten op basis van het type en de grootte van uw functie-app-hosting.
Oplossing 4
Als u een HTTP-proxy gebruikt, moet u ervoor zorgen dat deze het aantal verbindingen ondersteunt dat is geconfigureerd in de SDK GatewayConnectionConfig. Anders ondervindt u verbindingsproblemen.
Meerdere clientexemplaren maken
Het maken van meerdere clientexemplaren kan leiden tot verbindingstrijdigheid en time-outproblemen.
Oplossing 1
Volg de tips voor prestaties en gebruik één CosmosClient-exemplaar in een hele toepassing.
Oplossing 2
Als singleton CosmosClient niet mogelijk is in een toepassing, raden we u aan verbinding te delen via meerdere Azure Cosmos DB for NoSQL-clients via deze API connectionSharingAcrossClientsEnabled(true) in CosmosClient.
Wanneer u meerdere exemplaren van de client hebt die communiceren met meerdere accounts, kunt u met deze instelling verbinding delen in de directe modus. Deze modus is alleen ingeschakeld als het delen van verbindingen mogelijk is tussen exemplaren van de Azure Cosmos DB for NoSQL-client. Houd er rekening mee dat bij het instellen van deze optie voor delen de configuratie van de verbinding (bijvoorbeeld een time-outconfiguratie voor sockets, time-outconfiguratie voor inactiviteit) van de eerste geïnstantieerde client wordt gebruikt voor alle andere clientexemplaren.
Heetlopende partitiesleutel
Azure Cosmos DB for NoSQL distribueert de totale ingerichte doorvoer gelijkmatig over fysieke partities. Wanneer er sprake is van een hotte partitie, verbruiken een of meer logische partitiesleutels op een fysieke partitie alle aanvraageenheden per seconde (RU/s) van die fysieke partitie. Tegelijkertijd blijven de RU/s op andere fysieke partities ongebruikt. Een symptoom is dat de totale verbruikte RU/s lager zijn dan de totale ingerichte RU/s in de database of container, maar u ziet nog steeds snelheidsbeperking (429-fouten) voor de aanvragen tegen de hete logische partitiesleutel. Gebruik de genormaliseerde RU-verbruik-metriek om te zien of de belasting een hot partitie ondervindt.
Solution
Kies een goede partitiesleutel waarmee het aanvraagvolume en de opslag gelijkmatig worden gedistribueerd. Meer informatie over het wijzigen van uw partitiesleutel.
Hoge mate van gelijktijdigheid
De toepassing bereikt een hoog niveau van gelijktijdigheid, wat kan leiden tot concurrentie op het kanaal.
Solution
De clienttoepassing die gebruikmaakt van de SDK, moet dan omhoog of omlaag worden geschaald.
Grote aanvragen of antwoorden
Grote aanvragen of antwoorden kunnen leiden tot head-of-line blokkering op het kanaal en wedijver verergeren, ook al is de mate van gelijktijdigheid relatief laag.
Solution
De clienttoepassing die gebruikmaakt van de SDK, moet dan omhoog of omlaag worden geschaald.
Het foutpercentage valt binnen de SLA (Service Level Agreement) van Azure Cosmos DB voor NoSQL.
De toepassing moet tijdelijke fouten kunnen afhandelen en het opnieuw proberen wanneer dat nodig is. 408 uitzonderingen worden niet opnieuw geprobeerd omdat het bij het creëren van paden onmogelijk is om te weten of de service het item heeft aangemaakt of niet. Het verzenden van hetzelfde item voor het maken veroorzaakt een conflict-uitzondering. Bedrijfslogica van gebruikerstoepassingen kan aangepaste logica hebben voor het afhandelen van conflicten, waardoor de dubbelzinnigheid tussen een bestaand item en een conflict bij het opnieuw proberen te creëren wordt opgeheven.
Het uitvalpercentage overschrijdt de SLA van Azure Cosmos DB voor NoSQL.
Neem contact op met de ondersteuning van Azure.
Verwante inhoud
- Problemen vaststellen en oplossen wanneer u de Azure Cosmos DB for NoSQL Java v4 SDK gebruikt.
- Meer informatie over prestatierichtlijnen voor Java v4.