Condividi tramite

Diagnosticare e risolvere i problemi relativi alle eccezioni di timeout delle richieste di Azure Cosmos DB per NoSQL .NET SDK

  • Si applica a: ✅ NoSQL

L'errore HTTP 408 si verifica se il software development kit (SDK) non è riuscito a completare la richiesta prima del limite di timeout.

È importante assicurarsi che la progettazione dell'applicazione stia seguendo la guida per progettare applicazioni resilienti con Azure Cosmos DB per NoSQL SDK per assicurarsi che reagisca correttamente a condizioni di rete diverse. La tua applicazione dovrebbe disporre di meccanismi di ripetizione per errori di timeout, poiché questi errori sono solitamente previsti in un sistema distribuito.

Quando si valuta il caso degli errori di timeout, valutare la possibilità di intraprendere le azioni seguenti:

  • Misurare l'effetto nel volume di operazioni interessate rispetto alle operazioni riuscite.
  • Determinare se l'effetto rientra nelle soglie definite nel contratto di servizio.
  • Valutate come la latenza P99 o la disponibilità siano influenzate.
  • Identificare se l'errore interessa tutte le istanze dell'applicazione o solo un subset.

Personalizzare il timeout nell’SDK per .NET di Azure Cosmos DB for NoSQL

L'SDK ha due alternative distinte per controllare il timeout, ognuna con un ambito diverso.

Timeout a livello di richiesta

La ConnectionPolicy.RequestTimeout configurazione (o ConnectionPolicy.RequestTimeout per SDK v2) consente di impostare un timeout per la richiesta di rete dopo che la richiesta ha lasciato l'SDK ed è in rete, fino a quando non viene ricevuta una risposta.

La ConnectionPolicy.OpenTcpConnectionTimeout configurazione (o ConnectionPolicy.OpenTcpConnectionTimeout per SDK v2) consente di impostare un timeout per il tempo impiegato per l'apertura di una connessione iniziale. Una volta aperta una connessione, le richieste successive usano la connessione.

Un'operazione avviata da un utente può estendersi su più richieste di rete, ad esempio con ripetuti tentativi. Queste due configurazioni sono per richiesta, non end-to-end per un'operazione.

CancellationToken

Tutte le operazioni asincrone nell'SDK hanno un parametro CancellationToken facoltativo. Questo parametro CancellationToken viene usato nell'intera operazione, in tutte le richieste di rete e i retry. Tra le richieste di rete, il token di annullamento potrebbe essere controllato e un'operazione potrebbe essere annullata se il token correlato è scaduto. Il token di annullamento deve essere usato per definire un timeout previsto approssimativo nell'ambito dell'operazione.

Annotazioni

Il CancellationToken parametro è un meccanismo in cui la libreria controlla se l'annullamento può causare uno stato non valido. L'operazione potrebbe non essere annullata esattamente quando il tempo definito nell'annullamento è scaduto. Dopo la scadenza, eseguirà invece l'annullamento quando sarà sicuro farlo.

Procedura di risoluzione dei problemi

L'elenco seguente contiene cause note e soluzioni per le eccezioni di timeout delle richieste.

CosmosOperationCanceledException

Questo tipo di eccezione è comune quando l'applicazione passa CancellationTokens alle operazioni SDK. L'SDK controlla lo stato dei CancellationTokententativiintermedi e, se CancellationToken viene annullato, interrompe l'operazione in corso generando questa eccezione.

L'eccezione Message / ToString() indica anche lo stato del tuo CancellationToken tramite Cancellation Token has expired: true e contiene Diagnostics, che include il contesto dell'annullamento per le richieste coinvolte.

Queste eccezioni sono sicure da ripetere e possono essere considerate eccezioni di timeout in termini di ripetizione di tentativi.

Soluzione

Verifica l'orario configurato nel tuo CancellationToken. Assicurarsi quindi che questo valore sia maggiore del timeout della richiesta e della proprietà CosmosClientOptions.OpenTcpConnectionTimeout (se si sta utilizzando la modalità diretta). Se il tempo disponibile in CancellationToken è inferiore al timeout configurato e l'SDK riscontra problemi di connettività temporanei, non può ripetere il tentativo e genera un'eccezione CosmosOperationCanceledException.

Uso elevato della CPU

L'utilizzo elevato della CPU è il caso più comune. Per una latenza ottimale, l'utilizzo della CPU deve essere approssimativamente del 40%. Usare 10 i secondi come intervallo per monitorare l'utilizzo massimo (non medio) della CPU. I picchi di CPU sono più comuni con query tra partizioni in cui potrebbero essere eseguite più connessioni per una singola query.

Il timeout contiene Diagnostics, contenente a sua volta:

"systemHistory": [
  {
    "dateUtc": "2021-11-17T23:38:28.3115496Z",
    "cpu": 16.731,
    "memory": 9024120.000,
    "threadInfo": {
      "isThreadStarving": "False",
      ...
    }
  },
  {
    "dateUtc": "2021-11-17T23:38:28.3115496Z",
    "cpu": 16.731,
    "memory": 9024120.000,
    "threadInfo": {
      "isThreadStarving": "False",
      ...
    }
  },
  ...
]
  • Se i valori superano il cpu 70%, è probabile che l'esaurimento della CPU abbia causato il timeout. In questo caso, la soluzione consiste nell'analizzare l'origine dell'utilizzo elevato della CPU e ridurla o ridimensionare il computer a dimensioni di risorse maggiori.
  • Se i nodi threadInfo/isThreadStarving hanno valori True, la causa è la scadenza dei thread. In questo caso, la soluzione consiste nell'analizzare le origini della scarsità di thread (thread potenzialmente bloccati) oppure scalare le macchine a risorse di dimensioni maggiori.
  • Se il tempo tra le misurazioni dateUtc non è di circa 10 secondi, indicherà anche conflitti nel pool di thread. La CPU viene misurata ogni 10 secondi come attività indipendente accodata nel pool di thread. Se il tempo tra la misurazione è più lungo, indicherà che le attività asincrone non sono in grado di essere elaborate in modo tempestivo. Questo scenario si verifica in genere quando si eseguono chiamate di blocco su codice asincrono nel codice dell'applicazione.

Soluzione

L'applicazione client che usa l'SDK deve essere ridimensionata o ridotta.

La disponibilità del socket o della porta potrebbe essere bassa

Quando la soluzione è in esecuzione in Azure, i client che usano .NET SDK possono raggiungere l'esaurimento delle porte SNAT (Source Network Address Translation) di Azure.

Soluzione 1

Se si effettua l'esecuzione su macchine virtuali di Azure, seguire la guida sull'esaurimento delle porte SNAT.

Soluzione 2

Se si utilizza Azure App Service, seguire la guida alla risoluzione degli errori di connessione e utilizzare la diagnostica del Servizio app.

Soluzione 3

Se stai eseguendo Azure Functions, verifica di seguire la raccomandazione di Azure Functions di mantenere i client singleton o statici per tutti i servizi coinvolti (incluso Azure Cosmos DB per NoSQL). Controllare i limiti di servizio in base al tipo e alle dimensioni del proprio hosting dell'app per le funzioni.

Soluzione 4

Se si usa un proxy HTTP, assicurarsi che possa supportare il numero di connessioni configurate in ConnectionPolicy dell'SDK. In caso contrario, verranno riscontrati problemi di connessione.

Creare più istanze client

La creazione di più istanze client può causare conflitti di connessione e problemi di timeout. La Diagnostica contiene due proprietà pertinenti:

{
  "NumberOfClientsCreated": X,
  "NumberOfActiveClients": Y,
}

NumberOfClientsCreated tiene traccia del numero di volte in cui è stato creato un CosmosClient all'interno dello stesso AppDomain e NumberOfActiveClients tiene traccia dei client attivi (non eliminati). L'aspettativa è che se viene seguito il modello singleton, X corrisponde al numero di account con cui l'applicazione funziona e che X è uguale a Y.

Se X è maggiore di Y, significa che l'applicazione sta creando ed eliminando istanze client. Questo scenario può causare conflitti di connessione e/o contesa della CPU.

Soluzione

Seguire i suggerimenti sulle prestazioni e utilizzare una singola istanza di CosmosClient per account in un intero processo. Evitare di creare ed eliminare i client software.

Chiave di partizione calda

Azure Cosmos DB per NoSQL distribuisce uniformemente il throughput complessivo fornito tra le partizioni fisiche. Quando è presente una partizione calda, una o più chiavi di partizione logica su una partizione fisica stanno consumando tutte le Unità di Richiesta della partizione fisica per secondo (UR/s). Allo stesso tempo, le RU/s su altre partizioni fisiche non vengono utilizzate. Come sintomo, le UR/s totali utilizzabili sono inferiori alle UR/s complessive di cui è stato effettuato il provisioning nel database o nel contenitore, ma si verificano limitazioni (errori 429) nelle richieste alla chiave di partizione logica 'a caldo'. Usare la Normalized RU Consumption metrica per verificare se il carico di lavoro incontra una partizione calda.

Soluzione

Scegliere una chiave di partizione valida che distribuisca in modo uniforme il volume e l'archiviazione delle richieste. Leggere come modificare la chiave di partizione.

Livello elevato di concorrenza

L'applicazione sta eseguendo un livello elevato di concorrenza, che può causare contese sul canale.

Soluzione

L'applicazione client che usa l'SDK deve essere ridimensionata o ridotta.

Richieste o risposte di grandi dimensioni

Richieste o risposte di grandi dimensioni possono causare un blocco head-of-line sul canale ed esacerbare la contesa, anche con un grado di concorrenza relativamente basso.

Soluzione

L'applicazione client che usa l'SDK deve essere ridimensionata o ridotta.

La percentuale di errori rientra nel contratto di servizio di Azure Cosmos DB per NoSQL

L'applicazione deve essere in grado di gestire gli errori temporanei e riprovare quando necessario. Eventuali eccezioni 408 non vengono ritentate perché nei percorsi di creazione non è possibile sapere se il servizio ha creato o meno l'elemento. L'invio dello stesso elemento per create causa un'eccezione di conflitto. La logica di business delle applicazioni utente potrebbe avere una logica personalizzata per gestire i conflitti, che potrebbe interrompere l'ambiguità di un elemento esistente rispetto al conflitto dovuto a un nuovo tentativo di creazione.

La frequenza di errore viola il contratto di servizio di Azure Cosmos DB per NoSQL

Contattare il supporto di Azure.

Contenuti correlati

  • Last updated on