Risolvere i problemi relativi alle prestazioni negli account di archiviazione di Azure

Articolo
11/20/2024

Questo articolo illustra le modifiche impreviste nel comportamento, ad esempio tempi di risposta più lenti del solito. Queste modifiche nel comportamento possono essere spesso identificate monitorando le metriche di archiviazione in Monitoraggio di Azure. Per informazioni generali sull'uso di metriche e log in Monitoraggio di Azure, vedere gli articoli seguenti:

Monitoraggio delle prestazioni

Per monitorare le prestazioni dei servizi di archiviazione, è possibile usare le metriche seguenti:

Le metriche SuccessE2ELatency e SuccessServerLatency indicano il tempo medio usata dal servizio di archiviazione o dal tipo di operazione API per elaborare le richieste. SuccessE2ELatency è una misura della latenza end-to-end che include il tempo impiegato per leggere la richiesta e inviare la risposta oltre al tempo impiegato per elaborare la richiesta (pertanto include la latenza di rete quando la richiesta raggiunge il servizio di archiviazione). SuccessServerLatency è una misura solo del tempo di elaborazione ed esclude quindi qualsiasi latenza di rete correlata alla comunicazione con il client.
Le metriche in uscita e in ingresso mostrano la quantità totale di dati, in byte, in ingresso e uscita dal servizio di archiviazione o tramite un tipo di operazione API specifico.
La metrica Transazioni mostra il numero totale di richieste ricevute dal servizio di archiviazione dell'operazione API. Le transazioni sono il numero totale di richieste ricevute dal servizio di archiviazione.

È possibile monitorare le modifiche impreviste in uno di questi valori. Queste modifiche potrebbero indicare un problema che richiede ulteriori indagini.

Nella portale di Azure è possibile aggiungere regole di avviso che segnalano quando una delle metriche delle prestazioni per questo servizio scende al di sotto o supera una soglia specificata.

Diagnosticare i problemi di prestazioni

Le prestazioni di un'applicazione possono essere soggettive, soprattutto dal punto di vista dell'utente. È quindi importante disporre di metriche di base disponibili per identificare la causa di un problema di prestazioni. Sono molti i fattori che possono influire sulle prestazioni di un servizio di archiviazione Azure dal punto di vista dell'applicazione client. Questi fattori possono operare nel servizio di archiviazione, nel client o nell'infrastruttura di rete. È quindi importante avere una strategia per identificare l'origine del problema di prestazioni.

Dopo aver identificato la probabile posizione della causa del problema di prestazioni dalle metriche, è possibile usare i file di log per trovare informazioni dettagliate per diagnosticare e risolvere ulteriormente il problema.

Le metriche mostrano successE2ELatency e bassa SuccessServerLatency

In alcuni casi, è possibile che SuccessE2ELatency sia superiore a SuccessServerLatency. Il servizio di archiviazione calcola solo la metrica SuccessE2ELatency per le richieste riuscite e, a differenza di SuccessServerLatency, include il tempo impiegato dal client per inviare i dati e ricevere il riconoscimento dal servizio di archiviazione. Pertanto, una differenza tra SuccessE2ELatency e SuccessServerLatency potrebbe essere dovuta al rallentamento della risposta dell'applicazione client o a causa di condizioni nella rete.

Note

È anche possibile visualizzare i valori E2ELatency e ServerLatency per le singole operazioni di archiviazione nei dati del log della registrazione dell'archiviazione.

Analisi dei problemi di prestazioni del client

I possibili motivi per cui il client risponde lentamente includono la presenza di connessioni o thread disponibili limitati o di risorse ridotte, ad esempio CPU, memoria o larghezza di banda di rete. È possibile risolvere il problema modificando il codice client in modo che sia più efficiente (ad esempio, usando chiamate asincrone al servizio di archiviazione) o usando una macchina virtuale più grande con più core e più memoria.

Per i servizi tabelle e code, l'algoritmo Nagle può anche causare un'elevata successE2ELatency rispetto a SuccessServerLatency. Per altre informazioni, vedere il post Algoritmo Nagle is Not Friendly towards Small Requests.For more information, see the post Nagle's Algorithm is Not Friendly towards Small Requests. È possibile disabilitare l'algoritmo Nagle nel codice usando la ServicePointManager classe nello spazio dei System.Net nomi . È consigliabile eseguire questa operazione prima di effettuare chiamate alla tabella o ai servizi di accodamento nell'applicazione perché ciò non influisce sulle connessioni già aperte. L'esempio Application_Start seguente deriva dal metodo in un ruolo di lavoro:

var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

È consigliabile controllare i log sul lato client per verificare il numero di richieste inviate dall'applicazione client e verificare la presenza di colli di bottiglia delle prestazioni correlati a .NET generali nel client, ad esempio CPU, Garbage Collection .NET, utilizzo della rete o memoria. Come punto di partenza per la risoluzione dei problemi nelle applicazioni client .NET, vedere Debug, traccia e profilatura.

Analisi dei problemi di latenza di rete

In genere la latenza end-to-end elevata causata dalla rete è dovuta a condizioni temporanee. È possibile analizzare i problemi di rete temporanei e persistenti, ad esempio i pacchetti eliminati, usando strumenti come Wireshark.

Le metriche mostrano una bassa latenza SuccessE2ELatency e una bassa successServerLatency, ma il client riscontra una latenza elevata

In questo scenario, la causa più probabile è un ritardo nella richiesta di archiviazione che raggiunge il servizio di archiviazione. È consigliabile esaminare il motivo per cui le richieste dal client non lo effettuano al servizio BLOB.

Un motivo possibile per cui il client ritarda l'invio delle richieste riguarda il numero limitato di connessioni o thread disponibili.

Controllare anche se il client sta eseguendo più tentativi e analizzare il motivo se lo è. Per determinare se il client sta effettuando più tentativi, è possibile:

Esaminare i log. Se si verificano più tentativi, verranno visualizzate più operazioni con gli stessi ID richiesta client.
Esaminare i log del client. I log dettagliati indicheranno che si è verificato un nuovo tentativo.
Eseguire il debug del codice e controllare le proprietà dell'oggetto OperationContext associato alla richiesta. Se l'operazione è stata ritentata, la RequestResults proprietà includerà più richieste univoce. È inoltre possibile controllare l'ora di inizio e fine di ogni richiesta.

Se non si riscontrano problemi nel client, occorre verificare la presenza di potenziali problemi della rete, ad esempio la perdita di pacchetti. È possibile usare strumenti come Wireshark per analizzare i problemi di rete.

Le metriche mostrano un numero elevato di SuccessServerLatency

Nel caso di un numero elevato di SuccessServerLatency per le richieste di download dei BLOB, è consigliabile usare i log di archiviazione per verificare se sono presenti richieste ripetute per lo stesso BLOB (o set di BLOB). Per le richieste di caricamento dei BLOB, è necessario esaminare le dimensioni del blocco che il client sta usando (ad esempio, i blocchi di dimensioni inferiori a 64 K possono comportare sovraccarichi a meno che le letture non si trovino anche in blocchi inferiori a 64 K) e se più client caricano blocchi nello stesso BLOB in parallelo. È anche necessario controllare le metriche al minuto per individuare i picchi nel numero di richieste che comportano il superamento degli obiettivi di scalabilità al secondo.

Se viene visualizzata un'elevata successServerLatency per le richieste di download blob quando sono presenti richieste ripetute per lo stesso BLOB o set di BLOB, prendere in considerazione la memorizzazione nella cache di questi BLOB usando Cache di Azure o la rete CDN (Azure rete per la distribuzione di contenuti). Per le richieste di caricamento, è possibile ottimizzare la velocità utilizzando blocchi di dimensioni maggiori. Per le query sulle tabelle, è anche possibile implementare la memorizzazione nella cache lato client nei client che eseguono le stesse operazioni di query e in cui i dati non cambiano di frequente.

I valori di SuccessServerLatency elevati possono anche essere un sintomo di tabelle o query progettate in modo non corretto che comportano operazioni di analisi o che seguono il modello anti-pattern append/prepend.

Note

È possibile trovare un elenco di controllo completo delle prestazioni da Archiviazione di Microsoft Azure Elenco di controllo per prestazioni e scalabilità.

Si verificano ritardi imprevisti nel recapito dei messaggi in una coda

Se si verifica un ritardo tra il momento in cui un'applicazione aggiunge un messaggio a una coda e il momento in cui diventa disponibile per la lettura dalla coda, seguire questa procedura per diagnosticare il problema:

Verificare che l'applicazione stia aggiungendo correttamente i messaggi alla coda. Verificare che l'applicazione non stia ritentando il AddMessage metodo più volte prima di riuscire.
Verificare che non vi sia un'asimmetria dell'orologio tra il ruolo di lavoro che aggiunge il messaggio alla coda e il ruolo di lavoro che legge il messaggio dalla coda. Un'asimmetria dell'orologio lo rende come se si verificasse un ritardo nell'elaborazione.
Verificare se il ruolo di lavoro che legge i messaggi dalla coda presenta degli errori. Se un client della coda chiama il GetMessage metodo ma non risponde con un riconoscimento, il messaggio rimarrà invisibile nella coda fino alla scadenza del invisibilityTimeout periodo. A questo punto, il messaggio diventa di nuovo disponibile per l'elaborazione.
Verificare se la lunghezza della coda aumenta con il tempo. Ciò può verificarsi se non sono disponibili ruoli di lavoro sufficienti per elaborare tutti i messaggi inseriti da altri ruoli di lavoro nella coda. Controllare anche le metriche per verificare se le richieste di eliminazione hanno esito negativo e il conteggio della coda sui messaggi, che potrebbero indicare tentativi ripetuti non riusciti di eliminare il messaggio.
Esaminare i log di archiviazione per le operazioni di coda con valori E2ELatency e ServerLatency superiori al previsto in un periodo di tempo più lungo del solito.

Vedi anche

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.

Condividi tramite