Cenni preliminari sulle prestazioni

Articolo
10/22/2014

Aggiornamento: novembre 2007

Le prestazioni possono rappresentare un fattore chiave per il corretto funzionamento di un sito o di un progetto Web. In questo argomento vengono fornite linee guida per migliorare le prestazioni di un sito e collegamenti alla documentazione relativa alle procedure consigliate.

Vengono illustrati i seguenti argomenti:

Suggerimenti
Informazioni di supporto
Esempi di codice

Suggerimenti

Nell'elenco riportato di seguito vengono forniti collegamenti a risorse del sito Web Microsoft che descrivono le procedure consigliate complessive per le prestazioni del sito Web ASP.NET.

Chapter 4 — Architecture and Design Review of a .NET Application for Performance and Scalability (informazioni in lingua inglese)
Chapter 6 — Improving ASP.NET Performance (informazioni in lingua inglese)
Microsoft Patterns and Practices (informazioni in lingua inglese)

Torna all'inizio

Informazioni di supporto

Nella sezione vengono elencate le tecniche utilizzabili per ottimizzare le prestazioni delle applicazioni Web ASP.NET. Tali istruzioni sono divise nelle seguenti sezioni:

Elaborazione delle pagine e dei controlli server
Gestione dello stato
Accesso ai dati
Applicazioni Web
Procedure di codifica

Elaborazione delle pagine e dei controlli server

Nelle istruzioni riportate di seguito vengono forniti suggerimenti per un utilizzo efficiente delle pagine e dei controlli ASP.NET.

Evitare round trip al server non necessari°°°In alcune situazioni, è possibile utilizzare ASP.NET AJAX e il rendering parziale della pagina per effettuare attività nel codice del browser senza eseguire un postback completo. Ad esempio, è possibile utilizzare le funzionalità ASP.NET AJAX per convalidare l'input dell'utente nel browser prima che venga inviato al server. Per ulteriori informazioni, vedere°Cenni preliminari su ASP.NET AJAX e Cenni preliminari sul rendering a pagina parziale.
In generale, se non è necessario inoltrare al server informazioni da verificare o scrivere in un archivio dati, è possibile migliorare le prestazioni della pagina (e, di conseguenza, l'esperienza utente) evitando i round trip al server.
Se si sviluppano controlli server personalizzati, progettarli in modo che eseguano il rendering dello script client per alcune delle relative funzionalità. In tal modo è possibile ridurre notevolmente il numero di invii delle informazioni al server Web. Per ulteriori informazioni, vedere°Sviluppo di controlli server ASP.NET personalizzati e Creazione di uno script client personalizzato utilizzando Microsoft AJAX Library.
Utilizzare la proprietà IsPostBack dell'oggetto Page per evitare un'elaborazione non necessaria°°°Evitare di eseguire codice a ogni postback se deve essere eseguito solo la prima volta che la pagina viene richiesta. È possibile testare la proprietà IsPostBack per eseguire codice in base a determinate condizioni, a seconda che la pagina venga eseguita o meno in risposta a un evento del controllo server.
Lasciare attiva la memorizzazione nel buffer a meno che non vi sia una ragione specifica per disattivarla La disattivazione della memorizzazione nel buffer per le pagine Web ASP.NET comporta una considerevole riduzione delle prestazioni. Per ulteriori informazioni, vedere la proprietà Buffer.
Utilizzare il metodo Transfer dell'oggetto Server o il cross-page posting per eseguire il reindirizzamento tra le pagine ASP.NET della stessa applicazione Per ulteriori informazioni, vedere Reindirizzamento degli utenti a un'altra pagina.

Gestione dello stato

Nelle istruzioni riportate di seguito vengono forniti suggerimenti su come rendere efficiente la gestione dello stato.

Salvare lo stato di visualizzazione dei controlli server solo quando necessario Lo stato di visualizzazione consente ai controlli server di ricompilare i valori delle proprietà in un round trip senza la necessità di scrivere codice. Tuttavia, lo stato di visualizzazione influisce sulle prestazioni e sulle dimensioni della pagina poiché viene passato al server e dal server in un campo modulo nascosto. Se un controllo server viene associato a dati a ogni round trip, lo stato di visualizzazione salvato non è utile in quanto i valori del controllo vengono sostituiti con nuovi valori durante l'associazione dati. In questo caso, la disattivazione dello stato di visualizzazione consente di ridurre il tempo necessario per l'elaborazione nonché la dimensione della pagina.

Per impostazione predefinita, lo stato di visualizzazione è attivato per tutti i controlli server. Per disattivarlo relativamente a un controllo, impostare la proprietà EnableViewState del controllo su false, come illustrato nell'esempio seguente:
```
<asp:datagrid EnableViewState="false" datasource="..." 
   />
```
È anche possibile disattivare lo stato di visualizzazione per una pagina mediante la direttiva @ Page, come illustrato nell'esempio seguente:
```
<%@ Page EnableViewState="false" %>
```
Tale disattivazione risulta utile quando la pagina non richiede l'elaborazione del postback.

Nota:

L'attributo EnableViewState è supportato anche nella direttiva @ Control per specificare se lo stato di visualizzazione è attivato per un controllo utente.

Per analizzare la dimensione dello stato di visualizzazione di una pagina, attivare l'analisi della pagina impostando trace="true" nella direttiva @ Page. Nell'output di analisi esaminare la colonna Viewstate della tabella Gerarchia controllo. Per ulteriori informazioni, vedere la classe Cenni preliminari sull'analisi di ASP.NET.
Evitare di utilizzare la crittografia dello stato di visualizzazione, a meno che non sia necessario La crittografia dello stato di visualizzazione impedisce agli utenti di leggere i valori dello stato di visualizzazione nel campo modulo nascosto di tale stato. Ad esempio, è possibile crittografare lo stato di visualizzazione se una pagina include un controllo GridView che gestisce il campo di un identificatore nella proprietà DataKeyNames per coordinare gli aggiornamenti dei record. Poiché non si desidera che l'identificatore sia visibile agli utenti, è possibile crittografare lo stato di visualizzazione. Tuttavia, a livello di prestazioni la crittografia ha un costo costante per l'inizializzazione e un costo aggiuntivo che dipende dalle dimensioni dello stato di visualizzazione da crittografare. La crittografia viene eseguita ogni volta che la pagina viene caricata. Pertanto, si verifica lo stesso effetto a livello di prestazioni quando la pagina viene richiesta per la prima volta e durante ogni postback.

Nota:
L'attributo EnableViewState è supportato anche nella direttiva @ Control per specificare se lo stato di visualizzazione è attivato per un controllo utente.

Disattivare lo stato sessione quando non lo si utilizza Per disattivare lo stato sessione di una pagina, impostare l'attributo EnableSessionState nella direttiva @ Page su false, come illustrato nell'esempio seguente:

<%@ Page EnableSessionState="false" %>

Nota:
Se una pagina richiede l'accesso alle variabili di sessione ma non creerà variabili né le modificherà, impostare l'attributo EnableSessionState nella direttiva @ Page su ReadOnly.

Lo stato sessione può essere disattivato anche per i metodi dei servizi Web ASP.NET. Per ulteriori informazioni, vedere la classe Cenni preliminari sui servizi delle applicazioni ASP.NET.

Per disattivare lo stato della sessione per un'applicazione, impostare l'attributo Mode su Off nella sezione SessionState del file Web.config dell'applicazione, come nell'esempio seguente:

<sessionState mode="Off" />

Scegliere il provider di stato sessione appropriato per l'applicazione In ASP.NET vengono forniti diversi modi per archiviare i dati di sessione dell'applicazione, tra cui lo stato sessione in-process, lo stato sessione out-of-process come un servizio Windows e lo stato sessione out-of-process in un database SQL Server (è anche possibile creare un provider di stato sessione personalizzato per archiviare i dati di sessione in un archivio dati specificato dall'utente). Ogni approccio presenta vantaggi, ma lo stato sessione in-process è di gran lunga quello più rapido. Se si utilizza lo stato sessione solo per piccole quantità di dati in esso, utilizzare il provider in-process. Utilizzare, invece, le opzioni dello stato sessione out-of-process se l'applicazione viene distribuita tra più processori o computer o se si desidera salvare in modo permanente i dati di sessione quando viene riavviato un server o un processo. Per ulteriori informazioni, vedere la classe Cenni preliminare sullo stato della sessione ASP.NET.

Accesso ai dati

Nelle istruzioni riportate di seguito vengono forniti suggerimenti per rendere efficiente l'accesso ai dati nell'applicazione.

Utilizzare SQL Server e stored procedure per l'accesso ai dati SQL Server è la scelta consigliata per l'archivio dati per la creazione di applicazioni Web scalabili e a prestazioni elevate. Quando si utilizza il provider SQL Server gestito, è possibile ottenere un ulteriore incremento delle prestazioni utilizzando stored procedure compilate, laddove possibile, anziché comandi SQL. Per informazioni, vedere Configurazione di parametri e di tipi di dati dei parametri (ADO.NET).
Utilizzare la classe SqlDataReader per un cursore di dati rapido e forward-only La classe SqlDataReader crea un flusso di dati forward-only in sola lettura recuperato da un database SQL Server. La classe SqlDataReader utilizza il formato nativo di trasferimento dei dati su rete di SQL Server per leggere i dati direttamente da una connessione di database. Se possibile, utilizzare la classe SqlDataReader poiché offre prestazioni migliori rispetto alla classe DataSet. Ad esempio, quando si associa un controllo dati al controllo SqlDataSource, si otterranno prestazioni migliori se si imposta la proprietà DataSourceMode su DataReader (tuttavia, un lettore dati supporta un numero inferiore di funzionalità rispetto alla modalità DataSet). La classe SqlDataReader implementa l'interfaccia IEnumerable, che consente di associarvi controlli server. Per ulteriori informazioni, vedere la classe SqlDataReader e Accesso ai dati tramite ASP.NET.
Quando possibile, memorizzare nella cache i dati e l'output delle pagine Utilizzare la memorizzazione nella cache di ASP.NET se le pagine o i dati devono essere calcolati in modo dinamico per ogni richiesta di pagina. Se possibile, progettare le richieste di dati e di pagine per la memorizzazione nella cache, soprattutto per le situazioni in cui si prevede un traffico elevato. L'utilizzo corretto della cache può migliorare le prestazioni del sito più dell'utilizzo di qualsiasi altra funzionalità di .NET Framework.

Quando si utilizza la memorizzazione nella cache di ASP.NET, seguire le linee guida riportate di seguito. In primo luogo, non memorizzare nella cache un numero eccessivo di elementi, poiché ogni elemento memorizzato nella cache richiede memoria del server. Ad esempio, non memorizzare nella cache elementi facilmente ricalcolabili o utilizzati di rado. In secondo luogo, non assegnare una scadenza breve agli elementi memorizzati nella cache. Gli elementi che scadono in breve tempo possono determinare un lavoro aggiuntivo per il codice di pulitura e per il Garbage Collector. È possibile monitorare il ricambio nella cache causato da elementi in scadenza utilizzando il contatore delle prestazioni Tasso di ricambio complessivo della cache associato all'oggetto prestazione Applicazioni ASP.NET. Un tasso di ricambio elevato può indicare l'esistenza di un problema, specie quando gli elementi vengono rimossi prima della scadenza. Questa situazione è talvolta definita pressione della memoria.

Per informazioni su come memorizzare nella cache l'output delle pagine e le richieste di dati, vedere Cenni preliminari sull'inserimento nella cache in ASP.NET.
Utilizzare la dipendenza della cache SQL in modo appropriato Per la memorizzazione nella cache dei dati di SQL Server, ASP.NET supporta sia il polling basato su tabella che la notifica delle query, a seconda della versione di SQL Server in uso. Il polling basato su tabella è supportato da tutte le versioni di SQL Server. Nel polling basato su tabella, se vengono modificati i dati in una tabella, vengono invalidati tutti gli elementi della cache dipendenti dalla tabella. Questa situazione può determinare un ricambio non necessario nella cache. Il polling basato su tabella non è consigliabile per le tabelle sottoposte a frequenti modifiche. Ad esempio, il polling basato su tabella sarebbe consigliabile per una tabella di catalogo modificata raramente, mentre non sarebbe consigliabile per una tabella degli ordini aggiornata di frequente.

La notifica delle query è supportata da SQL Server 2005 e versioni successive. Tale notifica utilizza le query SQL°per rilevare le modifiche in un insieme di righe di destinazione. In tal modo viene ridotto il numero di notifiche inviate quando viene modificata una tabella. La notifica delle query può fornire prestazioni migliori rispetto al polling basato su tabella, ma non è adatta per migliaia di query.

Per ulteriori informazioni sulla dipendenza della cache SQL, vedere Procedura dettagliata: utilizzo della memorizzazione nella cache di output di ASP.NET con SQL Server e Inserimento nella cache in ASP.NET con la classe SqlCacheDependency.
**Utilizzare il paging e l'ordinamento dell'origine dati anziché il paging e l'ordinamento dell'interfaccia utente **La funzionalità di paging dell'interfaccia utente dei controlli dati quali DetailsView e GridView può essere utilizzata con qualsiasi oggetto origine dati che supporti l'interfaccia ICollection. Per ogni operazione di paging, il controllo dati esegue una query sull'origine dati per l'intero insieme di dati, seleziona la riga o le righe da visualizzare e ignora i restanti dati.

Se un controllo origine dati implementa DataSourceView e se la proprietà CanPage restituisce true, il controllo dati utilizza il paging dell'origine dati anziché quello dell'interfaccia utente. In tal caso, il controllo dati richiede solo le righe necessarie per ogni pagina da visualizzare. Pertanto, il paging dell'origine dati è più efficace del paging dell'interfaccia utente. Tra i controlli ASP.NET standard, solo i controlli origine dati ObjectDataSource e LinqDataSource supportano il paging dell'origine dati. Per attivare il paging dell'origine dati per altri controlli origine dati, è possibile ereditare dal controllo origine dati che si desidera utilizzare e modificarne il comportamento.
**Utilizzare una colonna Timestamp per il controllo della concorrenza con il controllo LinqDataSource **Se una tabella del database SQL Server non contiene una colonna Timestamp (tipo di dati SQL Server), il controllo LinqDataSource verifica la concorrenza dei dati archiviando i valori dei dati originali nella pagina Web. LINQ to SQL controlla i valori originali rispetto al database prima che i dati vengano aggiornati o eliminati. Questo approccio può creare una pagina Web di grandi dimensioni se il record di dati contiene molte colonne o valori di colonna elevati. Può rappresentare anche un rischio per la sicurezza se il record contiene dati che non si desidera esporre nella pagina. Quando una tabella di database dispone di una colonna Timestamp, il controllo LinqDataSource archivia solo il valore di timestamp per i confronti futuri. LINQ to SQL può controllare la coerenza dei dati determinando se il timestamp originale corrisponde al valore di timestamp corrente nella tabella. Per ulteriori informazioni sui timestamp, vedere timestamp (Transact-SQL) sul sito Web MSDN.

**Valutare il vantaggio a livello di sicurezza della convalida degli eventi rispetto al costo in termini di prestazioni **I controlli che derivano dalle classi System.Web.UI.WebControls e System.Web.UI.HtmlControls possono convalidare che un evento ha avuto origine dall'interfaccia utente visualizzata dal controllo. In questo modo si evita che il controllo risponda a notifiche di eventi di cui è stato effettuato lo spoofing. Ad esempio, mediante la convalida degli eventi, il controllo DetailsView può impedire che un utente malintenzionato effettui una chiamata a Delete (non supportata implicitamente nel controllo) e modifichi il controllo in eliminazione di dati. La convalida degli eventi ha un costo a livello di prestazioni. È possibile controllare la convalida degli eventi mediante l'elemento di configurazione EnableEventValidation e il metodo RegisterForEventValidation. Il costo della convalida dipende dal numero di controlli nella pagina e rientra nell'intervallo di alcuni punti percentuali.

Nota sulla sicurezza:
Si consiglia di non disabilitare la convalida degli eventi. Prima di disattivare la convalida degli eventi, assicurarsi che non possa essere costruito alcun postback che abbia un effetto indesiderato sull'applicazione.

**Utilizzare la memorizzazione nella cache, l'ordinamento e il filtro del controllo SqlDataSource **Se la proprietà DataSourceMode del controllo SqlDataSource è impostata su DataSet, il controllo SqlDataSource può memorizzare nella cache il set di risultati di una query. Le operazioni di filtro e di ordinamento del controllo SqlDataSource possono quindi utilizzare i dati memorizzati nella cache. Un'applicazione può essere eseguita in modo più rapido se si memorizza nella cache l'intero dataset e se si utilizzano le proprietà FilterExpression e SortParameterName per eseguire l'ordinamento e il filtro. Il controllo origine dati può quindi evitare di eseguire query SQL con le clausole Where e Sort By per accedere al database ogni volta che gli utenti ordinano o filtrano i dati nell'interfaccia utente.

Applicazioni Web

Nelle linee guida riportate di seguito vengono forniti suggerimenti su come far funzionare in modo efficiente le applicazioni Web nel loro complesso.

Precompilare il sito Un'applicazione Web viene sottoposta alla compilazione batch alla prima richiesta di una risorsa, ad esempio una pagina Web ASP.NET. Se nessuna pagina dell'applicazione è stata compilata, con la compilazione batch verranno compilate tutte le pagine della directory in blocchi per garantire un migliore utilizzo di dischi e memoria. È possibile utilizzare lo Strumento di compilazione ASP.NET (Aspnet_compiler.exe) per precompilare un'applicazione Web. Per la compilazione sul posto, lo strumento di compilazione chiama il runtime ASP.NET per compilare il sito così come quando un utente richiede una pagina del sito Web. È possibile precompilare un'applicazione Web in modo da conservare il markup dell'Interfaccia utente, oppure precompilare le pagine in modo che il codice sorgente non possa essere modificato. Per ulteriori informazioni, vedere la classe Procedura: precompilare siti Web ASP.NET.
Disattivare la modalità di debug Disattivare sempre la modalità di debug prima di distribuire un'applicazione di produzione o di eseguire misurazioni delle prestazioni. Se la modalità di debug è attivata, può verificarsi una riduzione delle prestazioni dell'applicazione. Per informazioni sull'impostazione della modalità di debug, vedere Modifica dei file di configurazione ASP.NET.
Ottimizzare i file di configurazione per il server Web e per specifiche applicazioni La configurazione predefinita di ASP.NET consente l'utilizzo del più ampio insieme di funzionalità e degli scenari più comuni. È possibile modificare alcune impostazioni di configurazione predefinite per migliorare le prestazioni delle applicazioni, a seconda delle funzionalità utilizzate. Nell'elenco seguente sono incluse le modifiche di configurazione che è necessario prendere in considerazione:
- Attivare l'autenticazione solo per le applicazioni che la richiedono Per impostazione predefinita, la modalità di autenticazione per le applicazioni ASP.NET è Windows o la modalità NTLM integrata. Nella maggior parte dei casi è preferibile disattivare l'autenticazione nel file Machine.config e attivarla nei file Web.config delle singole applicazioni che la richiedono.
- Configurare l'applicazione per l'utilizzo delle impostazioni di codifica di richiesta e risposta appropriate La codifica predefinita di ASP.NET è UTF-8. Se l'applicazione utilizza solo caratteri ASCII, configurarla per ASCII per ottenere un lieve miglioramento delle prestazioni.
- Disattivare AutoEventWireup per l'applicazione L'impostazione dell'attributo AutoEventWireup su false nel file Web.config impedisce che la pagina associ gli eventi di pagina ai metodi in base a una corrispondenza tra nomi (ad esempio, Page_Load). In tal modo viene fornito alle pagine un lieve incremento delle prestazioni. Per gestire gli eventi di pagina, utilizzare una delle due strategie riportate di seguito. La prima strategia consiste nell'eseguire l'override dei metodi. Ad esempio, è possibile eseguire l'override del metodo OnLoad dell'oggetto Page per scrivere codice per l'evento di caricamento della pagina (assicurarsi di chiamare il metodo di base per garantire la generazione di tutti gli eventi). La seconda strategia consiste nell'eseguire l'associazione agli eventi di pagina mediante la parola chiave Handles in Visual Basic o mediante l'associazione di delegati in C#.
- Rimuovere i moduli inutilizzati dalla pipeline di elaborazione delle richieste Per impostazione predefinita, tutte le funzionalità restano attive nel nodo HttpModules del file Machine.config del server Web. A seconda delle funzionalità utilizzate dall'applicazione, è possibile rimuovere i moduli inutilizzati dalla pipeline di richieste per ottenere un lieve incremento delle prestazioni. Revisionare ogni modulo e le relative funzionalità e personalizzarlo secondo le proprie esigenze. Ad esempio, se nell'applicazione non vengono utilizzati lo stato sessione e la memorizzazione dell'output nella cache, è possibile rimuovere i moduli relativi a tali funzionalità dall'elenco HttpModules.
Eseguire le applicazioni Web out-of-process in Internet Information Services 5.0 Per impostazione predefinita, ASP.NET in IIS 5.0 risponde alle richieste utilizzando un processo di lavoro out-of-process. Tale funzionalità è stata tarata per una elevata velocità di trasmissione. Per i vantaggi e le funzionalità derivanti dall'esecuzione di ASP.NET in un processo di lavoro out-of-process, si consiglia questa soluzione per i siti di produzione.
Riciclare i processi periodicamente Riciclare i processi periodicamente sia per motivi di stabilità che di prestazioni. A lungo andare, bug e risorse che comportano perdite di memoria possono compromettere le prestazioni del server Web ma, grazie al riciclo dei processi, è possibile liberare la memoria impiegata per questi tipi di problemi. Tuttavia, è necessario bilanciare l'esigenza di riciclo periodico con un riciclo troppo frequente, in quanto lo svantaggio di dover arrestare il processo di lavoro, ricaricare le pagine e riottenere le risorse e i dati può annullare i benefici del riciclo.

Le applicazioni Web ASP.NET in esecuzione su Windows Server 2003 e IIS 6.0 non richiedono una regolazione del modello di processo, in quanto in ASP.NET verranno utilizzate le impostazioni del modello di processo di IIS 6.0.

Impostare correttamente il numero di thread per processo di lavoro per l'applicazione L'architettura di richieste di ASP.NET tenta di raggiungere un equilibrio tra il numero di thread che eseguono richieste e le risorse disponibili. Tale architettura limita il numero di richieste in esecuzione contemporanea a quelle che la CPU può sostenere. Questa tecnica è nota come sbarramento thread. Vi sono tuttavia casi in cui l'algoritmo di sbarramento thread non è efficiente. È possibile monitorare lo sbarramento thread in Performance Monitor di Windows utilizzando il contatore delle prestazioni Istanze pipeline associato all'oggetto prestazione Applicazioni ASP.NET.

Quando una pagina Web ASP.NET chiama una risorsa esterna, ad esempio quando accede a un database o elabora richieste di servizi Web ASP.NET, la richiesta della pagina viene generalmente interrotta finché la risorsa esterna non risponde. In tal modo viene liberata la CPU per l'elaborazione di altri thread. Se un'altra richiesta è in attesa di elaborazione e un thread del pool di thread è libero, viene iniziata l'elaborazione della richiesta in attesa. Può risultarne un numero elevato di richieste in esecuzione contemporanea e di thread in attesa nel processo di lavoro ASP.NET o nel pool di applicazioni. Questa situazione può compromettere la velocità effettiva del server Web e influire negativamente sulle prestazioni.

Per ridurre questo effetto sulle prestazioni, è possibile impostare manualmente il limite per il numero di thread nel processo. A tale scopo, modificare gli attributi MaxWorkerThreads e MaxIOThreads nella sezione processModel del file Machine.config.

Nota:
I thread di lavoro vengono utilizzati per l'elaborazione delle richieste ASP.NET, mentre i thread di I/O vengono utilizzati per il trattamento dei dati di file, database o servizi Web ASP.NET.

I valori assegnati agli attributi del modello di processo rappresentano il numero massimo di ciascun tipo di thread per CPU nel processo. Per un computer con due processori, il numero massimo equivale al doppio del valore impostato. Per un computer con quattro processori, il numero massimo equivale al quadruplo del valore impostato. Le impostazioni predefinite sono adatte per i computer con uno o due processori. Tuttavia, la presenza di 100 o 200 thread nel processo per i computer con più di due processori può causare una riduzione delle prestazioni. Può infatti verificarsi un rallentamento del processo se in esso è presente un numero eccessivo di thread. Il server deve eseguire cambi di contesto aggiuntivi e, di conseguenza, il sistema operativo impiega cicli di CPU per la gestione dei thread invece che per l'elaborazione delle richieste. È possibile determinare il numero appropriato di thread mediante il test delle prestazioni dell'applicazione.

Per le applicazioni che si basano ampiamente sulle risorse esterne, attivare il Web gardening sui computer multiprocessore Il modello di processo ASP.NET consente di attivare la scalabilità sui computer multiprocessore mediante la distribuzione del lavoro in diversi processi, uno per CPU, ciascuno dei quali con l'affinità dei processori impostata su una CPU. Questa tecnica viene talvolta definita Web gardening. Le applicazioni Web possono trarre vantaggio dal Web gardening se fanno ampio uso di risorse esterne. Ad esempio, potrebbero beneficiarne se utilizzano un server database o se chiamano oggetti COM con dipendenze esterne. Tuttavia, è necessario testare le prestazioni di un'applicazione Web in un Web garden prima di attivare il Web gardening per un sito Web di produzione.

Procedure di codifica

Nelle istruzioni riportate di seguito vengono forniti suggerimenti per la scrittura di un codice efficiente.

Non basarsi sulle eccezioni presenti nel codice°°°Le eccezioni possono determinare una notevole riduzione delle prestazioni. Pertanto, evitare di utilizzarle come metodo per controllare il normale flusso di programma. Se possibile, includere nel codice la logica per rilevare e gestire le condizioni che possono provocare un'eccezione. Gli scenari comuni da rilevare nel codice comprendono il controllo della presenza di valori null, l'analisi delle stringhe in valori numerici e il controllo della presenza di specifici valori prima dell'esecuzione di operazioni matematiche. Negli esempi riportati di seguito viene illustrato codice che potrebbe causare un'eccezione e codice alternativo che consente di verificare una condizione. Gli esempi producono lo stesso risultato.
```
// This is not recommended.
try {
   result = 100 / num;
}
catch (Exception e) {
  result = 0;
}

// This is preferred.
if (num != 0)
   result = 100 / num;
else
  result = 0;
```
```
' This is not recommended.
Try
   result = 100 / num
Catch (e As Exception)
  result = 0
End Try

' This is preferred.
If Not (num = 0)
   result = 100 / num
Else
  result = 0
End If
```