View a markdown version of this page

Risoluzione dei problemi di latenza in Amazon DynamoDB - Amazon DynamoDB

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi di latenza in Amazon DynamoDB

Se il carico di lavoro sembra avere una latenza elevata, puoi analizzare la CloudWatch SuccessfulRequestLatency metrica e controllare la latenza media e la latenza mediana tramite le metriche percentili (p50) per vedere se è correlata a DynamoDB. Una certa variabilità nella metrica SuccessfulRequestLatency restituita è normale e i picchi occasionali (in particolare nelle statistiche Maximum e nei percentili elevati) non devono destare preoccupazione. Tuttavia, se la Average statistica o p50 (mediana) mostra un forte aumento e persiste, dovresti controllare il Service Health Dashboard e il Personal Health Dashboard per ulteriori informazioni. AWS Alcune possibili cause includono la dimensione dell’elemento nella tabella (un elemento da 1 KB e un elemento da 400 KB avranno una latenza diversa) o la dimensione della query (10 elementi rispetto a 100 elementi).

Le metriche percentili (p99, p90, ecc.) possono aiutare a comprendere meglio la distribuzione della latenza. Ad esempio:

  • p50 (mediana) mostra la latenza tipica del carico di lavoro.

  • p90 mostra che il 90% delle richieste è più veloce di questo valore.

  • p99 aiuta a identificare la latenza peggiore che riguarda l’1% delle richieste.

Valori di p99 elevati con valori p50 normali potrebbero indicare problemi sporadici che interessano una piccola parte delle richieste, mentre valori p50 costantemente elevati potrebbero suggerire un peggioramento delle prestazioni.

Nota

Per analizzare i valori percentili personalizzati (come p99,9), puoi inserire manualmente il percentile desiderato (ad esempio, p99,9) nel campo delle statistiche metriche. CloudWatch Ciò consente di valutare le distribuzioni di latenza oltre i percentili predefiniti elencati nel menu a discesa.

Sono previste alcune variazioni nelle metriche di latenza, in particolare nei percentili più alti, che possono essere rilevate come risultato di operazioni in DynamoDB-driven background che aiutano a mantenere un'elevata disponibilità e durata dei dati archiviati nelle tabelle DynamoDB o a problemi transitori dell'infrastruttura.

Se necessario, valuta la possibilità di aprire una richiesta di supporto e continua a valutare eventuali opzioni alternative disponibili per la tua applicazione (ad esempio l'evacuazione di una regione se hai un'architettura multiregionale) in base ai tuoi runbook. Supporto AWSÈ necessario registrare gli ID delle richieste lente e fornire questi ID a Supporto AWS quando si apre una richiesta di assistenza.

La metrica SuccessfulRequestLatency misura solo la latenza interna al servizio DynamoDB; l’attività lato client e i tempi di accesso alla rete non sono inclusi. Per saperne di più sulla latenza complessiva per le chiamate dal tuo client al servizio DynamoDB, puoi abilitare la registrazione delle metriche di latenza nel tuo SDK. AWS

Nota

Per la maggior parte delle operazioni singleton (operazioni che si applicano a un singolo elemento specificando completamente il valore della chiave primaria), DynamoDB fornisce un valore di Average SuccessfulRequestLatency pari a pochissimi millisecondi. Questo valore non include il sovraccarico di trasporto per il codice chiamante che accede all'endpoint DynamoDB. Per le operazioni sui dati con più elementi, la latenza varia in base a fattori quali la dimensione del set di risultati, la complessità delle strutture di dati restituite e le eventuali espressioni di condizione e di filtro applicate. Per operazioni con più elementi ripetute sullo stesso set di dati con gli stessi parametri, DynamoDB fornisce un'elevata coerenza per Average SuccessfulRequestLatency.

Prendi in considerazione una o più delle seguenti strategie per ridurre la latenza:

  • Riutilizzo delle connessioni: le richieste DynamoDB vengono effettuate tramite una sessione autenticata che per impostazione predefinita è HTTPS. L’avvio della connessione richiede più round trip e richiede tempo, pertanto la latenza della prima richiesta è superiore al normale rispetto alle richieste successive che riutilizzano la connessione. Le richieste su una connessione già inizializzata forniscono una bassa latenza costante di DynamoDB. Per evitare il sovraccarico della latenza necessaria nello stabilire nuove connessioni, è possibile implementare un meccanismo “keep-alive” inviando una richiesta GetItem ogni 30 secondi quando non vengono effettuate altre richieste.

  • Usa letture a coerenza finale: se la tua applicazione non richiede un'elevata consistenza di lettura, puoi utilizzare le letture a coerenza finale. Le letture a coerenza finale hanno un costo inferiore e possono provenire da più zone di disponibilità, permettendo la selezione di una zona di disponibilità ubicata nella stessa posizione del richiedente, il che riduce la latenza. Per ulteriori informazioni, consulta Coerenza di lettura di DynamoDB.

  • Implementazione dell’hedging delle richieste: per requisiti di latenza p99 molto bassi, prendi in considerazione l’implementazione dell’hedging delle richieste. Con l’hedging delle richieste, se la richiesta iniziale non riceve una risposta abbastanza rapidamente, invia una seconda richiesta equivalente e considera valida la prima risposta ricevuta. Ciò migliora la latenza di coda al costo di alcune richieste aggiuntive. È possibile decidere quanto aspettare prima di inviare la seconda richiesta. L’hedging è più facile per le letture. Per quanto riguarda le scritture, utilizza l’ordinamento basato sul timestamp per garantire che le richieste con hedging vengano trattate come se si verificassero al momento del primo tentativo, evitando aggiornamenti fuori ordine. Questo approccio è stato discusso in Timestamp writes for write hedging in Amazon DynamoDB.

  • Regolazione del timeout delle richieste e del comportamento delle ripetizioni dei tentativi: il percorso dal client a DynamoDB attraversa molti componenti, ognuno dei quali è progettato sulla base della ridondanza. Prendi in considerazione i seguenti aspetti:

    • Resilienza della rete

    • Timeout dei pacchetti TCP

    • L’architettura distribuita di DynamoDB

    I comportamenti degli SDK predefiniti sono ottimizzati per la maggior parte delle applicazioni. Tuttavia, è possibile implementare una strategia per anticipare l’errore (fail-fast) e regolare le impostazioni di timeout. Le richieste che richiedono molto più tempo del normale hanno meno probabilità di esito finale positivo. Attraverso l’anticipo dell’errore (fail fast) e la ripetizione dei tentativi, è possibile ottenere rapidamente un esito positivo attraverso un percorso diverso. La procedura è simile all’hedging delle richieste, ma termina la prima richiesta invece di consentirle di procedere.

    Evita di impostare valori di timeout troppo bassi. Timeout troppo bassi possono causare problemi di disponibilità indotti dal client. Ad esempio, un timeout del socket di 50 millisecondi potrebbe causare errori di connessione durante i picchi di latenza di rete, ad esempio quando ci si avvicina ai limiti di larghezza di banda delle istanze Amazon EC2 per il traffico a flusso singolo. Valuta attentamente i vantaggi di timeout più bassi rispetto ai potenziali rischi per la disponibilità delle applicazioni e preferisci l’hedging rispetto ai timeout brevi.

    Per un'utile discussione su questo argomento, consulta Ottimizzazione delle impostazioni di richiesta HTTP di AWS Java SDK per applicazioni Amazon DynamoDB che supportano la latenza.

  • Riduci la distanza tra il client e l'endpoint DynamoDB: se hai utenti distribuiti a livello globale, prendi in considerazione l'utilizzo di Tabelle globali: replica multi-attiva e multi-Regione. Con le tabelle globali, puoi replicare la tabella in AWS regioni specifiche in cui desideri che la tabella sia disponibile. È possibile posizionare una copia dei dati più vicino all’utente finale per ridurre la latenza di rete durante le operazioni di lettura e scrittura. Per ulteriori informazioni sull'uso efficace delle tabelle globali DynamoDB, consulta Using Amazon DynamoDB global tables in Prescriptive Guidance. AWS

  • Utilizzo della caching: in presenza di traffico a lettura intensiva, prendi in considerazione l’adozione di uno dei seguenti servizi di caching: