Procedure consigliate per l'architettura per il servizio app di Azure (app Web)

Assegnare priorità ai flussi utente: Non tutti i flussi sono ugualmente importanti. Identificare i percorsi critici nell'applicazione e assegnare priorità a ogni flusso per guidare le decisioni di progettazione. La progettazione del flusso utente può influenzare i livelli di servizio e il numero di istanze che scegli per un piano di App Service e nella configurazione.

Ad esempio, l'applicazione potrebbe includere livelli front-end e back-end che comunicano tramite un broker di messaggi. È possibile scegliere di segmentare i livelli in più app Web per consentire scalabilità indipendente, gestione del ciclo di vita e manutenzione. Se si inserisce un'applicazione di grandi dimensioni in un singolo piano, può causare problemi di memoria o CPU che influiscono sull'affidabilità.

Potrebbero essere necessarie più istanze sul front-end per ottenere prestazioni ottimali sul lato interfaccia utente. Tuttavia, il back-end potrebbe non richiedere lo stesso numero di istanze.

Prevedere potenziali errori: Pianificare strategie di mitigazione per potenziali errori. La tabella seguente mostra esempi di analisi della modalità di errore.

Per altre informazioni, vedere l'analisi della modalità di errore per le applicazioni di Azure.

Ridondanza della compilazione: Creare ridondanza nell'applicazione e nell'infrastruttura di supporto. Distribuire le istanze tra zone di disponibilità per migliorare la tolleranza di errore. Il traffico viene instradato verso altre zone se una zona fallisce. Distribuire l'applicazione in più aree per assicurarsi che l'app rimanga disponibile, anche se si verifica un'interruzione dell'intera area.

Creare livelli simili di ridondanza nei servizi dipendenti. Ad esempio, le istanze dell'applicazione si associano all'archivio BLOB. Considerare la configurazione dell'account di archiviazione associato con l'archiviazione ridondata per zona se un'applicazione utilizza una distribuzione ridondata per zona.

Usare più istanze: Se si esegue l'app in una sola istanza, si verifica un singolo punto di errore immediato. Assegna più istanze alla tua app per garantire alta disponibilità. Se un'istanza ha esito negativo, altre istanze possono comunque gestire le richieste in ingresso. Il codice dell'app deve essere in grado di gestire più istanze senza problemi di sincronizzazione durante la lettura da origini dati o la scrittura in origini dati.

Assicurarsi di avere ridondanza nei componenti di rete. Ad esempio, usare indirizzi IP con ridondanza della zona e servizi di bilanciamento del carico.

Avere una strategia di scalabilità affidabile: Un carico imprevisto in un'applicazione può renderlo inaffidabile. Prendere in considerazione l'approccio di ridimensionamento corretto in base alle caratteristiche del carico di lavoro. La scalabilità orizzontale, o la scalabilità orizzontale, consente di aggiungere altre istanze per distribuire il carico. La scalabilità verticale, o la scalabilità verticale, aumenta la capacità di un'istanza esistente, ad esempio CPU o memoria. Prestare attenzione al provisioning eccessivo perché l'aggiunta di istanze non necessarie aumenta i costi senza vantaggi tangibili per le prestazioni.

A volte è possibile aumentare le prestazioni per gestire il carico. Tuttavia, se il carico continua ad aumentare, scalare verso nuove istanze. Scegliere l'approccio automatico o di scalabilità automatica rispetto all'approccio manuale. Mantenere sempre un buffer di capacità aggiuntiva durante le operazioni di ridimensionamento per evitare una riduzione delle prestazioni.

Il piano di servizio app di livello che scegli influisce sul ridimensionamento in termini di numero di istanze e unità di elaborazione.

Prendere in considerazione i requisiti del protocollo di rete durante la progettazione della strategia di scalabilità, assicurandosi che siano trattati sia i modelli di traffico IPv4 che IPv6. Il servizio app supporta la connettività IPv6 in ingresso insieme a IPv4. Le reti solo IPv6 possono risolvere i problemi di esaurimento dei dispositivi IPv4. Tuttavia, i client solo IPv6 richiedono servizi di traduzione da IPv4 a IPv6 quando IPv6 non è abilitato, creando potenziali sovraccarichi di traduzione di rete. Per altre informazioni, vedere Indirizzi IP in ingresso e in uscita nel servizio app di Azure.

Assicurarsi che l'inizializzazione dell'app sia corretta in modo che le nuove istanze si avviino rapidamente e possano ricevere richieste. Puntare a creare applicazioni senza stato, quando possibile. Il ridimensionamento affidabile dello stato con nuove istanze può aumentare la complessità. Prendere in considerazione un archivio dati esterno che è possibile ridimensionare in modo indipendente se è necessario archiviare lo stato dell'applicazione. L'archiviazione dello stato della sessione in memoria può comportare la perdita dello stato della sessione quando si verifica un problema con l'applicazione o il servizio app. Limita inoltre la possibilità di distribuire il carico tra altre istanze.

Testare regolarmente le regole di scalabilità automatica. Simulare scenari di carico per verificare che l'app si adatti come previsto. È consigliabile registrare gli eventi di ridimensionamento in modo da poter risolvere i problemi che possono verificarsi e ottimizzare la strategia di scalabilità nel tempo.

App Service presenta una limitazione per il numero di istanze all'interno di un piano, che influisce sull'affidabilità del ridimensionamento. Per risolvere questo problema, una strategia consiste nel distribuire indicatori identici, con ogni stamp che esegue la propria istanza e un endpoint del piano di servizio app. È essenziale far fronte a tutti gli stamp con un servizio di bilanciamento del carico esterno per distribuire il traffico tra di essi. Usare Azure Application Gateway per le distribuzioni a zona singola e Azure Front Door per distribuzioni in più aree. Questo approccio è ideale per le applicazioni cruciali quando l'affidabilità è fondamentale. Per altre informazioni, vedere baseline mission-critical con il servizio app.

Pianificare la recuperabilità: La ridondanza è fondamentale per la continuità aziendale. Eseguire il failover su un'altra istanza se un'istanza non è raggiungibile. Esplorare le funzionalità di correzione automatica in App Service, come il ripristino automatico delle istanze.

Implementare modelli di progettazione per gestire una riduzione normale delle prestazioni per gli errori temporanei, ad esempio problemi di connettività di rete ed eventi su larga scala, ad esempio interruzioni a livello di area. Considerare i modelli di progettazione seguenti:

• il modello Bulkhead segmenta l'applicazione in gruppi isolati per evitare che un errore influisca sull'intero sistema.

• Il modello di livellamento del carico Queue-Based mette in coda le attività che fungono da buffer per attenuare i picchi di traffico.

• Il modello di ripetizione dei tentativi gestisce gli errori temporanei dovuti a problemi di rete, perdite di connessioni al database o servizi occupati.

• il modello di interruttore impedisce a un'applicazione di tentare ripetutamente di eseguire un'operazione che potrebbe non riuscire.

È possibile usare Processi Web per eseguire attività in background nell'app Web. Per eseguire tali attività in modo affidabile, assicurarsi che l'app che ospita le attività venga eseguita continuamente in base a una pianificazione o in base a trigger basati su eventi.

Per altre informazioni, vedere Modelli di progettazione dell'architettura che supportano l'affidabilità.

Eseguire test di affidabilità: Eseguire test di carico per valutare l'affidabilità e le prestazioni dell'applicazione sotto carico. I piani di test devono includere scenari che convalidano le operazioni di ripristino automatizzato.

Usare l'inserimento di errori per introdurre intenzionalmente guasti e convalidare i meccanismi di auto-riparazione e autoconservazione. Per altre informazioni, vedere Errore e libreria di azioni di Azure Chaos Studio.

Il servizio app impone limiti di risorse per le app ospitate. Il piano di servizio app determina questi limiti. Assicurarsi che i test confermino che l'app venga eseguita entro i limiti delle risorse. Per altre informazioni, vedere limiti servizio app.

Usare la funzionalità di controllo integrità per identificare i processi di lavoro che non rispondono: App Service include funzionalità predefinite che eseguono periodicamente il ping di un percorso specifico dell'applicazione web. La piattaforma esegue il ping di questo percorso per determinare se l'applicazione è integra e risponde alle richieste.

Quando il sito viene ridimensionato su più istanze, App Service esclude tutte le istanze non funzionanti dal servizio delle richieste. Questo processo migliora la disponibilità complessiva.

Il percorso di controllo dell'integrità dell'app deve effettuare un controllo dei componenti essenziali dell'applicazione, ad esempio il database, la cache o il servizio di messaggistica. Questo passaggio consente di garantire che lo stato restituito dal percorso del controllo della salute sia un quadro accurato dell'integrità complessiva dell'applicazione.

Usare la funzionalità di correzione automatica: A volte l'applicazione potrebbe riscontrare comportamenti imprevisti che un riavvio semplice può risolvere. Usare la funzionalità di correzione automatica per definire una condizione che attiva il ripristino automatico e l'azione che viene ripristinata automaticamente viene avviata quando viene soddisfatta tale condizione. Per ulteriori informazioni, vedere Panoramica della diagnostica di App Service.

Report del punteggio di resilienza del servizio App: Per esaminare le raccomandazioni personalizzate sulle procedure consigliate, vedere la panoramica della diagnostica del Servizio App.

Esaminare le baseline di sicurezza: Per migliorare il comportamento di sicurezza dell'applicazione ospitata in un piano di servizio app, esaminare la baseline di sicurezza per il servizio app.

Usare il runtime e le librerie più recenti: Testare accuratamente le compilazioni dell'applicazione prima di eseguire aggiornamenti per rilevare i problemi in anticipo e garantire una transizione uniforme alla nuova versione. Il servizio app supporta i criteri di supporto del runtime del linguaggio per aggiornare gli stack esistenti e ritirare gli stack di fine supporto.

Creare la segmentazione attraverso i limiti di isolamento per contenere violazioni: Applicare la segmentazione delle identità. Ad esempio, implementare il controllo degli accessi in base al ruolo per assegnare autorizzazioni specifiche in base ai ruoli. Seguire il principio dei privilegi minimi per limitare i diritti di accesso solo a ciò che è necessario. Creare anche la segmentazione a livello di rete. Integrare le app del servizio app con una rete virtuale di Azure per l'isolamento e definire gruppi di sicurezza di rete (NSG) per filtrare il traffico.

I piani di App Service offrono il tier App Service Environment, che fornisce un alto grado di isolamento. Con l'ambiente del servizio app si ottengono risorse di calcolo e rete dedicate.

Applicare i controlli di accesso alle identità: Limitare l'accesso interno all'app Web e l'accesso esterno dall'app Web ad altre risorse. Questa configurazione applica i controlli di accesso alle identità e consente di mantenere il comportamento di sicurezza complessivo del carico di lavoro.

Usare Microsoft Entra ID per tutte le esigenze di autenticazione e autorizzazione. Usare i ruoli predefiniti, come un Collaboratore del Piano Web, Collaboratore del Sito Web, un Collaboratore generico , Lettore e Proprietario.

Applicare i controlli di sicurezza di rete: Integrare il servizio app con una rete virtuale per controllare il traffico in uscita. Usare gli endpoint privati per controllare il traffico in ingresso, limitare l'accesso all'istanza del servizio app dall'interno della rete virtuale e disabilitare l'accesso a Internet pubblico. Per altre informazioni, vedere Routing di rete.

Distribuire un web application firewall (WAF) per proteggere da vulnerabilità comuni. Sia Application Gateway che Azure Front Door dispongono di funzionalità WAF integrate.

Configurare le regole del proxy inverso e le impostazioni di rete in modo appropriato per ottenere il livello di sicurezza e controllo desiderato. Ad esempio, aggiungere delle regole NSG nella subnet dell'endpoint privato per accettare solo il traffico proveniente dal proxy inverso.

Il traffico in uscita dall'applicazione ad altri servizi PaaS deve essere su endpoint privati. Prendere in considerazione l'inserimento di un componente firewall per limitare il traffico in uscita verso Internet pubblico. Entrambi gli approcci consentono di evitare l'esfiltrazione dei dati.

Per ulteriori informazioni, vedere le funzionalità di rete di App Service.

Crittografare i dati: Proteggere i dati in transito usando TLS (Transport Layer Security) end-to-end. Usare le chiavi gestite dal cliente per la crittografia completa dei dati inattivi.

Non usare protocolli legacy come TLS 1.0 e 1.1. Assicurarsi che tutte le app Web usino solo HTTPS e applichino TLS 1.2 o versione successiva. La versione minima predefinita di TLS è 1.2. Per altre informazioni, vedere la panoramica del TLS del Servizio App .

Tutte le istanze del servizio app hanno un nome di dominio predefinito. Usare un dominio personalizzato e proteggere tale dominio usando i certificati.

Crittografia TLS end-to-end: La crittografia TLS end-to-end è disponibile nei piani di servizio app Premium. Questa funzionalità crittografa il traffico nell'intera transazione, riducendo al minimo il rischio di intercettazione del traffico.

Ridurre la superficie di attacco: Rimuovere le configurazioni predefinite non necessarie. Ad esempio, disabilitare il debug remoto, l'autenticazione locale per i siti di Gestione controllo del codice sorgente e l'autenticazione di base. Disabilitare protocolli non protetti come HTTP e FTP (File Transfer Protocol). Applicare le configurazioni usando i criteri di Azure. Per altre informazioni, vedere Criteri di Azure.

Implementare criteri CORS (Cross-Origin Resource Sharing) restrittivi: Usare criteri CORS restrittivi nell'app Web per accettare solo le richieste provenienti da domini, intestazioni e altri criteri consentiti. Applicare i criteri CORS usando le definizioni predefinite dei criteri di Azure.

Usare le identità gestite:Abilitare le identità gestite per l'istanza del servizio app per accedere in modo più sicuro ad altri servizi di Azure senza dover gestire le credenziali.

Proteggere i segreti dell'applicazione: È necessario gestire informazioni riservate, ad esempio chiavi API o token di autenticazione. Invece di incorporare direttamente questi segreti nel codice dell'applicazione o nei file di configurazione, è possibile utilizzare i riferimenti di Azure Key Vault nella configurazione dell'app. All'avvio dell'applicazione, il servizio app recupera automaticamente i valori del segreto da Key Vault usando l'identità gestita dell'app.

Abilitare i log delle risorse per l'applicazione: Abilitare i log delle risorse per l'applicazione per creare percorsi di attività completi che forniscono dati preziosi durante le indagini che seguono gli eventi imprevisti di sicurezza. Per altre informazioni, vedere Log delle risorse di Monitoraggio di Azure.

Prendere in considerazione la registrazione come parte del processo di modellazione delle minacce quando si valutano le minacce.

Stimare il costo iniziale: Come parte dell'esercizio di modellazione dei costi, usare il calcolatore prezzi di Azure per valutare i costi approssimativi associati a vari livelli in base al numero di istanze che si prevede di eseguire. Ogni livello di servizio app offre diverse opzioni di calcolo.

Monitorare continuamente il modello di costo per tenere traccia delle spese.

Valutare le opzioni scontate: I livelli superiori includono istanze di calcolo dedicate. È possibile applicare uno sconto per la prenotazione se il carico di lavoro ha un modello di utilizzo prevedibile e coerente. Assicurarsi di analizzare i dati di utilizzo per determinare il tipo di prenotazione più adatto al carico di lavoro. Per ulteriori informazioni, vedere Risparmio sui costi con le istanze riservate del Servizio App.

Informazioni sui contatori di utilizzo: Azure addebita una tariffa oraria, ripartita al secondo, in base al piano tariffario del piano di servizio app. Gli addebiti si applicano a ogni istanza con scalabilità orizzontale nel piano, in base al tempo di allocazione dell'istanza della macchina virtuale. Prestare attenzione alle risorse di calcolo sottoutilizzate che potrebbero aumentare i costi a causa della sovrassegnazione derivante dalla scelta non ottimale dello SKU o da una configurazione di ridimensionamento non corretta.

Le funzionalità aggiuntive del servizio app, ad esempio la registrazione del dominio personalizzato e i certificati personalizzati, possono aggiungere costi. Altre risorse, ad esempio reti virtuali che isolano la soluzione o gli insiemi di credenziali che proteggono i segreti del carico di lavoro, possono integrarsi anche con le risorse del Servizio App e aggiungere costi. Per altre informazioni, vedere Informazioni sul modello di fatturazione completo per il servizio app.

Considerare i compromessi tra densità e isolamento: È possibile usare i piani di servizio app per ospitare più applicazioni nello stesso ambiente di calcolo, risparmiando così i costi con gli ambienti condivisi. Per altre informazioni, vedere Compromessi.

Valutare gli effetti della strategia di ridimensionamento sui costi: Quando si implementa la scalabilità automatica, è necessario progettare, testare e configurare correttamente sia per la scalabilità in espansione (scale-out) sia per la scalabilità in contrazione (scale-in). Stabilire limiti massimi e minimi precisi per la scalabilità automatica.

Inizializzare in modo proattivo l'applicazione per una scalabilità affidabile. Ad esempio, non attendere fino a quando la CPU raggiunge 95% utilizzo. Al contrario, attivare il ridimensionamento a circa 65% per consentire l'allocazione e l'inizializzazione di nuove istanze durante il processo di ridimensionamento. Tuttavia, questa strategia potrebbe comportare capacità inutilizzata.

È consigliabile combinare e bilanciare i meccanismi per scalare verticalmente e orizzontalmente. Ad esempio, un'app può scalare verticalmente per un certo periodo di tempo e quindi scalare orizzontalmente in base alle esigenze. Esplorare i livelli elevati che offrono capacità di grandi dimensioni e un utilizzo efficiente delle risorse. In base ai modelli di utilizzo, i livelli Premium più elevati sono spesso più convenienti perché sono più capaci.

Ottimizzare i costi dell'ambiente: Prendere in considerazione l'uso del livello Basic o del livello gratuito per eseguire ambienti di pre-produzione. Questi livelli sono a basso costo e prestazioni ridotte. Se usate il livello Basic o il livello gratuito, usate la governance per applicare il livello, limitate il numero di istanze e CPU, limitate il ridimensionamento e la conservazione dei log.

Implementare modelli di progettazione: Questa strategia riduce il volume di richieste generate dal carico di lavoro. Prendere in considerazione l'uso di modelli come il modello Back-end per i front-end e il modello di aggregazione del gateway per ridurre al minimo il numero di richieste e ridurre i costi.

Controllare regolarmente i costi correlati ai dati: I periodi di conservazione dei dati estesi o i livelli di archiviazione costosi possono comportare costi di archiviazione elevati. Più spese possono accumularsi a causa dell'utilizzo della larghezza di banda e della conservazione prolungata dei dati di registrazione.

Valutare la possibilità di implementare la memorizzazione nella cache per ridurre al minimo i costi di trasferimento dei dati. Iniziare con la memorizzazione nella cache in memoria locale e quindi esplorare le opzioni di memorizzazione nella cache distribuita per ridurre il numero di richieste al database back-end. Prendere in considerazione i costi del traffico della larghezza di banda associati alla comunicazione tra aree se il database si trova in un'area diversa.

Ottimizzare i costi di distribuzione: Sfruttare i vantaggi degli slot di distribuzione per ottimizzare i costi. Lo slot funziona nello stesso ambiente di calcolo dell'istanza di produzione. Usarli in modo strategico per scenari come distribuzioni blu-verde che passano da uno slot all'altro. Questo approccio riduce al minimo i tempi di inattività e garantisce transizioni uniformi.

Usare gli slot di distribuzione con cautela. È possibile introdurre problemi, ad esempio eccezioni o perdite di memoria, che potrebbero influire sulle istanze esistenti e sulle nuove istanze. Assicurarsi di testare accuratamente le modifiche. Per altre informazioni sulle linee guida operative, vedere Operational Excellence.

Gestire le versioni: Usare gli slot di distribuzione per gestire in modo efficace le versioni. È possibile distribuire l'applicazione in uno slot, eseguire test e convalidarne la funzionalità. Dopo la verifica, è possibile spostare facilmente l'app nell'ambiente di produzione. Questo processo non comporta costi aggiuntivi perché lo slot viene eseguito nello stesso ambiente di macchina virtuale (VM) dell'istanza di produzione.

Usare la funzionalità di scambio con anteprima (scambio a più fasi). Lo scambio con l'anteprima consente di testare l'app negli slot di staging con le impostazioni di produzione e anche di riscaldare l'app. Dopo aver eseguito i test e aver riscaldato tutti i percorsi necessari, è possibile completare lo scambio. L'app riceverà quindi il traffico di produzione senza riavviare.

Eseguire test automatizzati: Prima di alzare di livello una versione dell'app Web, testarne accuratamente le prestazioni, le funzionalità e l'integrazione con altri componenti. Usare Test di carico di Azure. Si integra con Apache JMeter, uno strumento molto diffuso per i test delle prestazioni. Esplorare gli strumenti automatizzati per altri tipi di test, ad esempio Phantom per i test funzionali.

Automatizzare le distribuzioni: Usare pipeline di integrazione continua e distribuzione continua con Azure DevOps o GitHub Actions per automatizzare le distribuzioni e ridurre il lavoro manuale. Per altre informazioni, vedere Distribuzione continua nel Servizio App.

Distribuire unità non modificabili: Implementare il modello Deployment Stamps per suddividere App Service in un'unità non modificabile. Il servizio app supporta l'uso di contenitori, intrinsecamente non modificabili. Prendere in considerazione contenitori personalizzati per l'app Web del servizio app.

Ogni timbro rappresenta un'unità autonoma che è possibile espandere o ridurre rapidamente. Le unità basate su questo stamp sono temporanee e senza stato. La progettazione senza stato semplifica le operazioni e la manutenzione. Questo approccio è ideale per le applicazioni cruciali. Per altre informazioni, vedere baseline mission-critical con il servizio app.

Usare una tecnologia IaC (Infrastructure as Code), ad esempio Bicep, per eliminare le unità con ripetibilità e coerenza.

Mantenere sicuri gli ambienti di produzione: Creare piani di servizio app separati per eseguire ambienti di produzione e pre-produzione. Non apportare modifiche direttamente nell'ambiente di produzione per garantire stabilità e affidabilità. Le istanze separate consentono flessibilità nello sviluppo e nei test prima di promuovere le modifiche all'ambiente di produzione.

Usare ambienti bassi per esplorare nuove funzionalità e configurazioni in modo isolato. Mantenere temporanei gli ambienti di sviluppo e test.

Gestire i certificati: Per i domini personalizzati, è necessario gestire i certificati TLS.

Disporre di processi per acquistare, rinnovare e convalidare i certificati. Se possibile, eseguire l'offload di questi processi nel servizio app. Se si utilizza il proprio certificato, è necessario gestirne il rinnovo. Scegliere un approccio più adatto ai requisiti di sicurezza.

Identificare e monitorare gli indicatori di prestazioni: Impostare le destinazioni per gli indicatori chiave per l'applicazione, ad esempio il volume di richieste in ingresso, il tempo impiegato dall'applicazione per rispondere alle richieste, alle richieste in sospeso e agli errori nelle risposte HTTP. Prendere in considerazione gli indicatori chiave come parte della baseline delle prestazioni per il carico di lavoro.

Acquisire le metriche del servizio app che costituiscono la base degli indicatori di prestazioni. Raccogliere i log per ottenere informazioni dettagliate sull'utilizzo delle risorse e sulle attività. Usare gli strumenti di monitoraggio delle prestazioni delle applicazioni, ad esempio Application Insights, per raccogliere e analizzare i dati sulle prestazioni dall'applicazione. Per ulteriori informazioni, consultare il riferimento dati di monitoraggio di App Service .

Includere la strumentazione a livello di codice, la traccia delle transazioni e la profilatura delle prestazioni.

Valutare la capacità: Simulare vari scenari utente per determinare la capacità ottimale necessaria per gestire il traffico previsto. Usare Test di carico per comprendere il comportamento dell'applicazione con livelli di carico diversi.

Scegliere il livello corretto: Usare il calcolo dedicato per i carichi di lavoro di produzione. I livelli Premium v3 offrono SKU più grandi con maggiore capacità di memoria e CPU, più istanze e ulteriori funzionalità, come la ridondanza di zona. Per altre informazioni, vedere Piano tariffario Premium v3.

Ottimizzare la strategia di scalabilità: Quando possibile, usare la scalabilità automatica anziché regolare manualmente il numero di istanze quando cambia il carico dell'applicazione. Con la scalabilità automatica, il servizio app regola la capacità del server in base a regole o trigger predefiniti. Assicurarsi di eseguire test delle prestazioni adeguati e impostare le regole corrette per i trigger corretti.

Se si assegna la priorità alla semplicità durante l'installazione iniziale, usare un'opzione di scalabilità automatica che richiede solo l'impostazione dei limiti, senza dover definire le regole.

Disporre di risorse sufficienti prontamente disponibili per garantire prestazioni ottimali. Allocare le risorse in modo appropriato per mantenere gli obiettivi di prestazioni, ad esempio il tempo di risposta o la velocità effettiva. Quando necessario, valutare la sovrasocazione delle risorse.

Quando si definiscono le regole di scalabilità automatica, tenere conto del tempo necessario per l'inizializzazione dell'applicazione. Prendere in considerazione questo sovraccarico quando si prendono tutte le decisioni di ridimensionamento.

Usare la memorizzazione nella cache: Il recupero di informazioni da una risorsa che non cambia frequentemente ed è costoso per l'accesso influisce sulle prestazioni. Le query complesse, inclusi le unioni e più ricerche, contribuiscono al tempo di esecuzione. Eseguire la memorizzazione nella cache per ridurre al minimo il tempo di elaborazione e la latenza. Memorizzare nella cache i risultati delle query per evitare round trip ripetuti al database o al back-end e ridurre il tempo di elaborazione per le richieste successive.

Per altre informazioni sull'uso della cache locale e distribuita nel carico di lavoro, vedere Memorizzazione nella cache.

Esaminare gli antipattern delle prestazioni: Per assicurarsi che l'applicazione Web offra prestazioni e scalabilità conformemente ai requisiti aziendali, evitare gli antipattern tipici. La tabella seguente descrive alcuni antipattern corretti dal servizio app.