Considerazioni sulle prestazioni per le applicazioni che utilizzano servizi
Aggiornamento: novembre 2007
In questo argomento vengono descritte le tecniche per ottimizzare le prestazioni quando si utilizzano le funzionalità di ASP.NET per l'appartenenza, i ruoli, le proprietà dei profili, lo stato della sessione, la personalizzazione di Web part e l'esplorazione di siti.
Appartenenza
In questa sezione sono disponibili informazioni su come utilizzare l'appartenenza di ASP.NET in modo efficiente.
Raccogliere elenchi di appartenenza in modo efficiente
Quando si chiamano i metodi della classe Membership, chiamare i metodi di overload che accettano membri PageIndex e PageSize. Questi overload vengono eseguiti più rapidamente, perché comportano il trasferimento dal server Web di un numero inferiore di dati. Un esempio è rappresentato dal metodo GetAllUsers della classe Membership. Se si chiama il metodo GetAllUsers senza parametri, vengono restituiti tutti gli utenti dell'appartenenza. Al contrario, se si chiama l'overload GetAllUsers viene restituita una sola pagina di utenti, e questo riduce la quantità dei dati elaborati dalla pagina.
Memorizzare nella cache i risultati quando si ottiene il numero di utenti in linea
È possibile chiamare il metodo GetNumberOfUsersOnline per visualizzare il numero di utenti considerati attivi nel sito Web. Questo metodo esamina ogni riga della tabella dell'appartenenza ogni volta che il metodo viene chiamato e questo può essere molto gravoso per quanto riguarda le prestazioni se il numero di utenti nel database è notevole. Chiamare il metodo solo quando effettivamente necessario e memorizzare il valore nella cache per un certo periodo di tempo se non è necessario un conteggio preciso.
Ruoli
Per impostazione predefinita, il metodo GetRolesForUser viene chiamato automaticamente ogni volta che viene caricata una pagina e restituisce i ruoli rivestiti da un utente. I ruoli sono memorizzati in un dizionario nell'oggetto RolePrincipal. Mentre la pagina Web è in esecuzione, viene effettuato il controllo dei ruoli mediante questo dizionario. Per evitare l'accesso al provider per ogni pagina caricata e quindi ridurre il tempo di elaborazione del server, impostare l'attributo CacheRolesInCookie nel file Web.config dell'applicazione su true. L'elenco dei ruoli dell'utente verrà archiviato in un cookie. Nei successivi caricamenti della pagina, sarà possibile leggere le informazioni sui ruoli dal cookie anziché utilizzare una chiamata al provider.
È possibile utilizzare il metodo GetRolesForUser, la proprietà IsInRole e il metodo GetRoles nel codice per verificare l'appartenenza in un ruolo. Dopo aver compreso in che modo questi metodi interagiscono, sarà possibile scrivere codice per l'applicazione che garantisca la massima efficienza per le attività che si desidera svolgere.
Il metodo GetRolesForUser accede sempre al provider. Una chiamata al metodo IsInRole comporta sempre una chiamata al metodo GetRolesForUser alla prima richiesta di una pagina se non è abilitata la memorizzazione nella cache dei cookie. Se la memorizzazione nella cache dei cookie è abilitata, le chiamate al metodo IsInRole utilizzeranno le informazioni sui ruoli memorizzate nel cookie. La prima chiamata al metodo GetRoles comporta una chiamata al metodo GetRolesForUser, indipendentemente dal fatto che sia attivata o meno la memorizzazione nella cache dei cookie. Le successive chiamate al metodo GetRoles in una pagina utilizzeranno le informazioni sui ruoli memorizzate nell'oggetto RolePrincipal.
.gif "Nota") Nota: |
|---|
L'archiviazione di informazioni riservate in un cookie può esporre tali informazioni agli utenti. Se è necessaria la massima sicurezza, evitare di abilitare la memorizzazione nella cache dei cookie. |
Proprietà del profilo
Se il codice accede a proprietà del profilo, quando la pagina viene caricata il provider dei profili legge tutte le proprietà del profilo dell'utente corrente. (In specifico il provider legge tutte le proprietà associate a tale provider di profili.) Se uno o più valori delle proprietà del profilo sono cambiati, le nuove informazioni vengono scritte nell'archivio dati del provider quando la pagina viene scaricata. ASP.NET può determinare se sono stati modificati tipi intrinseci quali valori integer e stringhe, ma non può determinare se sono stati modificati tipi non intrinseci.
L'algoritmo per determinare se le proprietà del profilo vengono salvate è il seguente:
Se tutti i tipi di proprietà del profilo sono tipi intrinseci e nessuno è cambiato, il profilo non viene scritto nell'archivio dati.
Se tutti i tipi di proprietà del profilo sono tipi intrinseci e qualcuno è cambiato, tutti i valori delle proprietà del profilo vengono scritti nell'archivio dati.
Se una proprietà non è di tipo intrinseco, ASP.NET non è in grado di determinare se un valore è cambiato. Se alla proprietà si accede nel codice, il valore della proprietà viene scritto nell'archivio dati.
Nota:In tutti i casi la decisione vale per tutte le proprietà di profilo per un provider specifico.
Se si utilizzano tipi di proprietà non intrinseci, la scrittura dei dati del profilo alla fine di ogni richiesta di pagina richiede del tempo. È possibile ovviare a questo sovraccarico nei seguenti modi:
Utilizzare solo tipi intrinseci nei profili.
Impostare l'attributo automaticSaveEnabled nell'elemento di configurazione <profile> su Off e scrivere codice personalizzato per rilevare le modifiche e salvare i valori delle proprietà quando necessario.
Scrivere codice personalizzato per gestire l'evento ProfileAutoSaving e nel codice dell'evento determinare se le proprietà del profilo sono cambiate. Se nessuna proprietà è cambiata, annullare l'operazione di salvataggio automatico e impostare la proprietà ContinueWithProfileAutoSave dell'evento su false.
Stato della sessione
Quando si utilizza la modalità dello stato della sessione out-of-process (per ulteriori informazioni, vedere Modalità stato sessione) è importante valutare le prestazioni. In questa sezione sono disponibili informazioni sull'ottimizzazione delle prestazioni dello stato della sessione.
Riduzione del sovraccarico delle letture e scritture dello stato della sessione
Per impostazione predefinita, le informazioni sullo stato della sessione vengono caricate durante ogni caricamento di pagina. L'attributo EnableSessionState della direttiva @ Page consente di controllare il caricamento dello stato della sessione con le seguenti impostazioni:
True Lo stato della sessione viene letto in ogni caricamento di pagina e se è cambiato viene salvato. ASP.NET può determinare se tipi intrinseci quali valori integer e stringhe sono cambiati. Se tutti i valori dello stato della sessione sono tipi intrinseci e nessuno è cambiato, la sessione non viene salvata. Se alcuni dei valori non sono di tipo intrinseco e si accede a valori della sessione non intrinseci, vengono salvate tutte le informazioni sullo stato della sessione. Questo perché ASP.NET non registra se i tipi non intrinseci sono cambiati e opta per la soluzione più sicura salvando tutti i dati.
False I dati dello stato della sessione non vengono letti quando la pagina viene caricata.
ReadOnly I dati dello stato della sessione vengono letti in ogni caricamento di pagina ma non vengono mai salvati, anche se viene apportata una modifica nel codice ai valori dello stato della sessione.
Evitare conflitti a livello di blocchi per lo stato della sessione
Evitare di utilizzare elementi <IFRAME> nelle pagine che richiedono lo stato della sessione. Se vengono effettuate più richieste ad ASP.NET con lo stesso identificatore dello stato della sessione e se le richieste riguardano tutte le pagine ASP.NET in cui EnableSessionState è impostato su true, le richieste parallele saranno in conflitto per il blocco associato allo stato della sessione out-of-process. Nel caso di elementi <IFRAME>, questo significa che le pagine ASP.NET visualizzate in più elementi <IFRAME> di una pagina possono competere per gli stessi dati della sessione. Il risultato è che ogni richiesta distinta verrà serializzata nel server.
Personalizzazione di Web part
Quando una pagina viene eseguita, vengono caricate le informazioni di personalizzazione di ASP.NET. Per determinare se le informazioni sulla personalizzazione delle Web Part sono cambiate, ASP.NET chiama il metodo Equals per confrontare i vecchi e i nuovi valori delle proprietà contrassegnate con l'attributo PersonalizableAttribute.
Se uno o più valori delle proprietà di personalizzazione sono cambiati, i dati di personalizzazione vengono salvati. Per tipi intrinseci quali i valori integer, il metodo Equals confronta direttamente i valori vecchi e nuovi delle proprietà. Tuttavia, per i tipi non intrinseci ASP.NET confronta il valore del riferimento, ma non necessariamente i dati gestiti da un'istanza del tipo.
Ad esempio, per una proprietà di tipo ArrayList, il metodo Equals confronta i valori vecchi e nuovi del riferimento ArrayList, ma non il contenuto dell'oggetto ArrayList. Il metodo Equals restituisce true se il riferimento a ArrayList non è cambiato, anche se all'elenco è stato aggiunto un nuovo elemento. In tal caso i dati di ArrayList non verrebbero salvati.
Questo algoritmo per i tipi non intrinseci è efficiente, ma è carente per quanto riguarda il fatto che i dati non vengono salvati. Se si desidera salvare i dati di un tipo non intrinseco, come un oggetto ArrayList, impostare la proprietà IsDirty su true se il controllo deriva da WebPart oppure chiamare il metodo SetPersonalizationDirty che accetta un controllo come parametro.
Spostamenti all'interno del sito
Le mappe di sito di grandi dimensioni rallentano le prestazioni. Ad esempio, negli scenari di testing l'aumento del numero di nodi da 100 a 1000 (un aumento di dieci volte) può comportare un aumento del tempo di caricamento delle pagine di circa un terzo.
La funzionalità di rimozione della sicurezza, che filtra i nodi in base ai ruoli, ha un impatto sulle prestazioni maggiore dell'aumento del numero di nodi. Ad esempio, una mappa di sito con 1000 nodi presenta un sovraccarico di elaborazione di 10 volte maggiore rispetto a una mappa di sito con 100 nodi.
Alcuni consigli validi per ridurre questo effetto sono:
Se la funzionalità di rimozione della sicurezza è attivata, il numero massimo di nodi consigliato è 150.
Impostare l'attributo Roles in ogni nodo della mappa del sito. Quando esiste questo attributo, ASP.NET può ignorare l'autorizzazione di URL e file per l'URL associato all'oggetto SiteMapNode, purché un utente appartenga a uno dei ruoli indicati nell'attributo. Si noti, tuttavia, che se un utente non appartiene a uno dei ruoli specificati, ASP.NET eseguirà il fallback ai controlli di autorizzazione di file e URL più lenti.
Creare una classe che eredita dalla classe SiteMapProvider ed esegue l'override del metodo IsAccessibleToUser per controllare solo l'attributo Roles di ogni nodo della mappa del sito. Questo velocizza il processo di filtraggio, perché ignora l'autorizzazione di URL e file. Questo approccio, tuttavia, richiede due definizioni di sicurezza parallele nell'applicazione Web. La prima riguarda le informazioni di autorizzazione nel file Web.config (e gli elenchi di controllo di accesso NTFS per l'autorizzazione file se è abilitata l'autenticazione di Windows). La seconda riguarda le informazioni sui ruoli nella mappa del sito. È opportuno valutare il sovraccarico di lavoro per la gestione della sicurezza determinato dalla divisione delle informazioni a fronte del miglioramento delle prestazioni.
Per ulteriori informazioni, vedere Rimozione della protezione della mappa del sito ASP.NET e Autorizzazione ASP.NET.
Vedere anche
Concetti
Protezione del sistema di spostamento all'interno dei siti ASP.NET