Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a questa raccomandazione per l'Efficienza delle Prestazioni del checklist Well-Architected Framework di Azure:
| PE:06 | Ottimizzare le prestazioni del carico di lavoro testando regolarmente in un ambiente di produzione per garantire che il carico di lavoro raggiunga gli obiettivi di prestazioni desiderati e raggiunga gli obiettivi aziendali. |
|---|
Il test delle prestazioni è una pratica di test non funzionale usata per valutare il comportamento di un carico di lavoro in varie condizioni. Consente di identificare il degrado delle prestazioni in anticipo, risolvere i problemi in modo proattivo e garantire un allineamento continuo con i contratti a livello di servizio.
Quando si misurano i tempi di risposta, la velocità effettiva, l'utilizzo delle risorse e la stabilità, si raccolgono prove che il carico di lavoro soddisfa costantemente gli obiettivi definiti e offre il livello di prestazioni richiesto dall'azienda.
Le strategie principali di questo articolo si basano sulle procedure di test di base descritte in Strategie di architettura di OE:09 per i test. È consigliabile prima esaminare l'articolo. Le raccomandazioni contenute in questa guida sono incentrate sulle prestazioni e concentrarsi sul raggiungimento degli obiettivi di prestazioni in modo che i carichi di lavoro rimangano allineati agli obiettivi aziendali in continua evoluzione.
La tabella seguente definisce i termini chiave per le prestazioni usati in questo articolo.
| Termine | Definition |
|---|---|
| Obiettivi di prestazioni | I valori di prestazioni specifici che un carico di lavoro deve soddisfare, ad esempio il tempo di risposta, la velocità effettiva o il numero di utenti simultanei. |
| Soglie delle prestazioni | Limiti che separano le prestazioni accettabili dalle prestazioni inaccettabili per una determinata metrica. |
| Budget delle prestazioni | Parte dell'obiettivo complessivo delle prestazioni assegnata a ogni livello o componente di un workload. |
| Margine di errore accettabile | Livello consentito di errori o guasti, derivato dagli obiettivi di livello di servizio (SLO). |
| Criteri di accettazione | Le condizioni che un risultato del test deve soddisfare affinché il carico di lavoro superi i requisiti di prestazioni. |
| Sperimentazione basata su ipotesi | Metodo di test in cui si dichiara una stima delle prestazioni, testarla su una linea di base e convalidarla con i risultati misurati. |
| Baseline delle prestazioni | Set di metriche che rappresentano il comportamento di un carico di lavoro in condizioni normali convalidate dal test. |
| Transazioni sintetiche | Richieste con script che simulano interazioni utente reali per misurare le prestazioni del sistema in condizioni controllate. |
| Regressione delle prestazioni | Calo delle prestazioni rispetto a una baseline stabilita, introdotta da una modifica nel codice, nella configurazione o nell'infrastruttura. |
| Deriva delle prestazioni | Calo graduale delle prestazioni nel tempo che non viene rilevato senza test regolari rispetto alle baseline stabilite. |
Impostare obiettivi misurabili per i test delle prestazioni
Gli obiettivi di prestazioni misurabili trasformano le aspettative soggettive in criteri obiettivi che è possibile testare e convalidare.
Definire gli obiettivi di prestazioni e assegnare budget. Definire e documentare obiettivi di prestazioni specifici, ad esempio il numero di utenti simultanei che è necessario supportare. Assicurarsi che questi obiettivi siano allineati agli obiettivi del livello di servizio e convertirli in obiettivi di test misurabili.
Assegna budget di prestazioni ed errori ai diversi strati del carico di lavoro. Quando i test delle prestazioni hanno esito negativo, i budget consentono di identificare quale livello è responsabile e dove concentrare le attività di ottimizzazione. Senza budget, i test non superati indicano solo che gli obiettivi di prestazioni non vengono soddisfatti, non dove si trova il problema.
Ad esempio, è possibile impostare budget di 400 ms per il tempo di risposta dell'API, 150 ms per le query di database e un limite di 1% per le richieste non riuscite. Quando un test non riesce, è possibile controllare i risultati di ogni livello rispetto al budget per determinare se il problema è costituito da risposte API lente, query lente del database o un picco di errori.
Note
Evitare di definire gli obiettivi di livello di servizio prima di comprendere i flussi utente e i requisiti di prestazione. I contratti di servizio devono essere basati sulle esigenze degli utenti reali e sugli obiettivi aziendali, non su obiettivi arbitrari.
Definire i criteri di accettazione con soglie di superamento e di errore chiare. Basare i criteri di accettazione sulle metriche delle prestazioni, ad esempio latenza, tempi di risposta, velocità effettiva, utilizzo delle risorse, tassi di errore e altri indicatori di prestazioni allineati agli obiettivi di prestazioni.
Definire le soglie per ogni metrica in modo che i test producano risultati positivi o negativi. Se lo SLO richiede il completamento di 95% di richieste entro 200 ms, impostare la soglia di tempo di risposta dell'API su 200 ms al 95° percentile. Qualsiasi esecuzione di test in cui il 95° percentile supera i 200 ms è un errore.
Inizia presto ed effettua test continui.
L'analisi anticipata delle prestazioni rileva i colli di bottiglia dell'architettura prima che diventino costosi da risolvere.
Avviare il test delle prestazioni il prima possibile nel ciclo di vita di sviluppo software del carico di lavoro. Non è necessaria un'applicazione completa per iniziare. Gli sviluppatori possono profilare il codice in locale, misurare i tempi di risposta e identificare le operazioni a elevato utilizzo di risorse. I test iniziali informano le decisioni di progettazione, convalidano le scelte dell'architettura rispetto agli obiettivi di prestazioni e identificano le opportunità di ottimizzazione.
Testare continuamente il carico di lavoro man mano che si evolve per soddisfare nuovi requisiti. Ogni modifica del codice potrebbe introdurre regressioni delle prestazioni. Eseguire regolarmente i test per rilevare queste modifiche in anticipo. Incorporare i test delle prestazioni nelle pipeline di distribuzione ed eseguire test automatizzati periodici per rilevare la deriva delle prestazioni prima che raggiunga la produzione.
Compromesso. I test delle prestazioni iniziali richiedono un'infrastruttura dedicata e competenze specializzate, che aumentano i costi operativi. Bilanciare questo investimento rispetto al costo dei problemi di prestazioni individuati in ritardo e in caso di eventi imprevisti di produzione.
Eseguire test in condizioni reali
I test delle prestazioni devono corrispondere a condizioni reali in modo che i risultati siano significativi.
Effettuare il mirroring dell'ambiente di produzione
L'ambiente di test dovrebbe rispecchiare la produzione quanto più possibile. Personalizzare l'approccio per l'ambiente in base al profilo di rischio del carico di lavoro.
Per i carichi di lavoro cruciali, trovare esattamente la corrispondenza tra la produzione:
- SKU e configurazioni di calcolo
- Impostazioni di scalabilità automatica
- Configurazioni di memorizzazione nella cache
- Condizioni di rete (latenza, larghezza di banda)
- Dipendenze esterne
Per i carichi di lavoro non critici, i test in un ambiente con scalabilità ridotta che simulano la produzione possono fornire informazioni utili a un costo inferiore.
Prevenire la deriva della configurazione La deriva della configurazione può causare risultati fuorvianti dei test. Implementare controlli automatizzati per verificare che l'ambiente di test corrisponda all'ambiente di produzione. Assicurarsi che le versioni corrette vengano distribuite prima di eseguire i test.
Convalidare le prestazioni nell'ambiente di produzione
Gli ambienti di test non possono replicare completamente le condizioni reali che influiscono sulle prestazioni. I test di produzione rivelano problemi che emergono solo durante l'uso effettivo e forniscono linee di base accurate per l'ottimizzazione futura. Alcuni requisiti di prestazioni possono essere convalidati solo quando si intersecano utenti, dati e infrastrutture reali.
Eseguire test di produzione controllati. Pianificare i test durante le ore di minore attività per comprendere il comportamento del carico di lavoro in caso di esaurimento delle risorse e ripristino da errori.
I test di produzione rivelano le caratteristiche delle prestazioni in condizioni effettive, tra cui:
- Modelli di comportamento utente realistici e volumi di dati
- Vera latenza di rete e variazioni della larghezza di banda
- Effetti di distribuzione geografica
- Prestazioni e dipendenze dell'API di terze parti
- Comportamento effettivo della memorizzazione nella cache e caratteristiche dell'infrastruttura
Usare tecniche di test progressivo. Iniziare con piccole percentuali di traffico e aumentare gradualmente. Monitorare i tempi di risposta, la velocità effettiva, le percentuali di errore e l'utilizzo delle risorse in ogni passaggio. Questo approccio graduale limita il rischio identificando il punto di interruzione, rivelando colli di bottiglia e fornendo una visione accurata del comportamento del sistema in base all'aumento della domanda.
Monitorare i test di produzione continuamente per individuare i problemi in anticipo. Implementare misure di sicurezza automatizzate che interrompono i test se influiscono negativamente sugli utenti, ad esempio meccanismi di rollback automatizzati e avvisi in tempo reale. Queste tecniche garantiscono una risposta rapida e riducono al minimo le interruzioni.
Note
Quando si eseguono test delle prestazioni controllati nell'ambiente di produzione, è necessario allocare capacità aggiuntiva per gestire il carico aggiuntivo generato dai test.
Rischio: I test di produzione influiscono direttamente sui clienti reali perché possono creare carico aggiuntivo e interrompere il traffico. Implementare sempre misure di sicurezza, limitare l'esposizione e avere piani di rollback pronti per ridurre al minimo il potenziale impatto aziendale. Bilanciare i vantaggi dei test realistici rispetto al potenziale impatto aziendale dell'interruzione degli utenti live.
Convalidare le modifiche con esperimenti basati su ipotesi
Usare la sperimentazione basata su ipotesi per guidare i test delle prestazioni. Progettare singoli esperimenti di prestazioni in modo da produrre risultati significativi.
Iniziare con un'ipotesi mirata sulle prestazioni del carico di lavoro e definire criteri di successo misurabili che portano a decisioni attuabili. Ad esempio, l'ipotesi potrebbe essere: "L'aggiunta di un indice alla tabella orders riduce il tempo di query di 70% durante il carico massimo". La baseline è lo schema corrente e la variante è lo schema con il nuovo indice. Eseguire lo stesso test di carico su entrambe le versioni. Acquisire la latenza delle query, l'utilizzo della CPU del database e il throughput, quindi confrontare i risultati per determinare se l'ipotesi è confermata.
Applicare più tipi di test delle prestazioni
I test delle prestazioni riguardano una serie di test che valutano velocità, stabilità e scalabilità in diverse condizioni. Ogni tipo di test è destinato a diversi aspetti delle prestazioni del carico di lavoro. Consente di scoprire informazioni dettagliate univoche e di abilitare una valutazione completa che va oltre i test funzionali.
Usare più tipi di test per convalidare il carico di lavoro da diverse angolazioni. Ad esempio, i test di stress rilevano il punto di interruzione sotto il carico massimo, ma solo i test di resistenza rivelano perdite di memoria che superano le ore o i giorni.
Scegliere i tipi di test in base a ciò che è necessario convalidare.
La tabella seguente illustra quando usare ogni tipo di test e cosa rivela sul carico di lavoro. Anche se questa tabella non è un elenco completo, funge da esempio illustrativo.
| Tipo di test | Scopo principale | Quando applicare | Cosa rivela | Environment |
|---|---|---|---|---|
| Test di carico | Verificare che il sistema gestisca i volumi utente previsti con un utilizzo normale e di picco | Avviare in anticipo, eseguire frequentemente | Prestazioni di base, limiti di capacità, efficacia del ridimensionamento | Ambiente di gestione temporanea o di produzione |
| Test di stress | Comprendere i limiti di sistema e i punti di interruzione | Prima che il sistema sia pronto per la produzione | Capacità massima, modalità di errore, comportamento di ripristino | Ambiente di test delle prestazioni dedicato |
| Test di carico a picco | Assicurarsi che il sistema gestisca picchi improvvisi di traffico | Iniziare in anticipo, soprattutto per le app pubbliche | Reattività con autoscalabilità, gestione delle code, degradazione graduale | Ambiente di pre-produzione o di produzione |
| Test di resistenza/assorbimento | Rilevare i problemi che emergono solo in lunghi periodi | Dopo il superamento dei test di carico iniziali | Perdite di memoria, esaurimento delle risorse, problemi del pool di connessioni | Ambiente simile all'ambiente di produzione con allocazione completa delle risorse |
Non tentare di implementare immediatamente tutti i tipi di test. Iniziare con i test di carico di base per comprendere le prestazioni di base. Man mano che si identificano i rischi e si acquisisce esperienza, espandere test di stress, test di picco e infine test di resistenza.
Usare modelli di utilizzo reali e caratteristiche dei dati
I test con dati realistici forniscono informazioni accurate sull'utilizzo delle risorse, sul comportamento del sistema e sui problemi di prestazioni nascosti.
Creare set di dati di test diversi che rappresentano vari scenari, profili utente e volumi di dati. Usare le varianti di input e la casualizzazione per simulare la diversità utente reale. Includere casi perimetrali che potrebbero causare problemi di prestazioni, ad esempio payload di grandi dimensioni, query complesse o concorrenza elevata.
I dati di test dovrebbero essere simili ai dati di produzione reali. Usare dati sintetici con caratteristiche dei dati di produzione. Riservare set di dati di produzione (resi anonimi correttamente) per determinati scenari, ad esempio per evidenziare i comportamenti di gestione dei dati, ad esempio coerenza delle transazioni, latenza e gestione dei volumi.
Simulare transazioni sintetiche che simulano flussi di lavoro utente reali. Creare uno script per queste transazioni ed eseguirle ripetutamente per generare il carico che riflette il modo in cui viene effettivamente usato il carico di lavoro.
Gli scenari di test devono riflettere modelli di utilizzo effettivi, ad esempio l'accesso utente simultaneo, i periodi di carico di picco e sequenze di transazioni specifiche. Assicurarsi che gli scenari siano allineati agli obiettivi aziendali, in modo che i risultati delle prestazioni riflettano il valore effettivo dell'utente.
Quando si esegue il test in fase di caricamento, includere le chiamate API di terze parti effettive. La simulazione delle dipendenze esterne rende i test più veloci e prevedibili, ma nasconde problemi di prestazioni reali. Se l'app dipende da un'API del processore di pagamento, testare con chiamate reali per comprendere la latenza end-to-end.
Usare i risultati dei test per guidare le decisioni di progettazione
I risultati dei test guidano le decisioni di progettazione stabilendo baseline affidabili e guidando le attività di ottimizzazione.
Stabilire le misurazioni di base. Le linee di base consentono di identificare tendenze e anomalie e se le modifiche apportate all'ottimizzazione offrono miglioramenti. Sono necessarie baseline affidabili per tenere traccia delle tendenze delle prestazioni nel tempo.
Registrare le metriche delle prestazioni durante i test iniziali. Questa registrazione è il punto di riferimento, una rappresentazione delle prestazioni 'normali'. Nelle esecuzioni successive confrontare i nuovi risultati con questa baseline per rilevare le modifiche alle prestazioni. Prendere in considerazione l'impatto dell'utente, la frequenza, il costo della correzione e il rischio di modifica dei criteri quando si esaminano i dati per comprendere il comportamento del sistema in diverse condizioni. Cercare modelli che mostrano dove le prestazioni diminuiscono. Usare queste informazioni dettagliate per classificare in ordine di priorità le attività di ottimizzazione.
L'ottimizzazione è un processo iterativo e deve essere guidato dai dati. Riservare tempo dedicato nel ciclo di sviluppo per l'ottimizzazione delle prestazioni. Usare le linee di base per misurare l'impatto delle modifiche e assicurarsi che forniscano i miglioramenti previsti senza introdurre regressioni.
Correlare le prestazioni con le metriche aziendali. Connettere i miglioramenti delle prestazioni ai risultati aziendali, ad esempio ricavi, coinvolgimento degli utenti, soddisfazione dei clienti e tasso di conversione per giustificare un continuo investimento nell'ottimizzazione delle prestazioni.
Note
Esaminare e aggiornare regolarmente le linee di base dopo modifiche significative al carico di lavoro, ad esempio modifiche dell'architettura, nuove funzionalità o modifiche di ridimensionamento. Eseguendo questa azione, assicurarsi che gli obiettivi di prestazioni rimangano rilevanti.
Mantenere gli asset di test allineati ai modelli di utilizzo correnti
Gli asset di test delle prestazioni contengono informazioni critiche sul comportamento previsto del carico di lavoro, soglie di prestazioni accettabili e modelli di traffico realistici.
Organizzare i gruppi di test per tipo. Mantenere test di carico, test di stress e test di resistenza in gruppi separati. Non mescolarli. Ogni tipo ha requisiti di configurazione diversi, durate di esecuzione e criteri di esito positivo. Le suite organizzate semplificano l'esecuzione di test mirati, confrontano i risultati tra le esecuzioni e gestiscono ogni gruppo in modo indipendente.
Aggiornare regolarmente i dati di test. I dati di test non aggiornati portano a risultati irrealistici. Rigenerare i dati di test per riflettere le caratteristiche correnti dei dati di produzione ogni volta che il modello di dati cambia, i volumi di dati aumentano o i dati demografici degli utenti cambiano.
Esaminare gli scenari di test man mano che il carico di lavoro si evolve. Pianificare revisioni regolari per assicurarsi che gli scenari riflettano ancora l'utilizzo effettivo. Gli scenari diventano obsoleti come:
- Il comportamento dell'utente cambia nel tempo
- I modelli di traffico cambiano man mano che la base utente cresce
- Le nuove funzionalità introducono modelli di utilizzo diversi
- Scalabilità dell'infrastruttura per soddisfare i nuovi requisiti di capacità
Facilitazione di Azure
Azure Pipelines consente di integrare i test delle prestazioni nella pipeline CI/CD. È possibile aggiungere test di carico come passaggio nella pipeline per convalidare le prestazioni e la scalabilità delle applicazioni.
Azure Chaos Studio consente di inserire errori reali nell'applicazione in modo da poter eseguire esperimenti di inserimento degli errori controllati. Gli esperimenti consentono di misurare, comprendere e migliorare la resilienza dell'applicazione cloud e del servizio.
Test di carico di Azure è un servizio di test di carico che genera un carico su larga scala in qualsiasi applicazione. Test di carico offre funzionalità per automatizzare i test di carico e integrarli nel flusso di lavoro di integrazione continua e distribuzione continua (CI/CD). È possibile definire criteri di test, ad esempio il tempo medio di risposta o le soglie di errore, e arrestare automaticamente i test di carico in base a condizioni di errore specifiche. Test di carico offre un dashboard che fornisce aggiornamenti in tempo reale e metriche dettagliate delle risorse dei componenti dell'applicazione Azure durante un test di carico. È possibile analizzare i risultati del test, identificare i colli di bottiglia delle prestazioni e confrontare più esecuzioni di test per comprendere le regressioni delle prestazioni nel tempo.
Monitoraggio di Azure è una soluzione di monitoraggio completa per la raccolta, l'analisi e la risposta ai dati di telemetria dagli ambienti cloud e locali. Application Insights è un'estensione di Monitoraggio che fornisce funzionalità APM. È possibile usare Application Insights per monitorare le applicazioni durante lo sviluppo e il test e anche nell'ambiente di produzione.
Collegamenti correlati
- Raccomandazioni per i test di sicurezza
- Suggerimenti per la progettazione di una strategia di test di affidabilità
Elenco di controllo dell'efficienza delle prestazioni
Fare riferimento al set completo di raccomandazioni.