Sviluppo di applicazioni ASP.NET a elevate prestazioni

  • Articolo

Nelle istruzioni riportate in questo argomento sono elencate le tecniche utilizzabili per ottimizzare la velocità effettiva 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 percorsi di andata e ritorno al server non necessari   In alcune circostanze non è necessario utilizzare controlli server ASP.NET e gestire eventi di postback. La convalida dell'input dell'utente nelle pagine Web ASP.NET, ad esempio, può essere spesso eseguita sul client prima che i dati vengano inviati al server. In generale, se non è necessario inoltrare al server informazioni da verificare o scrivere in un archivio dati, è possibile migliorare le prestazioni della pagina e le attività dell'utente evitando l'immissione di codice che causa un percorso di andata e ritorno al server. È anche possibile utilizzare i callback del client per leggere i dati dal server anziché eseguire un percorso di andata e ritorno completo. Per informazioni dettagliate, vedere Implementazione di callback client senza postback nelle pagine Web ASP.NET.

    Se si sviluppano controlli server personalizzati, fare in modo che eseguano il rendering del codice sul lato client per i browser che supportano ECMAScript (JavaScript). Se si utilizzano i controlli server in questo modo, è possibile ridurre notevolmente il numero di invii di informazioni al server Web. Per ulteriori informazioni, vedere Sviluppo di controlli server ASP.NET personalizzati.

  • Utilizzare la proprietà IsPostBack dell'oggetto Page per evitare di eseguire processi di elaborazione inutili in un percorso di andata e ritorno   Se si scrive codice che gestisce l'elaborazione postback dei controlli server, è possibile che si desideri eseguire altro codice solo la prima volta che viene richiesta una pagina anziché a ogni postback. Utilizzare la proprietà IsPostBack per eseguire il codice in modo condizionale a seconda che la pagina venga o meno generata in risposta a un evento del controllo server.

  • Salvare lo stato di visualizzazione di un controllo server solo se necessario   La gestione automatica dello stato di visualizzazione consente ai controlli server di ricompilare i valori delle proprietà in un percorso di andata e ritorno senza scrivere codice. Questa funzionalità, tuttavia, influisce sulle prestazioni poiché lo stato di visualizzazione di un controllo server viene passato al server e dal server in un campo di form nascosto. È consigliabile capire in quali situazioni lo stato di visualizzazione è utile e in quali, invece, può avere effetti negativi sulle prestazioni della pagina. Se, ad esempio, un controllo server viene associato ai dati a ogni percorso di andata e ritorno, lo stato di visualizzazione salvato non è utile, in quanto i valori del controllo vengono sostituiti con i nuovi valori durante l'associazione dei 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, impostare la proprietà EnableViewState del controllo su false, come nel seguente esempio di controllo server DataGrid:

    <asp:datagrid EnableViewState="false" datasource="..." 
   runat="server"/>

    È inoltre possibile disattivare lo stato di visualizzazione per un'intera pagina utilizzando la direttiva @ Page. Questa impostazione è utile quando non viene eseguito il postback al server da una pagina:

    <%@ Page EnableViewState="false" %>

    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 utilizzato dai controlli server nella pagina, attivare l'analisi della pagina includendo l'attributo trace="true" nella direttiva @ Page. Nell'output di analisi osservare la colonna Viewstate della tabella Gerarchia controllo. Per informazioni sull'analisi e sulla relativa attivazione, vedere Analisi di ASP.NET.

  • 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 informazioni dettagliate, 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.

  • Disattivare lo stato della sessione quando non è in uso   Non tutte le applicazioni o pagine richiedono uno stato della sessione per ciascun utente. È pertanto consigliabile disattivarlo se non è necessario. Per disattivare lo stato della sessione per una pagina, impostare l'attributo EnableSessionState nella direttiva @ Page su false, come 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 della sessione può essere disattivato anche per i metodi dei servizi Web XML. Per ulteriori informazioni, vedere Servizi Web creati mediante ASP.NET e client di servizi Web XML.

    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 dello stato sessione appropriato per le esigenze dell'applicazione   In ASP.NET è possibile archiviare i dati della sessione per l'applicazione in vari modi: stato sessione in-process, stato sessione out-of-process come servizio Windows e stato sessione out-of-process in un database SQL Server. È anche possibile creare un provider dello stato sessione personalizzato per l'archiviazione dei dati della sessione nell'archivio dati desiderato. Sebbene ognuno di essi presenti dei vantaggi, lo stato sessione in-process rappresenta di gran lunga la soluzione più rapida. Se si archiviano soltanto piccole quantità di dati volatili nello stato della sessione, è consigliabile utilizzare il provider in-process. Le opzioni dello stato sessione out-of-process sono utili se l'applicazione viene distribuita tra più processori o computer o se si desidera conservare i dati della sessione nel caso in cui un server o un processo venga riavviato. Per ulteriori informazioni, vedere Stato 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 le stored procedure per l'accesso ai dati   Tra tutti i metodi di accesso ai dati forniti da .NET Framework, l'utilizzo di SQL Server rappresenta la scelta consigliata per la generazione di applicazioni Web scalabili e a elevate prestazioni. Quando si utilizza il provider SQL Server gestito, è possibile ottenere un ulteriore miglioramento delle prestazioni utilizzando stored procedure compilate, laddove possibile, anziché comandi SQL. Per informazioni sull'utilizzo delle stored procedure di SQL Server, vedere Utilizzo di stored procedure con un comando.

  • Utilizzare la classe SqlDataReader per un cursore per ottenere un cursore fast forward-only   La classe SqlDataReader fornisce un flusso di dati forward-only recuperato da un database SQL Server. Se nell'applicazione ASP.NET è possibile utilizzare un flusso in sola lettura, la classe SqlDataReader offrirà prestazioni migliori rispetto alla classe DataSet, in quanto utilizzerà il formato di trasferimento dati su rete nativo di SQL Server per leggere i dati direttamente dalla connessione a un database. Quando ad esempio si esegue l'associazione al controllo SqlDataSource, si otterranno prestazioni migliori impostando la proprietà DataSourceMode su DataReader. L'utilizzo di un lettore dati comporta una perdita di funzionalità. La classe SqlDataReader implementa inoltre l'interfaccia IEnumerable che consente di associare i dati anche ai controlli server. Per ulteriori informazioni, vedere la classe SqlDataReader. Per informazioni sull'accesso ai dati in ASP.NET, vedere Accesso ai dati tramite ASP.NET.

  • Quando possibile, memorizzare i dati e l'output delle pagine nella cache   In ASP.NET sono disponibili meccanismi per la memorizzazione dell'output delle pagine o dei dati nella cache, quando non è necessario calcolarli in modo dinamico per ogni richiesta di pagina. Inoltre, la progettazione di richieste di pagine e dati da archiviare nella cache, in particolare nelle aree del sito in cui si prevede un traffico elevato, può ottimizzare le prestazioni di tali pagine. L'utilizzo corretto della cache può ottimizzare le prestazioni del sito più dell'utilizzo di qualsiasi altra funzionalità di .NET Framework.

    Se si utilizza la memorizzazione nella cache ASP.NET, tenere presente quanto segue. Primo, non memorizzare nella cache troppi elementi. La memorizzazione di ogni elemento nella cache presenta un costo. Gli elementi che possono essere ricalcolati facilmente o che vengono utilizzati di rado non andrebbero memorizzati nella cache. Secondo, non assegnare una scadenza breve agli elementi memorizzati nella cache. Gli elementi con validità breve causano un continuo ricambio nella cache non necessario e possono comportare un lavoro aggiuntivo per la rimozione del codice e il Garbage Collector. È possibile monitorare il ricambio nella cache dovuto a elementi in scadenza utilizzando il contatore delle prestazioni Tasso di ricambio complessivo della cache associato all'oggetto prestazioni 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   **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, in caso di modifica di un qualsiasi elemento di una tabella tutti i listener vengono invalidati. Questo può comportare una varianza non necessaria nell'applicazione. Il polling basato su tabella non è consigliabile per le tabelle sottoposte a frequenti modifiche. Ad esempio, il polling basato su tabella sarebbe consigliabile in una tabella di catalogo che viene modificata raramente. Non sarebbe consigliabile per una tabella degli ordini, che sarebbe soggetta ad aggiornamenti più frequenti. La notifica delle query è supportata da SQL Server 2005. La notifica delle query supporta query specifiche, e questo riduce il numero di notifiche inviate in caso di modifica di una tabella. Se da un lato può fornire prestazioni migliori del polling basato su tabella, dall'altro 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 o 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   **Il paging dell'interfaccia utente di controlli dati quali DetailsView e GridView può essere utilizzato con qualsiasi oggetto origine dati che supporti l'interfaccia ICollection. Per ogni operazione di paging, il controllo dati effettua la ricerca nell'intero insieme di dati dell'origine dati e seleziona la riga o le righe da visualizzare, eliminando i dati rimanenti. Se un'origine dati implementa DataSourceView e se la proprietà CanPage restituisce true, il controllo dati utilizzerà il paging dell'origine dati anziché il paging dell'interfaccia utente. In tal caso, il controllo dati cercherà solo la riga necessaria per ogni operazione di paging. Pertanto, il paging dell'origine dati è più efficiente del paging dell'interfaccia utente. Solo il controllo origine dati ObjectDataSource supporta il paging dell'origine dati. Per abilitare il paging dell'origine dati in altri controlli origine dati, è necessario ereditare dal controllo origine dati e modificare il relativo comportamento.

  • **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, il controllo DetailsView può impedire l'elaborazione di una chiamata Delete (che non è supportata implicitamente dal controllo) ed evitare che vengano eliminati dati. La convalida ha un costo a livello di prestazioni. È possibile controllare questo comportamento utilizzando 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.

    Security noteNota sulla protezione

    Si consiglia di non disabilitare la convalida degli eventi. Prima di disabilitare la convalida degli eventi, verificare che non sia possibile creare alcun postbck che avrebbe effetti indesiderati sull'applicazione.

  • **Evitare di utilizzare la crittografia dello stato di visualizzazione, a meno che non sia effettivamente necessario   **La crittografia dello stato di visualizzazione impedisce agli utenti di leggere i valori nel campo dello stato di visualizzazione nascosto. Una situazione tipica è rappresentata da un controllo GridView con un campo dell'identificatore nella proprietà DataKeyNames. Il campo dell'identificatore è necessario per coordinare gli aggiornamenti dei record. Dal momento che 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 è impostata per ogni caricamento di pagina, quindi per ogni caricamento di pagina si ha lo stesso effetto a livello di prestazioni.

  • **Utilizzare le funzionalità di memorizzazione nella cache, ordinamento e 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. Se i dati vengono memorizzati nella cache in questo modo, le operazioni di filtro e ordinamento del controllo (configurate con le proprietà FilterExpression e SortParameterName) utilizzano i dati memorizzati nella cache. In molti casi la velocità di esecuzione dell'applicazione aumenta se viene memorizzato nella cache l'intero dataset e per l'ordinamento e il filtro vengono utilizzate le proprietà FilterExpression e SortParameterName anziché query SQL con clausole "WHERE" e "SORT BY" che devono accedere al database per ogni azione di selezione.

Applicazioni Web

Nelle istruzioni riportate di seguito vengono forniti suggerimenti su come utilizzare in modo efficiente le applicazioni Web nel loro complesso.

  • Prendere in considerazione la precompilazione   Un'applicazione Web viene sottoposta alla compilazione batch la prima volta che viene richiesta 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 per la compilazione di 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 tag dell'Interfaccia utente, oppure precompilare le pagine in modo che il codice sorgente non possa essere modificato. Per ulteriori informazioni, vedere How to: Precompile ASP.NET Web SitesProcedura: precompilare siti Web ASP.NET.

  • 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 consigliabile prestare attenzione a non trasformare il riciclo periodico in 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.

    Con le applicazioni Web ASP.NET eseguite in un sistema Windows Server 2003 con IIS 6.0, non occorre effettuare la regolazione delle impostazioni del modello di processo in quanto in ASP.NET verranno utilizzate le impostazioni del modello di processo di IIS 6.0.

  • Se necessario, regolare il numero di thread a disposizione di ogni processo di lavoro dell'applicazione   L'architettura di ASP.NET per la gestione delle richieste è finalizzata a trovare un equilibrio tra il numero di thread impiegati per l'esecuzione delle richieste e le risorse disponibili. Tale architettura limita il numero di richieste in esecuzione contemporanea a una soglia che la CPU possa 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 Windows Performance Monitor utilizzando il contatore delle prestazioni Istanze pipeline associato all'oggetto prestazioni Applicazioni ASP.NET.

    Quando una pagina Web ASP.NET chiama una risorsa esterna, ad esempio quando si esegue l'accesso al database o alle richieste del servizio Web XML, la richiesta della pagina viene generalmente interrotta finché la risorsa esterna non risponde, liberando la CPU per l'elaborazione di altri thread. Se un'altra richiesta è in attesa di elaborazione e uno dei thread del pool di thread è libero, l'elaborazione della richiesta in attesa avrà inizio. Questa situazione può generare la presenza di un numero elevato di richieste in esecuzione contemporanea e di molti thread in attesa nel processo di lavoro ASP.NET o nel pool di applicazioni, con la conseguente compromissione dell'efficienza del server Web e delle prestazioni.

    Per arginare il problema, è possibile impostare manualmente il limite sul numero di thread consentiti nel processo modificando gli attributi MaxWorkerThreads e MaxIOThreads nella sezione processModel del file Machine.config.

    Nota

    I thread di lavoro sono quelli dedicati all'elaborazione delle richieste ASP.NET, mentre i thread di I/O sono imputati al trattamento dei dati di file, database o servizi Web XML.

    I valori assegnati agli attributi del modello di processo indicano il numero massimo di thread di ciascun tipo consentiti per ogni 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. I valori predefiniti sono adatti per i computer a uno o due processori, ma limitare un processo a 100 o 200 thread sui computer che dispongono di più processori può comportare più svantaggi che vantaggi per le prestazioni. La presenza di troppi thread in un processo può rallentare il server per effetto dei continui scambi di contesto, che portano il sistema operativo a impiegare più cicli di CPU per la gestione dei thread che non per l'elaborazione delle richieste. Per valutare meglio il numero adeguato di thread è possibile ricorrere alla verifica delle prestazioni dell'applicazione.

  • Per le applicazioni che si basano eccessivamente sulle risorse esterne, provare ad attivare il Web gardening sui computer a più processori   Il modello di processo ASP.NET consente di attivare la scalabilità sui computer a più processori mediante la distribuzione del lavoro su più processi, uno per ogni CPU, ciascuno dei quali con affinità dei processori impostata su una CPU. Questa tecnica è chiamata Web gardening. Se l'applicazione utilizza un server di database lento o chiama oggetti COM con dipendenze esterne, per citare solo due possibilità, l'attivazione del Web gardening per l'applicazione può risultare vantaggiosa. È tuttavia consigliabile verificare le prestazioni dell'applicazione in un Web garden prima di decidere di attivarlo per un sito Web di produzione.

  • 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 è attiva, potrebbe influire negativamente sulle prestazioni dell'applicazione. Per informazioni sulla sintassi per l'impostazione della modalità di debug, vedere Modifica dei file di configurazione ASP.NET.

  • Mettere a punto i file di configurazione per il computer del server Web e per le singole applicazioni in base alle proprie esigenze   La configurazione predefinita di ASP.NET è regolata in modo da permettere l'utilizzo del più ampio numero di funzionalità negli scenari più comuni. È possibile modificare alcune impostazioni di configurazione predefinite in modo da migliorare le prestazioni delle applicazioni, a seconda delle funzionalità in uso. Nell'elenco riportato di seguito sono indicate le impostazioni di configurazione che è possibile modificare:

    • 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 le impostazioni di codifica di richiesta e risposta appropriate per l'applicazione   La codifica predefinita di ASP.NET è UTF-8. Se l'applicazione utilizza solo caratteri ASCII, sarà possibile ottenere un minimo incremento delle prestazioni configurando l'applicazione per l'utilizzo della codifica ASCII.

    • Provare a disattivare AutoEventWireup per l'applicazione   Se si imposta l'attributo AutoEventWireup su false nel file Machine.config, la pagina non assocerà gli eventi di pagina a un metodo in base a una corrispondenza tra i nomi, ad esempio Page_Load. Se si disattiva AutoEventWireup, si otterrà un lieve incremento delle prestazioni delle pagine e si lascerà allo sviluppatore l'onere del collegamento degli eventi che solitamente è automatico.

      Se si desidera gestire gli eventi di pagina, utilizzare una delle seguenti strategie. La prima strategia consiste nell'eseguire l'override della classe base. È possibile, ad esempio, eseguire l'override del metodo OnLoad dell'oggetto Page per l'evento di caricamento della pagina anziché utilizzare un metodo Page_Load. (Accertarsi di chiamare il metodo base, in modo che vengano generati tutti gli eventi.) La seconda strategia consiste nell'eseguire l'associazione agli eventi utilizzando la parola chiave Handles in Visual Basic o delegare il wireup in C#.

    • Rimuovere i moduli inutilizzati dalla pipeline di elaborazione delle richieste   Per impostazione predefinita, tutte le funzionalità del nodo HttpModules del file Machine.config del computer server restano attive. 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. Se, ad esempio, l'applicazione non utilizza lo stato della sessione e la memorizzazione nella cache di output, sarà possibile rimuoverne i moduli dall'elenco HttpModules in modo che a ogni richiesta non si debba richiamare tali moduli senza alcuna elaborazione ulteriore.

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   Poiché le eccezioni possono generare una notevole riduzione delle prestazioni, è consigliabile non utilizzarle per controllare il normale flusso dei programmi. Se è possibile rilevare nel codice una condizione che potrebbe causare un'eccezione, è consigliabile farlo piuttosto che rilevare l'eccezione e gestirne la condizione. Tra gli scenari più comuni da rilevare nel codice sono inclusi il controllo della presenza di valori null, l'assegnazione di un valore a una String che verrà analizzata in un valore numerico o il controllo della presenza di valori specifici prima dell'esecuzione di operazioni matematiche. Di seguito è riportato un esempio di codice che potrebbe causare un'eccezione e un esempio di codice che consente di verificare una condizione. Entrambi 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

  • Riscrivere i componenti COM a elevato numero di chiamate in codice gestito   .NET Framework consente di interagire con i componenti COM tradizionali in modo semplice. Il vantaggio consiste nella possibilità di usufruire delle funzionalità di .NET conservando al tempo stesso gli investimenti esistenti relativi ai componenti COM. In alcune circostanze, tuttavia, il costo che la conservazione dei vecchi componenti comporta in termini di prestazioni è superiore a quello della migrazione al codice gestito. Ogni situazione è univoca e il modo migliore per decidere se la migrazione di un componente sia necessaria consiste nel misurare le prestazioni del sito Web. È consigliabile esaminare la possibilità di eseguire il porting in codice gestito di ogni componente COM che viene chiamato spesso.

    In molti casi non è possibile eseguire la migrazione di componenti esistenti verso il codice gestito, specie nella fase iniziale della migrazione di un'applicazione Web. In tali circostanze, uno dei fattori maggiormente lesivi delle prestazioni è il marshalling dei dati dall'ambiente non gestito a quello gestito. Nei casi di interoperatività occorre pertanto svolgere quante più attività è possibile sull'uno e l'altro fronte per effettuare poi un'unica chiamata, anziché una serie di piccole chiamate. Tutte le stringhe in Common Language Runtime sono in formato Unicode, sicché, ad esempio, prima di effettuare una chiamata al codice gestito occorrerebbe convertire le stringhe del componente in Unicode.

    Rilasciare gli oggetti COM o le risorse native non appena ne sarà terminata l'elaborazione. In tal modo si consente ad altre richieste di farne uso e si riducono al minimo gli impatti sulle prestazioni derivanti da un intervento del Garbage Collector altrimenti necessario successivamente.

  • Evitare l'uso di componenti COM apartment a thread singolo (STA, Single-Threaded Apartment)   Per impostazione predefinita, in ASP.NET non è possibile eseguire i componenti COM STA in una pagina. Per eseguirli, è necessario includere l'attributo ASPCompat=true nella direttiva @ Page del file aspx. In tal modo il pool di thread utilizzato per l'esecuzione della pagina verrà commutato in un pool di thread STA, mentre HttpContext e gli altri oggetti incorporati diverranno disponibili per l'oggetto COM. Se i componenti COM STA non vengono utilizzati si ottiene anche un'ottimizzazione delle prestazioni, in quanto si evita il marshalling delle chiamate da apartment con multithreading (MTA, Multithreaded Apartment) a thread STA.

    Se occorre utilizzare un componente COM STA, evitare di effettuare numerose chiamate durante un'esecuzione e tentare di inviare il maggior numero possibile di informazioni in poche chiamate. Evitare inoltre di creare componenti COM STA durante la costruzione della pagina. Nel codice che segue viene ad esempio creata un'istanza di SampleSTAComponent in fase di creazione della pagina che viene generata da un thread che non è il thread STA con cui viene eseguita la pagina. Ne potrebbe conseguire una riduzione delle prestazioni, poiché per creare la pagina sarà necessario ricorrere al marshalling tra thread MTA e STA.

    <%@ Page Language="VB" ASPCompat="true" %>
<script runat=server>
Dim myComp as new SampleSTAComponent()
Public Sub Page_Load()
    myComp.Name = "Sample"
End Sub
</script>
<html>
<%
    Response.Write(Server.HtmlEncode(myComp.SayHello))
%>
</html>

    La soluzione migliore consiste nel rinviare la creazione dell'oggetto finché il codice non verrà eseguito in un thread STA, come mostrato nell'esempio che segue.

    <%@ Page Language="VB" ASPCompat="true" %>
<script runat=server>
Dim myComp
Public Sub Page_Load()
    myComp = new SampleSTAComponent()
    myComp.Name = "Sample"
End Sub
</script>
<html>
<%
    Response.Write(Server.HtmlEncode(myComp.SayHello))
%>
</html>

    Si consiglia di costruire i componenti COM e le risorse esterne solo quando necessario o nel metodo Page_Load.

    Non memorizzare mai i componenti COM STA in una risorsa condivisa, come la cache o lo stato sessione, nella quale sono accessibili da thread diversi da quello utilizzato per la relativa costruzione. Anche se un thread STA effettua una chiamata a un componente COM STA, solo il thread con cui il componente COM STA è stato costruito può rispondere alla chiamata, con la conseguenza di imporre il marshalling della chiamata al thread con cui è avvenuta la costruzione. L'effetto negativo di tale marshalling può rivelarsi in termini di prestazioni e di scalabilità. In questi casi, provare a convertire il componente COM in un componente COM MTA o a riscriverlo in codice gestito.

Vedere anche

Concetti

Ottimizzazione delle prestazioni in ASP.NET
Monitoraggio delle prestazioni delle applicazioni ASP.NET
Contatori delle prestazioni di ASP.NET

Altre risorse

Memorizzazione nella cache ASP.NET