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

Articolo
04/10/2024

Questo articolo consente di analizzare le modifiche impreviste nel comportamento, ad esempio tempi di risposta più lenti del solito. Queste modifiche del comportamento possono spesso essere 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 mostrano il tempo medio che il servizio di archiviazione o il tipo di operazione API sta impiegando 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 una volta che la richiesta raggiunge il servizio di archiviazione). SuccessServerLatency è una misura solo del tempo di elaborazione e pertanto esclude qualsiasi latenza di rete correlata alla comunicazione con il client.
Le metriche Egress e Ingress mostrano la quantità totale di dati, in byte, che entrano e escono 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. Transazioni è 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.

Nel portale di Azure è possibile aggiungere regole di avviso che inviano una notifica quando una delle metriche delle prestazioni per questo servizio è inferiore o superiore a una soglia specificata.

Diagnosticare i problemi di prestazioni

Le prestazioni di un'applicazione possono essere soggettive, soprattutto dal punto di vista dell'utente. Di conseguenza, è importante avere a disposizione metriche di base che consentono di identificare la posizione in cui potrebbe verificarsi un problema di prestazioni. Molti fattori possono influire sulle prestazioni di un servizio di archiviazione di Azure dal punto di vista dell'applicazione client. Questi fattori possono operare nel servizio di archiviazione, nel client o nell'infrastruttura di rete. Di conseguenza, è importante avere una strategia per identificare l'origine del problema di prestazioni.

Dopo aver identificato la posizione probabile 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 un'elevata successE2ELatency e una 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. Di conseguenza, una differenza tra SuccessE2ELatency e SuccessServerLatency potrebbe essere dovuta a un rallentamento della risposta dell'applicazione client o a causa di condizioni nella rete.

Nota

È anche possibile visualizzare E2ELatency e ServerLatency per le singole operazioni di archiviazione nei dati del log di registrazione 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 l'esaurimento di risorse quali 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 di dimensioni maggiori con più core e più memoria.

Per i servizi di tabella e coda, l'algoritmo Nagle può anche causare un'elevata successe2elatenza rispetto a SuccessServerLatency. Per altre informazioni, vedere Il post Nagle's Algorithm is Not Friendly towards Small Requests (Algoritmo di Nagle non è compatibile con le richieste di piccole dimensioni). È 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 ai servizi di tabella o di coda nell'applicazione, in quanto ciò non influisce sulle connessioni già aperte. L'esempio seguente proviene dal Application_Start 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 generali relativi alle prestazioni correlate a .NET nel client, ad esempio CPU, Garbage Collection .NET, utilizzo della rete o memoria. Come punto di partenza per la risoluzione dei problemi delle 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 sia temporanei che persistenti, ad esempio i pacchetti eliminati, usando strumenti come Wireshark.

Le metriche mostrano bassa latenza SuccessE2ELatency e bassa SuccessServerLatency, ma il client sta riscontrando una latenza elevata

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

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

Controllare anche se il client sta eseguendo più tentativi ed esaminare il motivo. Per determinare se il client esegue più tentativi, è possibile:

Esaminare i log. Se si verificano più tentativi, verranno visualizzate più operazioni con gli stessi ID richiesta client.
Esaminare i log client. La registrazione dettagliata indicherà 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 univoche. È anche possibile controllare gli orari di inizio e fine per ogni richiesta.

Se non si verificano problemi nel client, è necessario analizzare potenziali problemi di rete, ad esempio la perdita di pacchetti. È possibile usare strumenti come Wireshark per analizzare i problemi di rete.

Le metriche mostrano un livello elevato di SuccessServerLatency

Nel caso di SuccessServerLatency elevato per le richieste di download dei BLOB, è necessario 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 BLOB, è consigliabile esaminare le dimensioni del blocco che il client sta usando( ad esempio, blocchi di dimensioni inferiori a 64 K possono comportare sovraccarichi a meno che le letture non siano anche in blocchi inferiori a 64 K) e se più client caricano blocchi nello stesso BLOB in parallelo. È anche consigliabile 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 dei 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 Content Delivery Network). Per le richieste di caricamento, è possibile migliorare la velocità effettiva usando dimensioni di blocco maggiori. Per le query nelle 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 SuccessServerLatency elevati possono anche essere un sintomo di tabelle o query progettate in modo non corretto che generano operazioni di analisi o che seguono l'anti-pattern di accodamento/anteposizione.

Nota

È possibile trovare un elenco di controllo completo delle prestazioni da Archiviazione di Microsoft Azure elenco di controllo per le prestazioni e la 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 tempo 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 dell'esito positivo.
Verificare che non vi sia alcuna differenza di clock 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 viene visualizzata come se si verificasse un ritardo nell'elaborazione.
Controllare se il ruolo di lavoro che legge i messaggi dalla coda ha esito negativo. Se un client di coda chiama il GetMessage metodo ma non riesce a rispondere con un riconoscimento, il messaggio rimarrà invisibile nella coda fino alla scadenza del invisibilityTimeout periodo. A questo punto, il messaggio diventa nuovamente disponibile per l'elaborazione.
Controllare se la lunghezza della coda sta crescendo nel tempo. Ciò può verificarsi se non sono disponibili ruoli di lavoro sufficienti per elaborare tutti i messaggi che altri ruoli di lavoro stanno inserendo nella coda. Controllare inoltre le metriche per verificare se le richieste di eliminazione hanno esito negativo e il conteggio della dequeue sui messaggi, che potrebbe indicare tentativi ripetuti non riusciti di eliminare il messaggio.
Esaminare i log di archiviazione per individuare eventuali operazioni di coda con valori E2ELatency e ServerLatency superiori al previsto per un periodo di tempo più lungo del solito.

Vedere 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.