Elenco di controllo per le prestazioni e la scalabilità di Archiviazione code
Microsoft ha sviluppato molte procedure comprovate per lo sviluppo di applicazioni ad alte prestazioni con queue Archiviazione. Questo elenco di controllo identifica le procedure chiave che gli sviluppatori possono seguire per ottimizzare le prestazioni. Tenere presenti queste procedure durante la progettazione dell'applicazione e durante tutto il processo.
Archiviazione di Azure ha degli obiettivi di scalabilità per la capacità, la frequenza di transazioni e la larghezza di banda. Per altre informazioni sugli obiettivi di scalabilità di Archiviazione di Azure, vedere Obiettivi di scalabilità e prestazioni per gli account di archiviazione standard e Obiettivi di scalabilità e prestazioni per Archiviazione code.
Elenco di controllo
Questo articolo organizza le procedure consolidate per le prestazioni in un elenco di controllo che è possibile seguire durante lo sviluppo di un'applicazione di archiviazione code.
Obiettivi di scalabilità
Se l'applicazione si avvicina o supera uno degli obiettivi di scalabilità, potrebbe verificarsi un aumento delle latenze delle transazioni o una limitazione. Quando Archiviazione di Azure limita l'applicazione, il servizio inizia a restituire i codici di errore 503 (Server Busy) o 500 (Operation Timeout). Evitare questi errori rispettando i limiti degli obiettivi di scalabilità è una parte importante del miglioramento delle prestazioni dell'applicazione.
Per altre informazioni sugli obiettivi di scalabilità per Archiviazione code, vedere Obiettivi di scalabilità e prestazioni per Archiviazione di Azure.
Numero massimo di account di archiviazione
Se si sta per raggiungere il numero massimo di account di archiviazione consentiti per una determinata combinazione di sottoscrizione/area, si usano più account di archiviazione da partizionare per aumentare il traffico in ingresso, in uscita, le operazioni di I/O al secondo o la capacità? In questo scenario, se possibile Microsoft consiglia di sfruttare l'innalzamento dei limiti degli account di archiviazione per ridurre il numero di account di archiviazione necessari per il carico di lavoro. Contattare il supporto di Azure per richiedere l'espansione dei limiti dell'account di archiviazione.
Obiettivi di capacità e transazioni
Se l'applicazione sta raggiungendo gli obiettivi di scalabilità per un singolo account di archiviazione, valutare uno dei seguenti approcci:
- Se gli obiettivi di scalabilità per le code non sono sufficienti per l'applicazione, è consigliabile usare più code e distribuire i messaggi fra di esse.
- Esaminare di nuovo il carico di lavoro che causa il raggiungimento o il superamento dell'obiettivo di scalabilità da parte dell'applicazione. È possibile progettarlo in modo diverso in modo che usi una quantità minore di larghezza di banda o capacità o un minor numero di transazioni?
- Se l'applicazione deve superare uno degli obiettivi di scalabilità, creare più account di archiviazione e partizionare i dati dell'applicazione tra questi account di archiviazione. Se si usa questo modello, assicurarsi di progettare l'applicazione in modo da aggiungere altri account di archiviazione in futuro per il bilanciamento del carico. Gli stessi account di archiviazione non hanno costi aggiuntivi rispetto a quelli per l'uso, ossia associati ai dati archiviati, alle transazioni effettuate o ai dati trasferiti.
- Se l'applicazione sta raggiungendo gli obiettivi di larghezza di banda, valutare la compressione dei dati sul lato client per ridurre la larghezza di banda necessaria a inviare i dati ad Archiviazione di Azure. Mentre la compressione dei dati potrebbe risparmiare larghezza di banda e migliorare le prestazioni di rete, può anche avere effetti negativi sulle prestazioni. Valutare gli effetti sulle prestazioni dei requisiti di elaborazione aggiuntivi per la compressione e la decompressione dei dati sul lato client. Tenere presente che l'archiviazione dei dati compressi può rendere più difficile la risoluzione dei problemi, perché potrebbe risultare più difficile visualizzare i dati usando gli strumenti standard.
- Se l'applicazione sta raggiungendo gli obiettivi di scalabilità, assicurarsi di usare un backoff esponenziale per i tentativi. È consigliabile provare a evitare di raggiungere gli obiettivi di scalabilità implementando i consigli descritti in questo articolo. Tuttavia, l'uso di un backoff esponenziale per i tentativi impedisce all'applicazione di riprovare rapidamente, cosa che potrebbe peggiorare la limitazione. Per altre informazioni, vedere la sezione Errori di timeout e server occupato.
Rete
I vincoli di rete fisica dell'applicazione potrebbero avere un impatto significativo sulle prestazioni. Le sezioni seguenti descrivono alcune limitazioni che gli utenti potrebbero riscontrare.
Capacità della rete client
La larghezza di banda e la qualità del collegamento di rete svolgono ruoli importanti nelle prestazioni dell'applicazione, come descritto nelle sezioni seguenti.
Velocità effettiva
Per la larghezza di banda il problema dipende spesso dalle capacità del client. Le istanze di Azure più grandi possono avere schede di interfaccia di rete con capacità più elevate ed è quindi opportuno prendere in considerazione l'uso di un'istanza più grande o di più macchine virtuali se è necessario che un singolo computer abbia limiti di rete più elevati. Se si accede Archiviazione di Azure da un'applicazione locale, si applica la stessa regola: comprendere le funzionalità di rete del dispositivo client e la connettività di rete al percorso di Archiviazione di Azure e migliorarle in base alle esigenze o progettare l'applicazione in modo che funzioni all'interno delle relative funzionalità.
Qualità del collegamento
Come per qualsiasi utilizzo di rete, tenere presente che le condizioni di rete che causano errori e perdita di pacchetti rallentano la velocità effettiva effettiva. L'uso di Wireshark o Monitoraggio di rete può aiutare a diagnosticare questo problema.
Titolo
In qualsiasi ambiente distribuito, il posizionamento del client accanto al server offre le prestazioni migliori. Per accedere all'archiviazione di Azure con la minor latenza possibile, è opportuno posizionare il client nella stessa area di Azure. Ad esempio, se si ha un'app Web di Azure che usa Archiviazione di Azure, posizionare entrambi in un'unica area, ad esempio Stati Uniti occidentali o Asia sud-orientale. Il posizionamento delle risorse nella stessa area riduce latenza e costi, in quanto l'utilizzo della larghezza di banda in un'unica area è gratuito.
Se le applicazioni client accedono Archiviazione di Azure ma non sono ospitate in Azure, ad esempio app per dispositivi mobili o servizi aziendali locali, l'individuazione dell'account di archiviazione in un'area vicina a tali client potrebbe ridurre la latenza. Se i client sono distribuiti in un'area ampia (ad esempio, alcuni in America del Nord e altri in Europa), è opportuno usare un account di archiviazione per ogni area. Questo approccio è più semplice da implementare se i dati archiviati dall'applicazione sono specifici per i singoli utenti e non richiedono la replica dei dati tra gli account di archiviazione.
SAS e CORS
Si supponga che sia necessario autorizzare il codice, ad esempio JavaScript, che viene eseguito nel Web browser dell'utente o in un'app per telefoni cellulari per accedere ai dati in Archiviazione di Azure. Un approccio consiste nel creare un'applicazione di servizio che funga da proxy. Il dispositivo dell'utente esegue l'autenticazione con il servizio, che a sua volta autorizza l'accesso alle risorse di Archiviazione di Azure. In questo modo si evita di esporre le chiavi dell'account di archiviazione in dispositivi non sicuri. Questo approccio causa tuttavia un sovraccarico significativo dell'applicazione di servizio, perché tutti i dati trasferiti tra il dispositivo dell'utente e Archiviazione di Azure devono passare attraverso l'applicazione di servizio.
È possibile evitare di usare un'applicazione di servizio come proxy per Archiviazione di Azure usando firme di accesso condiviso. Con le firme di accesso condiviso è possibile consentire al dispositivo dell'utente di indirizzare le richieste direttamente ad Archiviazione di Azure usando un token con accesso limitato. Ad esempio, se un utente vuole caricare una foto nell'applicazione, l'applicazione di servizio può generare una firma di accesso condiviso e inviarla al dispositivo dell'utente. Il token di firma di accesso condiviso può concedere l'autorizzazione per scrivere in una risorsa di Archiviazione di Azure per un intervallo di tempo specificato, dopo la scadenza del token di firma di accesso condiviso. Per altre informazioni sulla firma di accesso condiviso, vedere Concedere accesso limitato alle risorse di archiviazione di Azure tramite firme di accesso condiviso.
In genere, un Web browser non consente a JavaScript in una pagina ospitata da un sito Web in un dominio di eseguire determinate operazioni, ad esempio le operazioni di scrittura, in un altro dominio. Noto come criterio di corrispondenza dell'origine, questo criterio impedisce a uno script dannoso in una pagina di ottenere l'accesso ai dati in un'altra pagina Web. Tuttavia, i criteri di corrispondenza dell'origine possono costituire una limitazione quando si compila una soluzione nel cloud. La condivisione di risorse tra le origini è una funzionalità del browser che consente al dominio di destinazione di comunicare con il browser di cui reputa attendibili le richieste originate nel dominio di origine.
Si supponga, ad esempio, che un'applicazione Web in esecuzione in Azure faccia una richiesta di una risorsa a un account di Archiviazione di Azure. L'applicazione Web è il dominio di origine e l'account di archiviazione è il dominio di destinazione. È possibile configurare la condivisione di risorse tra le origini per qualsiasi servizio di Archiviazione di Azure in modo che comunichi con il Web browser che le richieste provenienti dal dominio di origine siano ritenuti attendibili da Archiviazione di Azure. Per altre informazioni sulla condivisione di risorse tra le origini, vedere Supporto della condivisione delle risorse tra le origini (CORS) per Archiviazione di Azure.
Entrambe le tecnologie SAS e CORS possono aiutare a evitare carichi non necessari nell'applicazione Web.
Configurazione .NET
Per i progetti che usano .NET Framework, questa sezione elenca alcune impostazioni di configurazione rapide che è possibile usare per apportare miglioramenti significativi delle prestazioni. Se si usa un linguaggio diverso da .NET, verificare se si applicano concetti simili nel linguaggio scelto.
Aumento del limite di connessione predefinito
Nota
Questa sezione si applica ai progetti che usano .NET Framework, perché il pool di connessioni è controllato dalla classe ServicePointManager. .NET Core ha introdotto una modifica significativa rispetto alla gestione del pool di connessioni, in cui il pool di connessioni avviene a livello httpClient e le dimensioni del pool non sono limitate per impostazione predefinita. Ciò significa che le connessioni HTTP vengono ridimensionate automaticamente per soddisfare il carico di lavoro. È consigliabile usare la versione più recente di .NET, quando possibile, per sfruttare i miglioramenti delle prestazioni.
Per i progetti che usano .NET Framework, è possibile usare il codice seguente per aumentare il limite di connessione predefinito (in genere 2 in un ambiente client o 10 in un ambiente server) a 100. Solitamente il valore deve essere impostato basandosi approssimativamente sul numero di thread usato dall'applicazione. Impostare il limite di connessione prima di aprire le connessioni.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Per altre informazioni sui limiti del pool di connessioni in .NET Framework, vedere Limiti del pool di Connessione ion di .NET Framework e il nuovo Azure SDK per .NET.
Per altri linguaggi di programmazione, vedere la documentazione per determinare come impostare il limite di connessione.
Aumentare il numero minimo di thread
Se si usano chiamate sincrone con attività asincrone, è possibile aumentare il numero di thread nel pool di thread:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Per altre informazioni, vedere il metodo ThreadPool.SetMinThreads.
Parallelismo non associato
Anche se il parallelismo può essere ottimale per le prestazioni, prestare attenzione all'uso del parallelismo non associato, ovvero non esiste alcun limite applicato al numero di thread o richieste parallele. Assicurarsi di limitare le richieste parallele per caricare o scaricare dati, per accedere a più partizioni nello stesso account di archiviazione o per accedere a più elementi nella stessa partizione. Se il parallelismo non è associato, l'applicazione può superare le capacità del dispositivo client o gli obiettivi di scalabilità dell'account di archiviazione producendo latenze più lunghe e limitazioni.
Librerie e strumenti client dell'archiviazione
Per ottenere le migliori prestazioni, usare sempre l'ultima versione delle librerie e degli strumenti client forniti da Microsoft. Archiviazione di Azure librerie client sono disponibili per varie lingue. Archiviazione di Azure supporta anche PowerShell e l'interfaccia della riga di comando di Azure. Microsoft sviluppa attivamente questi strumenti e librerie client concentrandosi sulle prestazioni, li mantiene aggiornati con le ultime versioni del servizio e verifica che siano in grado di gestire internamente gran parte delle procedure comprovate relative alle prestazioni. Per altre informazioni, vedere la documentazione di riferimento di Archiviazione di Azure.
Gestire gli errori del servizio
Archiviazione di Azure restituisce un errore quando il servizio non è in grado di elaborare una richiesta. Comprendere gli errori che potrebbero essere restituiti da Archiviazione di Azure in uno scenario specifico è utile per ottimizzare le prestazioni.
Errori di timeout e server occupato
Archiviazione di Azure potrebbe limitare l'applicazione se si avvicina ai limiti di scalabilità. In alcuni casi, Archiviazione di Azure potrebbe non essere in grado di gestire una richiesta a causa di una condizione temporanea. In entrambi i casi, il servizio potrebbe restituire un errore 503 (Server Busy) o 500 (Timeout). Questi errori possono verificarsi anche se il servizio esegue il ribilanciamento delle partizioni di dati per consentire una maggiore velocità effettiva. L'applicazione client in genere deve ripetere l'operazione che ha causato uno di questi errori. Tuttavia, se Archiviazione di Azure limita l'applicazione perché supera gli obiettivi di scalabilità o anche se il servizio non è in grado di soddisfare la richiesta per un altro motivo, i tentativi aggressivi potrebbero peggiorare il problema. È consigliabile l'uso di criteri di ripetizione del backoff esponenziale, ovvero il comportamento predefinito nelle librerie client. Ad esempio, l'applicazione potrebbe riprovare dopo 2 secondi, quindi 4 secondi, 10 secondi, quindi 30 secondi e quindi rinunciare completamente. Piuttosto che peggiorare il problema, in questo modo si riduce notevolmente il carico dell'applicazione sul servizio che potrebbe condurre alla limitazione della larghezza di banda della rete.
Connessione gli errori possono essere ritentati immediatamente, perché non sono il risultato della limitazione e si prevede che siano temporanei.
Errori irreversibili
Le librerie client gestiscono i tentativi con la consapevolezza degli errori che possono essere ritentati e che non possono essere eseguiti. Tuttavia, se si chiama direttamente l'API REST Archiviazione di Azure, ci sono alcuni errori che non è consigliabile riprovare. Ad esempio, un errore 400 (Bad Request) indica che l'applicazione client ha inviato una richiesta che non è stato possibile elaborare perché non era nel formato previsto. Il nuovo invio di questa richiesta restituisce la stessa risposta ogni volta, quindi non è necessario riprovare. Se si chiama direttamente l'API REST Archiviazione di Azure, tenere presente eventuali errori e verificare se devono essere ritentati.
Per altre informazioni sui codici di errore di Archiviazione di Azure, vedere Stato e codici errore.
Disabilitare l'algoritmo di Nagle
L'algoritmo Nagle viene spesso implementato nelle reti TCP/IP come strumento per migliorare le prestazioni di rete. Tuttavia, non è ottimale in tutte le circostanze ,ad esempio ambienti altamente interattivi. L'algoritmo di Nagle ha un impatto negativo sulle prestazioni delle richieste ad Archiviazione tabelle di Azure e, se possibile, dovrebbe essere disabilitato.
Dimensione del messaggio
Le prestazioni e la scalabilità della coda diminuiscono con l'aumentare delle dimensioni del messaggio. In un messaggio inserire solo le informazioni richieste dal ricevitore.
Recupero in batch
È possibile recuperare fino a 32 messaggi da una coda in una singola operazione. Il recupero in batch può ridurre il numero di round trip dall'applicazione client, cosa particolarmente utile per gli ambienti con latenza elevata, come i dispositivi mobili.
Intervallo di polling della coda
La maggior parte delle applicazioni esegue il polling dei messaggi da una coda, che può costituire una delle principali origini di transazioni per l'applicazione. L'intervallo di polling deve essere scelto con attenzione: se si esegue il polling con eccessiva frequenza, l'applicazione potrebbe avvicinarsi all'obiettivo di scalabilità per la coda. Tuttavia, a 200.000 transazioni per $0,01 (al momento della scrittura), un singolo processore polling una volta al secondo per un mese costerebbe meno di 15 centesimi, quindi il costo non è in genere un fattore che influisce sulla scelta dell'intervallo di polling.
Per informazioni aggiornate sui costi, vedere Prezzi di Archiviazione di Azure.
Eseguire un'operazione di aggiornamento del messaggio
È possibile eseguire un'operazione di aggiornamento del messaggio per aumentare il timeout di invisibilità o aggiornare le informazioni di stato di un messaggio. Questo approccio può essere più efficiente rispetto al passaggio di un processo da una coda alla successiva mediante un flusso di lavoro man mano che i singoli passaggi del processo vengono completati. L'applicazione può salvare lo stato del processo nel messaggio e continuare il lavoro invece di riaccodare il messaggio per il passaggio successivo del processo ogni volta che viene completato un passaggio. Tenere presente che ogni operazione di aggiornamento del messaggio viene presa in considerazione per il calcolo della soglia di scalabilità.
Architettura dell'applicazione
Usare le code per rendere scalabile l'architettura dell'applicazione. Di seguito vengono elencati alcuni modi in cui le code possono essere usate per rendere più scalabile l'applicazione:
- Le code possono essere usate per creare backlog di lavoro per l'elaborazione e il contenimento dei carichi di lavoro nell'applicazione. Ad esempio, è possibile accodare le richieste degli utenti per eseguire un lavoro che prevede un utilizzo intensivo del processore, ad esempio il ridimensionamento delle immagini caricate.
- È possibile usare le code per separare i componenti dell'applicazione per eseguirne la scalabilità in modo indipendente. Un front-end Web, ad esempio, può inserire i risultati di un sondaggio degli utenti in una coda per l'analisi e l'archiviazione successive. È possibile aggiungere più istanze del ruolo di lavoro per elaborare i dati della coda come richiesto.