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.
Gli antipattern delle prestazioni, molto simili a modelli di progettazione, sono processi e implementazioni difettosi comuni all'interno delle organizzazioni. Si tratta di procedure comuni che potrebbero causare problemi di scalabilità quando un'applicazione è sotto pressione. La consapevolezza di queste procedure può aiutare a semplificare la comunicazione di concetti di alto livello tra professionisti del software e la conoscenza degli antipattern può essere utile quando si esamina il codice o si diagnosticano i problemi di prestazioni.
Ecco uno scenario comune: un'applicazione si comporta correttamente durante i test delle prestazioni. Viene rilasciato nell'ambiente di produzione e inizia a gestire carichi di lavoro reali. A questo punto, inizia a funzionare in modo non corretto, rifiutando le richieste utente, bloccando o generando eccezioni. Il team di sviluppo deve quindi affrontare due domande:
- Perché questo comportamento non è stato visualizzato durante il test?
- Come risolviamo in problema?
La risposta alla prima domanda è semplice. È difficile simulare utenti reali in un ambiente di test, insieme ai relativi modelli di comportamento e ai volumi di lavoro che potrebbero eseguire. L'unico modo completamente sicuro per comprendere il comportamento di un sistema sotto carico è osservarlo nell'ambiente di produzione. Per essere chiari, non è consigliabile ignorare i test delle prestazioni. I test delle prestazioni sono fondamentali per ottenere le metriche delle prestazioni di base. Tuttavia, è necessario essere pronti a osservare e correggere i problemi di prestazioni quando si verificano nel sistema live.
La risposta alla seconda domanda, come risolvere il problema, è meno semplice. Qualsiasi numero di fattori può contribuire e talvolta il problema si manifesta solo in determinate circostanze. La strumentazione e la registrazione sono fondamentali per trovare la causa radice, ma è anche necessario sapere cosa cercare.
In base agli impegni con i clienti di Microsoft Azure, sono stati identificati alcuni dei problemi di prestazioni più comuni visualizzati dai clienti nell'ambiente di produzione. Per ogni antipattern, viene descritto perché l'antipattern si verifica in genere, i sintomi dell'antipattern e le tecniche per risolvere il problema. Viene inoltre fornito codice di esempio che illustra sia l'antipattern che una soluzione di scalabilità suggerita.
Alcuni di questi antipattern potrebbero sembrare ovvi quando si leggono le descrizioni, ma si verificano più spesso di quanto si potrebbe pensare. A volte un'applicazione eredita una progettazione che ha funzionato in locale, ma non viene ridimensionata nel cloud. Oppure un'applicazione potrebbe iniziare con una progettazione molto pulita, ma man mano che vengono aggiunte nuove funzionalità, una o più di queste antipattern si intrufolano. Indipendentemente da ciò, questa guida ti aiuterà a identificare e correggere questi antipattern.
Catalogo di antipattern
Ecco l'elenco degli antipattern identificati:
Antimodello | Descrizione |
---|---|
Database occupato | Delegare un'elaborazione eccessiva a un archivio dati. |
Front End Occupato | Spostamento di attività a elevato utilizzo di risorse nei thread in background. |
I/O chiacchierone | Inviare continuamente molte richieste di rete di piccole dimensioni. |
Recupero superfluo | Recupero di più dati di quanto necessario, con conseguente I/O non necessario. |
Istanziazione non corretta | Creazione e eliminazione ripetuta di oggetti progettati per essere condivisi e riutilizzati. |
Persistenza monolitica | Uso dello stesso archivio dati per i dati con modelli di utilizzo molto diversi. |
Nessuna memorizzazione nella cache | Impossibile memorizzare nella cache i dati. |
Vicino Rumoroso | Un singolo tenant usa una quantità sproporzionata di risorse. |
Tempesta di Riprova | Tentativi troppo frequenti di ripetizione delle richieste non riuscite a un server. |
I/O sincrono | Bloccare il thread di chiamata durante il completamento dell'I/O. |
Passaggi successivi
Per altre informazioni sull'ottimizzazione delle prestazioni, vedere Efficienza delle prestazioni in Well Architected Framework