Qual è la differenza tra gli errori timeout del datastore di Appengine 5 e 11?

Question

Sto provando ad accelerare un gestore di richieste di Google App Engine che ha una chiamata di grande datastore PutMulti (500 entità) dividendola in gruppi di entità ed eseguendo concurrent goroutine per inviare più piccole chiamate PutMulti (100 entità ciascuna).

Prima di questo, ho ricevuto spesso l'errore del datastore Call error 11: Deadline exceeded (timeout) dalle mie chiamate PutMulti oltre la scadenza quando ho testato il gestore su molte richieste simultanee. Dopo la parallelizzazione, il gestore ha accelerato, ma ho ancora occasionalmente ricevuto quell'errore e anche un altro tipo di errore, API error 5 (datastore_v3: TIMEOUT): The datastore operation timed out, or the data was temporarily unavailable.

Questo errore 5 è dovuto a contesa nell'archivio dati e qual è la differenza tra gli errori 5 e 11?

Answer 1

Il primo errore visualizzato può essere solo il timeout in funzionamento normale, il secondo è probabile a causa di conflitto di scrittura. Ulteriori informazioni su questo: Gestione degli errori Datastore https://cloud.google.com/appengine/articles/handling_datastore_errors

Answer 2

Questi errori provengono da due posizioni diverse, il primo, l'errore di chiamata, è un errore locale causato da un timeout nel client RPC. Indica che c'è stato un timeout in attesa del completamento di un RPC. Il timeout RPC predefinito in google.golang.org/appengine è di 60 secondi.

Il secondo errore deriva dal lato del servizio. Questo errore indica che si è verificato un timeout durante l'esecuzione delle operazioni all'interno del datastore. Alcune di queste operazioni hanno timeout molto più brevi degli anni '60, e in genere questo può indicare contesa.

Un modo forse più semplice per comprendere le differenze è che si scoprirà che se si esegue una singola operazione multipla con un numero molto elevato di modifiche, è possibile attivare facilmente il primo timeout. Se crei un numero significativo di operazioni simultanee contro una singola chiave o un piccolo set di chiavi, innescherai più facilmente quest'ultima. Poiché i timeout sono indicatori generali di saturazione delle risorse condivise, ci sono naturalmente molti modi e combinazioni per generarli. In generale, si vorranno riprovare le operazioni in modo appropriato, e anche dimensionare le operazioni in modo appropriato, nonché aggregare le operazioni sui tasti di scelta rapida nel miglior modo possibile per ridurre la possibilità di problemi relativi alla contesa. Come altri hanno suggerito, i documenti python e java ne hanno già alcuni esempi.

Si potrebbe desiderare di fare uso di https://godoc.org/google.golang.org/appengine#IsTimeoutError e se è necessario aumentare il timeout per la prima classe di errore, si può essere in grado di regolare la scadenza contesto, vedere i metodi qui: https://godoc.org/golang.org/x/net/context#WithDeadline Nota: Non sarà in grado di estendere la scadenza oltre quella di una scadenza di richiesta, tuttavia, se si esegue in attività o VM è possibile estendere a scadenze lunghe.