Condividi tramite


ASP.NET monitoraggio delle prestazioni e quando inviare avvisi agli amministratori

 

Thomas Marquardt
Microsoft Corporation

Aggiornamento di luglio 2003

Si applica a:
   Microsoft® ASP.NET

Riepilogo: Vengono illustrati i contatori delle prestazioni più utili per diagnosticare i problemi di stress e prestazioni nelle applicazioni di Microsoft ASP.NET, quali soglie devono essere impostate per avvisare gli amministratori dei problemi e altre risorse che possono essere usate per monitorare l'integrità di un'applicazione ASP.NET. (17 pagine stampate)

Scaricare il codice sorgente per questo articolo.

Contents

Contatori delle prestazioni di monitoraggio
Monitoraggio del log eventi
Monitoraggio dei log W3C e HTTPERR
Altre risorse usate per monitorare ASP.NET
Informazioni sui contatori delle prestazioni
   Contatore delle eccezioni CLR .NET
   Contatori di caricamento CLR .NET
   Contatori di memoria CLR .NET
   contatori ASP.NET
   Contatori delle applicazioni ASP.NET
   Contatori dei processi
   Contatore del processore
   Contatore memoria
   Contatore di sistema
   Contatori dei servizi Web
Conclusione

Contatori delle prestazioni di monitoraggio

Sono disponibili molti contatori delle prestazioni per il monitoraggio delle applicazioni. La scelta di quelle da includere nei log delle prestazioni può essere difficile e imparare a interpretarle è un'arte. Questo articolo dovrebbe essere utile per sentirsi più a proprio agio con entrambe queste attività.

Come minimo, i contatori delle prestazioni seguenti devono essere monitorati per le applicazioni Microsoft® ASP.NET:

  • Processore(_Totale)\% di tempo del processore
  • Process(aspnet_wp)\% Processor Time
  • Process(aspnet_wp)\Private Bytes
  • Process(aspnet_wp)\Virtual Bytes
  • Process(aspnet_wp)\Handle Count
  • Eccezioni CLR microsoft® .NET\# Exceps generate/sec
  • ASP.NET\Riavvii dell'applicazione
  • ASP.NET\Richieste rifiutate
  • ASP.NET\Riavvio del processo di lavoro (non applicabile a IIS 6.0)
  • Memoria\Byte disponibili
  • Servizio Web\Connessioni correnti
  • Servizio Web\Richieste di estensione ISAPI/sec

Di seguito è riportato un elenco più ampio dei contatori delle prestazioni utili per il monitoraggio delle prestazioni. È sempre consigliabile avere più dati sulle prestazioni che non sufficienti, soprattutto quando si verifica un problema che non è facilmente riprodotto. L'elenco omette diversi contatori delle prestazioni che in genere non sono necessari. Ad esempio, lo stato della sessione e i contatori delle prestazioni delle transazioni sono necessari solo quando vengono usate le funzionalità.

Alcune soglie sono consigliate in base all'esperienza con il debug e il test delle applicazioni ASP.NET. È possibile cercare "Soglia" in questo articolo per passare direttamente a loro. Gli amministratori devono determinare se generare avvisi quando queste soglie vengono superate in base all'esperienza. Nella maggior parte dei casi, gli avvisi sono appropriati, soprattutto se la soglia viene superata per periodi di tempo prolungati.

Monitoraggio del log eventi

È fondamentale monitorare il registro eventi per i messaggi provenienti da ASP.NET e Microsoft® Internet Information Server (IIS). ASP.NET scrive messaggi nel registro applicazioni, ad esempio ogni volta che il processo di lavoro aspnet_wp termina. IIS 6.0 scrive i messaggi sia nell'applicazione che nei log di sistema, ad esempio ogni volta che il processo di lavoro w3wp segnala se stesso non integro o si arresta in modo anomalo. È abbastanza facile scrivere un'applicazione .NET che legge il log applicazioni e filtra i messaggi da ASP.NET e IIS e genera un avviso (invia un messaggio di posta elettronica o compone un cercapersone) se necessario.

Monitoraggio dei log W3C e HTTPERR

Abilitare innanzitutto la registrazione W3C per IIS 5.0 e IIS 6.0 tramite Gestione Internet Information Services (IIS). Questo log può essere configurato per includere vari dati sulle richieste, ad esempio l'URI, il codice di stato e così via. Analizzare il log per individuare i codici di errore, ad esempio 404 Non trovato, ed eseguire un'azione per correggere i collegamenti, se necessario. In IIS 6.0 il codice di stato secondario è incluso nel log ed è utile per il debug. IIS usa i codici di stato secondario per indentificare problemi specifici. Ad esempio, 404.2 indica che l'estensione ISAPI che gestisce la richiesta è bloccata. Un elenco di codici di stato e di stato secondario è disponibile nell'argomento Informazioni sui messaggi di errore personalizzati .

Novità di IIS 6.0, richieste non valide o non valide e richieste che non riescono a essere gestite da un pool di applicazioni vengono registrate nel log HTTPERR da HTTP.SYS, il driver in modalità kernel per la gestione delle richieste HTTP. Ogni voce include l'URL e una breve descrizione dell'errore.

Controllare il log HTTPERR per le richieste rifiutate. Le richieste vengono rifiutate da HTTP.SYS quando viene superata la coda delle richieste del kernel e quando l'applicazione viene portata offline dalla funzionalità Protezione rapida non riuscita. Quando si verifica il primo problema, l'URL viene registrato con il messaggio QueueFull e quando il secondo si verifica, il messaggio è AppOffline. Per impostazione predefinita, la coda di richieste del kernel è impostata su 1.000 e può essere configurata nella pagina Proprietà pool di applicazioni in Gestione IIS. È consigliabile aumentare questo valore a 5.000 per un sito occupato, poiché la coda delle richieste del kernel potrebbe facilmente superare 1.000 se un pool di applicazioni si arresta in modo anomalo mentre un sito è sottoposto a un carico molto elevato.

Controllare il log HTTPERR per le richieste perse a causa di un arresto anomalo o blocco del processo di lavoro. Quando questo si verifica, l'URL verrà registrato con il messaggio , Connection_Abandoned_By_AppPool, per ogni richiesta in anteprima. Una richiesta in anteprima è una richiesta inviata a un processo di lavoro per l'elaborazione, ma non completata prima dell'arresto anomalo o del blocco.

I dettagli sul log HTTPERR sono disponibili nell'articolo della Microsoft Knowledge Base 820729: INFO: Registrazione degli errori nell'API HTTP.

Altre risorse usate per monitorare ASP.NET

I contatori delle prestazioni e i registri eventi non rilevano tutti gli errori che si verificano e pertanto non sono completamente sufficienti per il monitoraggio ASP.NET. È consigliabile scrivere una semplice applicazione che invia una richiesta HTTP per una o più pagine e prevede una determinata risposta. Questo strumento deve monitorare l'ora dell'ultimo byte (TTLB) per garantire che le pagine vengano gestite in modo tempestivo. Deve anche registrare eventuali errori che si verificano, in quanto queste informazioni saranno necessarie per analizzare il problema.

IIS 6.0 Resource Kit include Log Parser 2.1, uno strumento per l'analisi dei file di log (W3C Log, log HTTPERR, log eventi) e l'archiviazione dei risultati in un file o in un database. Il kit di risorse può essere installato in Microsoft® Windows® XP e Microsoft® Windows Server™ 2003.

È anche possibile scrivere un'applicazione che raccoglie dati sulle prestazioni, filtra il registro eventi e registra i dati chiave in un database di Microsoft® SQL Server. È incredibilmente facile eseguire questa operazione usando lo spazio dei nomi System.Diagnostics . È anche possibile monitorare i riavvii del processo di lavoro usando la classe System.Diagnostics.Process .

Per iniziare, usare il collegamento nella parte superiore di questo articolo per scaricare il codice di esempio per diversi strumenti utili:

  1. Codice sorgente per snap.exe, uno strumento da riga di comando per la registrazione dei dati sulle prestazioni per i processi. Il file Snap.cs contiene una breve descrizione e spiega come compilare lo strumento.
  2. Codice sorgente per HttpClient.exe, un semplice client che registra l'ora dell'ultimo byte (TTLB) per le richieste HTTP. Il file HttpClient.cs contiene una breve descrizione e spiega come compilare lo strumento.
  3. Codice sorgente per qqq.exe, uno strumento da riga di comando per il test dello stress di un'applicazione ASP.NET. Se usato in combinazione con un client di stress, ad esempio Microsoft® Application Center Test (ACT), questo strumento collega i debugger al processo di lavoro e monitora determinati contatori delle prestazioni. Può essere ottimizzato per suddividere i debugger in caso di riduzione delle prestazioni. Il file qqq.cs contiene una descrizione breif e spiega come compilare lo strumento.
  4. La pagina pminfo.aspx usa la classe System.Web.ProcessModelInfo per visualizzare informazioni sui riavvii del processo di aspnet_wp. La cronologia viene mantenuta fino all'arresto del servizio w3svc.
  5. Codice sorgente per ErrorHandler.dll. Si tratta di un IHttpModule che è possibile aggiungere alla pipeline HTTP per registrare eccezioni non gestite nel registro eventi. È preferibile registrare gli errori in un database SQL Server, ma l'esempio usa il registro eventi per semplicità.

Un altro passaggio semplice consiste nell'implementare Application_Error. È possibile aggiungere il testo seguente a global.asax e avviare immediatamente la registrazione degli errori non gestiti nel log dell'applicazione:

<%@ import namespace="System.Diagnostics" %>
<%@ import namespace="System.Text" %>

const string sourceName      = ".NET Runtime";
const string serverName      = ".";
const string logName         = "Application";
const string uriFormat       = "\r\n\r\nURI: {0}\r\n\r\n";
const string exceptionFormat = "{0}: \"{1}\"\r\n{2}\r\n\r\n";

void Application_Error(Object sender, EventArgs ea) {
    StringBuilder message = new StringBuilder();
    
    if (Request != null) {
        message.AppendFormat(uriFormat, Request.Path);
    }
  
    if (Server != null) {
        Exception e;
        for (e = Server.GetLastError(); e != null; e = e.InnerException) {
            message.AppendFormat(exceptionFormat, 
                                 e.GetType().Name, 
                                 e.Message,
                                 e.StackTrace);
        }
    }

    if (!EventLog.SourceExists(sourceName)) {
        EventLog.CreateEventSource(sourceName, logName);
    }

    EventLog Log = new EventLog(logName, serverName, sourceName);
    Log.WriteEntry(message.ToString(), EventLogEntryType.Error);

    //Server.ClearError(); // uncomment this to cancel the error
}

Application_Error intercettare gli errori di parser, compilazione e runtime all'interno di pagine. Non rileva i problemi di configurazione, né rileva errori che si verificano all'interno di inetinfo mentre aspnet_isapi elabora la richiesta. Inoltre, quando si usa la rappresentazione, il token rappresentato deve avere l'autorizzazione per scrivere in questa origine evento. È possibile evitare il problema con la rappresentazione registrando errori in un database SQL Server.

Infine, gli strumenti di debug Microsoft® per Windows sono molto utili per il debug di problemi in un server Web di produzione. Questi strumenti possono essere scaricati da https://www.microsoft.com/whdc/ddk/debugging/installx86.mspx. È disponibile un'estensione del debugger denominata sos.dll che è possibile caricare nel debugger windbg.exe o cdb.exe per eseguire il debug del codice gestito. Può eseguire il dump del contenuto dell'heap di Garbage Collection (GC), mostrare le tracce dello stack gestito, aiutare l'analisi della contesa per i blocchi gestiti, visualizzare le statistiche del pool di thread e molto altro ancora. Questa operazione può essere scaricata come parte del set di strumenti di debug menzionato in Debug di produzione per applicazioni .NET Framework.

Informazioni sui contatori delle prestazioni

Di seguito è riportata una breve descrizione dei contatori delle prestazioni importanti e come usarli.

Contatore eccezioni CLR .NET

L'istanza del contatore _Global_ non deve essere usata con questo contatore, perché viene aggiornata da tutti i processi gestiti. Usare invece l'istanza di aspnet_wp.

  • #Exceps generata/sec. Numero totale di eccezioni gestite generate al secondo. Man mano che questo numero aumenta, le prestazioni sono ridotte. Le eccezioni non devono essere generate come parte della normale elaborazione. Si noti, tuttavia, che Response.Redirect, Server.Transfer e Response.End causano che un threadAbortException venga generato più volte e un sito che si basa fortemente su questi metodi comporterà una penalità delle prestazioni. Se è necessario usare Response.Redirect, chiamare Response.Redirect(url, false), che non chiama Response.End e quindi non genera. Il lato negativo è che il codice utente che segue la chiamata a Response.Redirect(URL, false) verrà eseguito. È anche possibile usare una pagina HTML statica per reindirizzare. L'articolo di Microsoft Knowledge Base 312629 fornisce ulteriori dettagli.

    Oltre al monitoraggio di questo contatore delle prestazioni molto utile, l'evento Application_Error deve essere usato per avvisare gli amministratori dei problemi.

    Soglia: 5% di RPS. I valori maggiori di questo valore devono essere esaminati e una nuova soglia deve essere impostata in base alle esigenze.

Contatori di caricamento CLR .NET

L'istanza del contatore _Global_ non deve essere usata con questi contatori delle prestazioni, perché viene aggiornata da tutti i processi gestiti. Usare invece l'istanza di aspnet_wp.

  • AppDomains corrente. Numero corrente di AppDomains caricati nel processo. Il valore di questo contatore deve essere uguale al numero di applicazioni Web più 1. AppDomain aggiuntivo è il dominio predefinito.

  • Assembly correnti. Numero corrente di assembly caricati nel processo. Per impostazione predefinita, i file ASPX e ASCX in una directory sono compilati in "batch". Questo restituisce in genere uno a tre assembly, a seconda delle dipendenze. Ad esempio, se sono presenti pagine ASPX con dipendenze in fase di analisi sui file ASCX, in genere verranno generati due assembly. Uno conterrà i file ASPX, gli altri file ASCX. Le dipendenze in fase di analisi includono quelle create dalle <direttive %@ import %, <%@ reference> %>, e <%@ register %> . Un controllo caricato tramite il metodo LoadControl non crea una dipendenza in fase di analisi. Si noti che global.asax viene compilato in un assembly stesso.

    Occasionalmente, il consumo eccessivo di memoria è causato da un numero insolitamente elevato di assembly caricati. Ad esempio, un sito che visualizza articoli di notizie eseguirà meglio usando un piccolo set di file ASPX che ottengono le notizie da un database rispetto a quello che sarebbe stato un singolo file ASPX usato per ogni articolo. Le finestre di progettazione siti devono tentare di generare contenuto in modo dinamico, usare la memorizzazione nella cache e ridurre il numero di pagine ASPX e ASCX.

    Gli assembly non possono essere scaricati da un AppDomain. Per evitare un consumo eccessivo di memoria, AppDomain viene scaricato quando il numero di ricompilazione (ASPX, ASCX, ASAX) supera il limite specificato dalla <compilazione numRecompilesBeforeAppRestart=/>. Si noti che se l'attributo %@ page debug=%> è impostato su true o se <il debug di compilazione=/> è impostato su true, la <compilazione batch è disabilitata.

  • Byte nell'heap del caricatore. Numero di byte eseguito dal caricatore della classe in tutti i Domini app. Questo contatore dovrebbe raggiungere uno stato costante. Se questo contatore aumenta continuamente, monitorare il contatore "Assembly correnti". Potrebbero essere caricati troppi assembly per AppDomain.

Contatori di memoria CLR .NET

L'istanza del contatore _Global_ non deve essere usata con questi contatori delle prestazioni, perché viene aggiornata da tutti i processi gestiti. Usare invece l'istanza di aspnet_wp.

  • # Byte in tutti gli heaps. Numero di byte sottoposti a commit da oggetti gestiti. Si tratta della somma dell'heap di grandi oggetti e della generazione 0, 1 e 2 heaps. Queste aree di memoria sono di tipo MEM_COMMIT (vedere la documentazione di Platform SDK per VirtualAlloc). Il valore di questo contatore sarà sempre minore del valore di Process\Private Bytes, che conta tutte le aree MEM_COMMIT per il processo. Byte privati meno # byte in tutti gli heaps è il numero di byte commit da oggetti non gestiti. Il primo passaggio dell'analisi dell'utilizzo eccessivo della memoria consiste nel determinare se viene usato da oggetti gestiti o non gestiti.

    Per analizzare l'utilizzo eccessivo della memoria gestita, è consigliabile WINDBG.EXE e SOS.DLL, che è possibile leggere in Debug di produzione per applicazioni .NET Framework. SOS.DLL ha un comando "!dumpheap –stat" che elenca il conteggio, le dimensioni e il tipo di oggetti nell'heap gestito. È possibile usare "!dumpheap –mt" per ottenere l'indirizzo di un oggetto e "!gcroot" per visualizzarne le radici. Il comando "!eeheap" presenta statistiche di utilizzo della memoria per gli heaps gestiti.

    Un altro strumento utile per diagnosticare l'utilizzo della memoria è CLR Profiler, illustrato in dettaglio di seguito.

    Un utilizzo eccessivo della memoria gestita in genere è causato dalle seguenti condizioni:

    1. Lettura nella memoria di dataset di grandi dimensioni.
    2. Creazione di un numero eccessivo di voci della cache.
    3. Upload o download di file di grandi dimensioni.
    4. Utilizzo eccessivo di espressioni o stringhe regolari durante l'analisi di file.
    5. Visualizzazione eccessiva.
    6. Quantità eccessiva di dati nello stato sessione o numero eccessivo di sessioni.
  • Raccolte # Gen 0. Il numero di volte in cui sono stati raccolti oggetti di generazione 0. Gli oggetti che sopravvivono vengono promossi alla generazione 1. Una raccolta viene eseguita quando è necessario allocare un oggetto o quando un utente forza una raccolta chiamando System.GC.Collect. Le raccolte che coinvolgono generazioni più elevate richiedono più tempo, poiché sono precedute da raccolte di generazioni inferiori. Tentare di ridurre al minimo la percentuale di raccolte di seconda generazione. Come regola generale, il numero di raccolte di generazione 0 deve essere 10 volte maggiore del numero di raccolte di generazione 1 e analogamente per la generazione 1 e 2. I contatori delle raccolte #Gen N e il tempo % nel contatore GC sono i migliori per identificare i problemi di prestazioni causati da allocazioni eccessive. Per migliorare le prestazioni, vedere la descrizione per % Tempo in GC.

  • Raccolte # Gen 1. Il numero di volte in cui sono stati raccolti oggetti di generazione 1. Gli oggetti che sopravvivono vengono promossi alla generazione 2.

    Soglia: un decimo il valore delle raccolte #Gen 0. Le applicazioni che eseguono bene seguono la regola di pollice menzionata nella descrizione per il contatore delle raccolte #Gen 0.

  • Raccolte # Gen 2. Il numero di volte in cui sono stati raccolti oggetti di seconda generazione. La generazione 2 è la più alta, pertanto gli oggetti che sopravvivono alla raccolta rimangono nella generazione 2. Le raccolte gen 2 possono essere molto costose, soprattutto se le dimensioni dell'heap gen 2 sono eccessive.

    Soglia: un decimo il valore delle raccolte # Gen 1. Le applicazioni che eseguono bene seguono la regola di pollice menzionata nella descrizione per il contatore delle raccolte #Gen 0.

  • % tempo in GC. Percentuale di tempo trascorso durante l'ultima Garbage Collection. Un valore medio del 5% o minore sarebbe considerato integro, ma i picchi più grandi di questo non sono insoliti. Si noti che tutti i thread vengono sospesi durante una Garbage Collection.

    La causa più comune di un tempo elevato in GC sta effettuando troppe allocazioni per ogni richiesta. La seconda causa più comune è l'inserimento di una grande quantità di dati nella cache ASP.NET, la rimozione, la rigenerazione e la reinserzione nella cache ogni pochi minuti. Spesso sono presenti piccole modifiche che possono essere apportate per ridurre notevolmente le allocazioni. Ad esempio, la concatenazione stringa può essere costosa per ogni richiesta, poiché le stringhe concatenate devono essere garbage collection. StringBuilder, con una capacità iniziale appropriata, offre prestazioni migliori rispetto alla concatenazione stringa. Tuttavia, StringBuilder deve anche essere garbage collection e, se usato in modo non corretto, può comportare più allocazioni rispetto alle aspettative perché vengono ridimensionati i buffer interni. La chiamata a Response.Write più volte in ogni stringa funziona anche meglio di combinarle con StringBuilder, quindi se è possibile evitare StringBuilder altogther, fare clic.

    Le applicazioni archiviano temporaneamente i dati in stringBuilder o MemoryStream durante la generazione di una risposta. Anziché ricreare questa risorsa di archiviazione temporanea in ogni richiesta, valutare l'implemeting di un pool di buffer riutilizzabile di matrici di caratteri o byte. Un pool di buffer è un oggetto con getBuffer e una routine ReturnBuffer . La routine GetBuffer tenta di restituire un buffer da un archivio interno di buffer, ma crea un nuovo buffer se l'archivio è vuoto. La routine ReturnBuffer restituisce il buffer all'archivio se il numero massimo di buffer archiviati non è ancora stato raggiunto, ma lo libera in caso contrario. Il lato negativo di questa implementazione del pool di buffer è che richiede il blocco per la sicurezza del thread. In alternativa, è possibile evitare l'impatto sulle prestazioni del blocco usando HttpContext.ApplicationInstance per accedere a un campo dell'istanza definito in global.asax. Esiste un'istanza di global.asax per ogni istanza della pipeline e quindi il campo è accessibile da una sola richiesta alla volta, rendendolo un luogo ideale per archiviare un carattere riutilizzabile o un buffer di byte.

    Per ridurre il tempo % in GC, è necessario conoscere il modello di allocazione. Usare CLR Profiler per profilare una singola richiesta o uno stress leggero per almeno un paio di minuti. Questi strumenti sono invasivi e non devono essere usati in producton. La visualizzazione Grafico allocazione visualizza la memoria totale allocata per ogni tipo di oggetto e lo stack di chiamate che ha eseguito l'allocazione. Usare questa operazione per ridurre le allocazioni eccessive. La visualizzazione Istogramma per dimensione (selezionare Tipi allocati istogrammi dal menu Visualizza) riepiloga le dimensioni degli oggetti allocati. Evitare di allocare oggetti di breve durata superiori a 85.000 byte. Questi oggetti vengono allocati nell'heap di oggetti di grandi dimensioni e sono più costosi da raccogliere. Nella visualizzazione Istogram per dimensioni è possibile selezionare gli oggetti con il mouse e fare clic con il pulsante destro del mouse per visualizzare chi li ha allocati. La riduzione delle allocazioni è un processo iterativo di modifiche e profilatura del codice.

    Soglia: media del 5% o minore; picchi di breve durata maggiori di quelli comuni. I valori medi maggiori di questo valore devono essere esaminati. Una nuova soglia deve essere impostata in base alle esigenze.

contatori ASP.NET

I contatori delle prestazioni in questa categoria vengono reimpostati solo su 0 quando viene avviato il servizio w3svc.

  • Riavvio dell'applicazione. Numero di riavvii dell'applicazione. La ricreazione del dominio dell'applicazione e la ricompilazione delle pagine richiede tempo, pertanto è necessario analizzare i riavvii imprevisti dell'applicazione. Il dominio dell'applicazione viene scaricato quando si verifica una delle operazioni seguenti:

    • Modifica di machine.config, web.configo global.asax.
    • Modifica della directory bin dell'applicazione o del relativo contenuto.
    • Quando il numero di compilazioni (ASPX, ASCX o ASAX) supera il limite specificato dalla <compilazione numRecompilesBeforeAppRestart=/>.
    • Modifica del percorso fisico di una directory virtuale.
    • Modifica dei criteri di sicurezza di accesso al codice.
    • Il servizio Web viene riavviato.

    Per le Web farm in produzione, è consigliabile rimuovere un server dalla rotazione prima di aggiornare il contenuto per ottenere prestazioni ottimali e affidabilità. Per un singolo server Web in produzione, è possibile aggiornare il contenuto mentre il server è in fase di caricamento. L'hotfix descritto nell'articolo della Knowledge Base 810281 è di interesse per chiunque verifichi errori dopo il riavvio di un'applicazione, ad esempio la condivisione di violazioni con un errore simile a "Impossibile accedere a FileName <> perché viene usato da un altro processo".

    Un problema che riguarda i riavvii software e le applicazioni antivirus è risolto nell'articolo della Knowledge Base 820746: FIX: alcuni programmi antivirus potrebbero causare il riavvio imprevisto delle applicazioni Web per v1.0 e nell'articolo della Knowledge Base 821438 per v1.1.

    Soglia: 0. In un mondo perfetto, il dominio dell'applicazione sopravviverà per la vita del processo. I valori eccessivi devono essere esaminati e una nuova soglia deve essere impostata in base alle esigenze.

  • Applicazioni in esecuzione. Numero di applicazioni in esecuzione.

  • Richieste correnti. Numero di richieste attualmente gestite dal ASP.NET ISAPI. Ciò include quelli accodati, in esecuzione o in attesa di essere scritti nel client. Questo contatore delle prestazioni è stato aggiunto alla versione 1.0 di ASP.NET nell'hotfix pre-SP3 descritto nell'articolo della Knowledge Base 329959.

    ASP.NET inizierà a rifiutare le richieste quando questo contatore supera la richiestaQueueLimit definita nella sezione di configurazione di processModel . Si noti che requestQueueLimit si applica a ASP.NET in IIS 5.0 durante l'esecuzione in aspnet_wp, ma forse sorprendentemente, si applica anche in IIS 6.0 durante l'esecuzione in w3wp. Non è noto che diverse impostazioni di configurazione di processModel si applicano ancora durante l'esecuzione in IIS 6.0. Questi includono requestQueueLimit, responseDeadlockInterval, maxWorkerThreads, maxIoThreads, minWorkerThreads e minIoThreads. Un bug nella versione 1.1 di Framework, corretto in ASP.NET 1.1 Giugno 2003 Hotfix Rollup Package, ha consentito ASP.NET di gestire un numero infinito di richieste durante l'esecuzione in IIS 6.0. La correzione causa ASP.NET rifiutare le richieste quando le richieste Correnti superano la richiestaQueueLimit.

    Per le applicazioni ASP classiche, le richieste accodate forniscono un avviso per quando le richieste verranno rifiutate. Per ASP.NET, le richieste correnti, insieme alle richieste nella coda dell'applicazione, forniscono questa funzionalità. Questo contatore viene usato anche dal meccanismo di rilevamento del deadlock ASP.NET. Se Richieste correnti è maggiore di 0 e non sono state ricevute risposte dal processo di lavoro per una durata maggiore del limite specificato da <processModel responseDeadlockInterval=/>, il processo viene terminato e viene avviato un nuovo processo. Nell'hotfix pre-SP3 descritto nell'articolo della Knowledge Base 328267, l'algoritmo è stato modificato in modo che le richieste correnti siano maggiori della somma di maxWorkerThreads e maxIoThreads, specificate nella < sezione processModel/>configuration. Si noti che per impostazione predefinita il timeout di esecuzione della richiesta è di 90 secondi ed è intenzionalmente minore di responseDeadlockInterval. Il timeout di esecuzione della richiesta può essere modificato tramite l'impostazione di configurazione httpRuntime executionTimeout=/> o la < proprietà Server.ScriptTimeout, ma deve essere sempre eseguita meno di responseDeadlockInterval.

  • Tempo di esecuzione richiesta. Numero di millisecondi eseguiti per eseguire l'ultima richiesta. Nella versione 1.0 di Framework, l'ora di esecuzione inizia quando il processo di lavoro riceve la richiesta e si arresta quando il ASP.NET ISAPI invia HSE_REQ_DONE_WITH_SESSION a IIS. Per IIS versione 5, questo include il tempo impiegato per scrivere la risposta al client, ma per IIS versione 6, i buffer di risposta vengono inviati in modo asincrono e quindi il tempo impiegato per scrivere la risposta al client non è incluso. Pertanto, nella versione 5 di IIS, un client con una connessione di rete lenta aumenterà notevolmente il valore di questo contatore.

    Nella versione 1.1 di Framework, l'ora di esecuzione inizia quando viene creato HttpContext per la richiesta e si arresta prima dell'invio della risposta a IIS. Supponendo che il codice utente non chiami HttpResponse.Flush, ciò implica che il tempo di esecuzione si arresta prima di inviare byte a IIS o al client per tale questione.

    ASP.NET\Tempo di esecuzione richiesta è un contatore dell'istanza e molto volatile. D'altra parte, il tempo per l'ultimo byte (TTLB) può essere facilmente medio e usato per calcolare una stima migliore delle prestazioni in un periodo di tempo. TTLB può essere calcolato tramite un semplice client HTTP scritto nel codice gestito oppure è possibile usare uno dei molti client HTTP disponibili per calcolare TTLB, ad esempio Application Center Test (ACT).

    Si noti che se <il debug di compilazione=> / è impostato su TRUE, la compilazione batch verrà disabilitata e l'impostazione <di configurazione httpRuntime executionTimeout=/> nonché le chiamate a Server.ScriptTimeout verranno ignorate. Ciò può causare problemi se l'impostazione <processModel responseDeadlockInterval=/> non è impostata su Infinite, poiché le richieste per le pagine di debug possono essere eseguite per sempre.

    Soglia: N.A. Il valore di questo contatore deve essere stabile. L'esperienza aiuterà a impostare una soglia per un determinato sito. Quando il modello di processo è abilitato, il tempo di esecuzione della richiesta include il tempo necessario per scrivere la risposta al client e quindi dipende dalla larghezza di banda della connessione del client.

  • Richieste accodate. Numero di richieste attualmente accodate. Quando viene eseguito in IIS 5.0, esiste una coda tra inetinfo e aspnet_wp e una coda per ogni directory virtuale. Quando si esegue in IIS 6.0, è presente una coda in cui le richieste vengono inviate al threadPool gestito dal codice nativo e una coda per ogni directory virtuale. Questo contatore include le richieste in tutte le code. La coda tra inetinfo e aspnet_wp è una pipe denominata tramite la quale la richiesta viene inviata da un processo all'altro. Il numero di richieste in questa coda aumenta se si verifica una carenza di thread di I/O disponibili nel processo di aspnet_wp. In IIS 6.0 aumenta quando sono presenti richieste in ingresso e una carenza di thread di lavoro.

    Si noti che le richieste vengono rifiutate quando il contatore Richieste correnti supera la <richiesta processModelQueueLimit=/>. Molte persone pensano che si verifichi quando il contatore Richieste accodate supera requestQueueLimit, ma questo non è il caso. Quando questo limite viene superato, le richieste verranno rifiutate con un codice di stato 503 e il messaggio "Server è troppo occupato". Se una richiesta viene rifiutata per questo motivo, non raggiungerà mai il codice gestito e i gestori degli errori non verranno notificati. Normalmente si tratta solo di un problema quando il server è sotto un carico molto elevato, anche se un carico "burst" ogni ora potrebbe causare anche questo. Per lo scenario di carico di burst insolito, è possibile che si sia interessati all'hotfix descritto nell'articolo della Knowledge Base 810259, che consente di aumentare il numero minimo di thread di I/O dal valore predefinito di 1 per CPU.

    Ogni directory virtuale ha una coda usata per mantenere la disponibilità dei thread di lavoro e I/O. Il numero di richieste in questa coda aumenta se il numero di thread di lavoro disponibili o thread di I/O disponibili scende al di sotto del limite specificato da <httpRuntime minFreeThreads=/>. Quando il limite specificato dall'app httpRuntimeRequestQueueLimit=/> viene superato, la richiesta viene rifiutata con un codice di stato 503 e il client riceve un'eccezione HttpException con il messaggio "Server troppo occupato".<

    Per sé, questo contatore non è un indicatore chiaro dei problemi di prestazioni, né può essere usato per determinare quando le richieste verranno rifiutate. Nell'articolo della Knowledge Base 329959 sono stati introdotti due nuovi contatori delle prestazioni per risolvere questo problema: richieste correnti e richieste nella coda dell'applicazione. Per le richieste rifiutate, vedere le descrizioni di questi due contatori.

  • Richieste rifiutate. Numero delle richieste rifiutate. Le richieste vengono rifiutate quando viene superato uno dei limiti di coda (vedere la descrizione delle richieste accodate). Le richieste possono essere rifiutate per diversi motivi. La latenza back-end, ad esempio quella causata da un server SQL lento, è spesso preceduta da un aumento improvviso del numero di istanze della pipeline e una diminuzione dell'utilizzo della CPU e delle richieste/sec. Un server può essere sovraccaricato durante i tempi di carico elevato a causa di vincoli di processore o memoria che in definitiva comportano il rifiuto delle richieste.

    La progettazione di un'applicazione può comportare un tempo di esecuzione eccessivo della richiesta. Ad esempio, la compilazione batch è una funzionalità in cui tutte le pagine di una directory vengono compilate in un singolo assembly quando viene ricevuta la prima richiesta di una pagina. Se sono presenti diverse centinaia di pagine in una directory, la prima richiesta in questa directory potrebbe richiedere molto tempo per l'esecuzione. Se < il batch di compilazione batchTimeout=/> viene superato, la compilazione batch continuerà in un thread in background e la pagina richiesta verrà compilata singolarmente. Se la compilazione batch ha esito positivo, l'assembly verrà mantenuto su disco e può essere riutilizzato dopo il riavvio di un'applicazione. Tuttavia, se global.asax, web.config, machine.config o un assembly nella cartella bin dell'applicazione viene modificato, il processo di compilazione batch verrà eseguito di nuovo a causa della modifica della dipendenza.

    Un'attenta progettazione di un sito di grandi dimensioni può avere un impatto significativo sulle prestazioni. In questo caso, è preferibile avere solo alcune pagine che variano il comportamento in base ai dati della stringa di query. In generale, è necessario ridurre al minimo il tempo di esecuzione della richiesta, che è meglio monitorato mediando il tempo per l'ultimo byte (TTLB) usando un client HTTP che richiede una o più pagine dal sito Web.

    I contatori delle prestazioni seguenti sono più adatti per individuare la causa delle richieste rifiutate:

    • Elaborazione\% Tempo processore
    • Process\Private Bytes
    • Processo\Conteggio dei thread
    • Servizio Web\Richieste di estensione ISAPI/sec
    • ASP.NET\Richieste correnti
    • ASP.NET\Richieste accodate
    • ASP.NET\Tempo di attesa richiesta
    • ASP.NET Numero di istanze di applicazioni\pipeline
    • ASP.NET applicazioni\richieste nella coda dell'applicazione

    Soglia: 0. Il valore di questo contatore deve essere 0. I valori maggiori di questo devono essere esaminati.

  • Tempo di attesa richiesta. Numero di millisecondi che la richiesta più recente ha trascorso in attesa nella coda o nella pipe denominata, presente tra inetinfo e aspnet_wp (vedere la descrizione delle richieste accodate). Ciò non include tempo trascorso in attesa nelle code dell'applicazione.

    Soglia: 1000. La richiesta media deve trascorrere 0 millisecondi in attesa nella coda.

  • Processi di lavoro in esecuzione. Numero corrente di processi di lavoro aspnet_wp. Per un breve periodo di tempo, un nuovo processo di lavoro e il processo di lavoro che viene sostituito possono coesistere. Anche se raramente, a volte elabora il deadlock durante l'uscita. Se si sospetta questo problema, è consigliabile usare uno strumento per monitorare il numero di istanze del processo di lavoro. In alternativa, è possibile usare il contatore delle prestazioni Memory\Available Mbyte, poiché questi processi sospesi utilizzeranno la memoria.

    Soglia: 2. Durante l'arresto del processo di lavoro precedente, potrebbero esserci due istanze. Se webRden è abilitato, la soglia deve essere #CPUs più 1. I valori maggiori di questo possono indicare un riavvio eccessivo del processo entro un periodo di tempo molto breve.

  • Riavvio del processo di lavoro. Numero di aspnet_wp riavvio del processo.

    Soglia: 1. I riavvii del processo sono costosi e indesiderati. I valori dipendono dalle impostazioni di configurazione del modello di processo, nonché dalle violazioni di accesso impreviste, dalle perdite di memoria e dai deadlock. Se aspnet_wp riavvia, una voce del registro eventi dell'applicazione indicherà perché. Le richieste verranno perse se si verifica una violazione di accesso o un deadlock. Se le impostazioni del modello di processo vengono usate per riciclare in modo preliminare il processo, sarà necessario impostare una soglia appropriata.

contatori delle applicazioni ASP.NET

I contatori delle prestazioni in questa categoria vengono reimpostati su 0 quando viene riavviato il dominio dell'applicazione o il servizio Web.

  • Cache Totale voci. Numero corrente di voci nella cache (sia utente che interno). Internamente, ASP.NET usa la cache per archiviare oggetti costosi da creare, inclusi gli oggetti di configurazione, le voci di assembly mantenute, i percorsi mappati dal metodo MapPath e gli oggetti stato sessione in-process.

    Nota La famiglia "Cache Total" dei contatori delle prestazioni è utile per diagnosticare i problemi con lo stato della sessione in-process. L'archiviazione di troppi oggetti nella cache è spesso la causa di perdite di memoria.

  • Rapporto totale di hit della cache. Rapporto totale di hit-to-miss di tutte le richieste di cache (sia utente che interno).

  • Cache Total Turnover Rate .Cache Total Turnover Rate (Tasso totale di fatturato della cache). Numero di aggiunte e rimozione nella cache al secondo (sia utente che interno). Un tasso elevato di fatturato indica che gli articoli vengono aggiunti rapidamente e rimossi, che possono essere costosi.

  • Voci dell'API cache. Numero di voci attualmente presenti nella cache utente.

  • Rapporto di hit dell'API cache. Rapporto totale di hit-to-miss delle richieste cache utente.

  • Frequenza di fatturato API cache. Numero di aggiunte e rimozione nella cache utente al secondo. Un tasso elevato di fatturato indica che gli articoli vengono aggiunti rapidamente e rimossi, che possono essere costosi.

  • Voci della cache di output. Numero di voci attualmente presenti nella cache di output.

  • Rapporto di hit della cache di output. Rapporto totale di hit-to-miss delle richieste cache di output.

  • Frequenza di fatturato della cache di output. Numero di aggiunte e rimozione nella cache di output al secondo. Un tasso elevato di fatturato indica che gli articoli vengono aggiunti rapidamente e rimossi, che possono essere costosi.

  • Numero di istanze della pipeline. Numero di istanze della pipeline attive. Solo un thread di esecuzione può essere eseguito all'interno di un'istanza della pipeline, pertanto questo numero fornisce il numero massimo di richieste simultanee elaborate per un'applicazione specificata. Il numero di istanze della pipeline deve essere costante. Gli aumenti improvvisi sono indicativi della latenza back-end (vedere la descrizione delle richieste rifiutate in precedenza).

  • Compilazioni totali. Numero di file ASAX, ASCX, ASHX, ASPX o ASMX compilati. Questo è il numero di file compilati, non il numero di assembly generati. Gli assembly vengono conservati su disco e riutilizzati fino a quando non viene modificata l'ora di creazione, l'ultima ora di scrittura o la lunghezza di una dipendenza di file. Le dipendenze di una pagina ASPX includono global.asax, web.config, machine.config, assembly dipendenti nella cartella bin e file ASCX a cui fa riferimento la pagina. Se si riavvia l'applicazione senza modificare alcuna dipendenza file, l'assembly conservato verrà ricaricato senza richiedere alcuna compilazione. Questo contatore delle prestazioni incrementerà solo quando un file viene inizialmente analizzato e compilato in un assembly.

    Per impostazione predefinita, la compilazione batch è abilitata, tuttavia, questo contatore incrementerà una volta per ogni file analizzato e compilato in un assembly, indipendentemente dal numero di assembly creati.

    Se la compilazione ha esito negativo, il contatore non verrà incrementato.

  • Errori durante l'elaborazione preliminare. Numero totale di errori di configurazione e analisi. Questo contatore viene incrementato ogni volta che si verifica un errore di configurazione o un errore di analisi. Anche se gli errori di configurazione vengono memorizzati nella cache, il contatore aumenta ogni volta che si verifica l'errore.

    Nota Non basarsi esclusivamente sui contatori delle prestazioni "Errori" per determinare se il server è integro. Vengono reimpostati su zero quando appDomain viene scaricato. Possono tuttavia essere usati per approfondire un problema specifico. In generale, usare l'evento Application_Error per avvisare gli amministratori dei problemi.

  • Errori durante la compilazione. Numero totale di errori di compilazione. La risposta viene memorizzata nella cache e questo contatore viene incrementato una sola volta fino a quando la ricompilazione non viene forzata da una modifica del file. Implementare la gestione degli errori personalizzati per generare un evento.

  • Errori durante l'esecuzione. Numero totale di errori di runtime.

  • Errori non gestiti durante l'esecuzione. Numero totale di eccezioni non gestite in fase di esecuzione. Ciò non include quanto segue:

    1. Errori cancellati da un gestore eventi (ad esempio, da Page_Error o Application_Error).
    2. Errori gestiti da una pagina di reindirizzamento.
    3. Errori che si verificano all'interno di un blocco try/catch.
  • Errori non gestiti durante l'esecuzione/sec. Numero totale di eccezioni non gestite al secondo in fase di esecuzione.

  • Totale errori. Somma degli errori durante la pre-elaborazione, gli errori durante la compilazione e gli errori durante l'esecuzione.

  • Errori totali/sec. Totale di errori durante la pre-elaborazione, errori durante la compilazione ed errori durante l'esecuzione al secondo.

  • Richieste in esecuzione. Numero di richieste attualmente in esecuzione. Questo contatore viene incrementato quando HttpRuntime inizia a elaborare la richiesta e viene decrementato al termine della richiesta. Nella versione 1.1 di Framework è presente un bug in questo contatore delle prestazioni risolto nel pacchetto di aggiornamento cumulativo ASP.NET 1.1 giugno 2003. Sfortunatamente, il bug non è descritto nell'articolo della Knowledge Base. Prima della correzione, il contatore includeva il tempo impiegato per scrivere la risposta al client.

  • Richieste nella coda dell'applicazione. Numero di richieste nella coda delle richieste dell'applicazione (vedere la descrizione delle richieste accodate in precedenza). Oltre alle richieste correnti, le richieste nella coda dell'applicazione forniscono un avviso per quando le richieste verranno rifiutate. Se sono presenti solo due directory virtuali, l'aumento dell'appRequestQueueLimit predefinito a 200 o 300 può essere adatto, soprattutto per le applicazioni lente con carico elevato.

  • Richieste non trovate. Numero di richieste per le risorse non trovate.

  • Richieste non autorizzate. Numero di richieste non riuscite a causa dell'accesso non autorizzato.

  • Timeout delle richieste. Numero di richieste con timeout.

  • Richieste riuscite. Numero di richieste eseguite correttamente.

  • Totale richieste. Numero di richieste dall'avvio dell'applicazione.

  • Richieste/sec. Numero di richieste eseguite al secondo. Preferisco "Web Service\ISAPI Extension Requests/sec" perché non è interessato dai riavvii dell'applicazione.

Contatori dei processi

Con questi contatori, i processi di interesse sono aspnet_wp e inetinfo.

  • % Tempo processore. Percentuale di tempo usata dai thread di questo processo tramite i processori.

    Soglia: 70%. I valori maggiori di questo per lunghi periodi di tempo indicano la necessità di acquistare hardware o ottimizzare l'applicazione.

  • Handle Count.

    Soglia: 10000. Un numero di handle pari a 2000 in aspnet_wp è sospetto e 10.000 supera i limiti accettabili. Si verificherà una riduzione notevole delle prestazioni se il numero totale di handle per tutti i processi supera circa 40.000, che è completamente raggiungibile durante un attacco Denial of Service contro IIS.

  • Byte privati. Dimensione corrente, in byte, della memoria di cui è stato eseguito il commit di proprietà di questo processo. Le perdite di memoria sono identificate da un aumento costante e prolungato dei byte privati. Questo è il contatore delle prestazioni migliore per rilevare perdite di memoria.

    Quando si esegue in IIS 5.0, nella sezione processModel memoryLimit=/> configuration deve essere impostato <un limite di memoria per byte privati. Quando viene eseguito in IIS 6.0, il limite di memoria deve essere impostato in Gestione IIS. Aprire Proprietà per il pool di applicazioni e nella scheda Riciclo specificare un limite per Memoria usata massima (in megabyte). Questo limite corrisponde ai byte privati. I byte privati per il processo di lavoro sono confrontati con il limite di memoria per determinare quando riciclare il processo. System.Web.Caching.Cache usa anche byte privati e il limite di memoria per determinare quando espellere gli elementi dalla cache ed evitare quindi di riciclare il processo. È consigliabile evitare il paging del limite di memoria del 60% della RAM fisica, soprattutto quando un nuovo processo sostituisce quello precedente a causa di un consumo eccessivo di memoria. Si noti che l'articolo della Knowledge Base 330469 risolve un problema con ASP.NET in cui non riesce a monitorare byte privati nei server con un numero elevato di processi in esecuzione. Questo hotfix consente anche al gestore della memoria della cache di funzionare correttamente quando è presente un numero elevato di processi in esecuzione.

    È importante regolare il limite di memoria nei computer con grandi quantità di RAM fisica, in modo che il gestore della memoria della cache e il riciclo del processo funzionino correttamente. Si supponga, ad esempio, di avere un server con 4 gigabyte (GB) di RAM fisica che usa il limite di memoria predefinito. Questo è un problema. Il 65% della RAM fisica è di 2,4 GB, maggiore dello spazio di indirizzi virtuale predefinito di 2 GB. Quale limite di memoria deve essere impostato su?

    Ci sono un paio di aspetti da considerare: prima di tutto, la probabilità di riscontrare un'eccezione OutOfMemoryException inizia ad aumentare notevolmente quando "Process\Virtual Bytes" è compreso tra 600 MB del limite di spazio degli indirizzi virtuali (in genere 2 GB) e in secondo luogo, i test hanno dimostrato che "Process\Virtual Bytes" è spesso maggiore di "Process\Private Bytes" di non più di 600 MB. Questa differenza è dovuta in parte alle aree MEM_RESERVE gestite dal GC, consentendo di eseguire rapidamente il commit di più memoria quando necessario. Questo implica che quando "Process\Private Bytes" supera 800 MB, la probabilità di riscontrare un aumento di OutOfMemoryException . In questo esempio il computer ha 4 GB di RAM fisica, quindi è necessario impostare il limite di memoria su 20% per evitare condizioni di memoria insufficiente. È possibile provare a usare questi numeri per ottimizzare l'utilizzo della memoria in un computer, ma se si vuole riprodurlo in modo sicuro, i numeri nell'esempio funzioneranno.

    Per riepilogare, impostare il limite di memoria sul valore inferiore del 60% della RAM fisica o 800 MB. Poiché v1.1 supporta 3 GB di spazio indirizzi virtuali, se si aggiunge /3 GB a boot.ini, è possibile usare in modo sicuro 1.800 MB anziché 800 MB come limite superiore.

    Si noti che quando si eseguono test, se si vuole forzare un GC e stabilizzare la memoria gestita, è possibile chiamare System.GC.GetTotalMemory(true) una volta. Questo metodo chiamerà GC. Raccogli e WaitForPendingFinalizers() ripetutamente fino a quando la memoria non si stabilizza entro il 5%.

    Soglia: minimo del 60% della RAM fisica e 800 MB. I valori superiori al 60% della RAM fisica totale iniziano ad avere un impatto sulle prestazioni, soprattutto durante i riavvii dell'applicazione e del processo. La liklihood di un OutOfMemoryException aumenta notevolmente quando i byte privati superano 800 MB in un processo con un limite di spazio di indirizzi virtuale di 2 GB.

  • Conteggio thread. Numero di thread attivi in questo processo. Il numero di thread aumenta spesso quando il carico è troppo elevato.

    Soglia: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs). La soglia deve essere aumentata se viene usata la modalità aspcompat: Soglia: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs * 2).

  • Byte virtuali. Dimensione corrente, in byte, dello spazio indirizzi virtuale per questo processo.

    Il limite di spazio degli indirizzi virtuali di un processo in modalità utente è 2 GB, a meno che non sia abilitato 3 GB di spazio indirizzi usando l'opzione /3GB in boot.ini. Le prestazioni diminuiscono man mano che questo limite viene avvicinato e in genere si verifica un arresto anomalo del processo o del sistema. Lo spazio indirizzi viene frammentato quando si avvicina il limite di 2 GB o 3 GB, quindi è consigliabile una soglia conservativa di 1,4 o 2,4 GB, rispettivamente. Se si verificano problemi in questo caso, verrà visualizzata l'eccezione System.OutOfMemoryException e questo potrebbe causare o meno l'arresto anomalo del processo.

    Durante l'esecuzione in IIS 6.0, è possibile impostare un limite di memoria virtuale in Gestione IIS. Tuttavia, l'impostazione di questa impostazione non corretta può causare problemi per ASP.NET. ASP.NET elimina gli elementi dalla cache per evitare di superare il limite di byte privati, ma l'algoritmo usa byte privati e il limite byte privati in questa determinazione. Non monitora i byte virtuali o il limite di byte virtuali. Dato che la differenza tra byte virtuali e byte privati non è in genere superiore a 600 MB, è possibile impostare il limite di byte virtuali su un valore di 600 MB superiore al limite byte privati se si è preoccupati della possibilità di perdite di memoria virtuale o frammentazione. Se questo è auspicabile, impostare un limite per La memoria virtuale massima (in megabyte), disponibile nella scheda Riciclo per Le proprietà del pool di applicazioni.

    La versione 1.0 di Framework non supporta 3 GB di spazio indirizzi nel processo di lavoro o nel servizio di stato. Per istruzioni su come abilitare lo spazio indirizzi di 3 GB all'interno di inetinfo.exe, vedere l'articolo della Knowledge Base 320353 . La versione 1.1 supporta completamente 3 GB di spazio indirizzi per il processo di lavoro e il servizio di stato.

    Soglia: 600 MB inferiori alle dimensioni dello spazio indirizzi virtuale, ovvero 1,4 o 2,4 GB.

Contatore del processore

  • % Tempo processore. Percentuale di tempo trascorso da tutti i thread usando i processori.

    Soglia: 70%. I valori maggiori di questo per lunghi periodi di tempo indicano la necessità di acquistare hardware o ottimizzare l'applicazione.

Contatore memoria

  • Byte disponibili. Quantità di RAM fisica disponibile.

    Soglia: 20% della RAM fisica. I valori inferiori a questo devono essere esaminati e possono indicare la necessità di acquistare hardware.

Contatore di sistema

  • Cambi di contesto/sec. Frequenza con cui i processori cambiano i contesti del thread. Un numero elevato può indicare conflitti di blocco elevati o transizioni tra la modalità utente e kernel. I commutatori di contesto/sec devono aumentare in modo lineare con velocità effettiva, carico e numero di CPU. Se aumenta in modo esponenziale, si verifica un problema. Un profiler deve essere usato per ulteriori indagini.

Contatori dei servizi Web

  • Connessioni correnti. Una soglia per questo contatore dipende da molte variabili, ad esempio il tipo di richieste (ISAPI, CGI, HTML statico e così via), l'utilizzo della CPU e così via. Una soglia deve essere sviluppata attraverso l'esperienza.
  • Totale richieste metodo/sec. Usato principalmente come metrica per la diagnosi dei problemi di prestazioni. Può essere interessante confrontarlo con "ASP.NET Applications\Requests/sec" e "Web Service\ISAPI Extension Requests/sec" per visualizzare la percentuale di pagine statiche servite rispetto alle pagine di cui viene eseguito il rendering da aspnet_isapi.dll.
  • Richieste di estensione ISAPI al secondo. Usato principalmente come metrica per la diagnosi dei problemi di prestazioni. Può essere interessante confrontarlo con "ASP.NET Applications\Requests/sec" e "Web Service\Total Method Requests/sec". Si noti che include le richieste a tutte le estensioni ISAPI, non solo aspnet_isapi.dll.

Conclusione

Un attento test di stress e prestazioni di un'applicazione prima di andare in tempo reale può prevenire un grave mal di testa. Ci sembrano due grandi blocchi a cascata che molte persone incontrano:

  1. È necessario usare un client HTTP in grado di simulare il traffico e caricare che si prevede che il sito Web abbia esperienza.
  2. È necessario testare l'intera applicazione in un ambiente quasi identico all'ambiente di produzione.

Non è facile simulare il traffico reale del sito Web, ma posso dire onestamente che la maggior parte delle applicazioni che riscontrano problemi non sono mai stati sottoposti a test di stress adeguati. Questo articolo illustra i contatori delle prestazioni e crea alcuni strumenti utili per il monitoraggio delle prestazioni. Per applicare il carico, è consigliabile usare Microsoft Application Center Test (ACT), incluso in Microsoft® Visual Studio® .NET. Per altre informazioni su questo strumento di stress, vedere Microsoft Application Center Test 1.0, Visual Studio .NET Edition. Consiglio anche microsoft® Web Application Stress Tool (WAST). È possibile scaricarlo gratuitamente da TechNet. Se l'applicazione usa ViewState, è necessario usare ACT perché WAST non è in grado di analizzare dinamicamente la risposta.

Non so cosa riguarda gli ambienti di produzione, ma c'è sicuramente qualcosa di speciale su di loro. Non posso contare i tempi in cui ho sentito l'affermazione" "Il problema si verifica solo nel nostro sito di produzione". In genere la differenza è l'applicazione stessa. Spesso è presente una parte dell'applicazione che non può essere simulata nel lab. Ad esempio, il server annunci è stato omesso dal test o il database usato per simulare il database reale è sostanzialmente diverso. A volte le differenze di rete o DNS sono la causa e talvolta è una differenza nell'hardware in cui vengono eseguiti i server.

Ho eseguito il debug e il monitoraggio delle prestazioni delle applicazioni ASP.NET per diversi anni, ma ci sono ancora momenti in cui ho bisogno di aiuto. Se ci si trova in questa posizione, i forum sul sito Web ASP.NET sono un buon posto per trovare risposte. Tuttavia, se sei davvero in un binding, non esitare a contattare il supporto tecnico Microsoft usando le informazioni di contatto fornite su tale sito. Si noti che se un problema è determinato da Microsoft come risultato di un difetto in un prodotto Microsoft, non verrà addebitato alcun addebito per tale evento imprevisto.

Si spera che questo documento abbia fornito gli strumenti e le informazioni necessarie per garantire l'affidabilità e le prestazioni dell'applicazione. In caso di domande, pubblicarle su ASP.NET Web e farò del mio meglio per rispondere. Buon lavoro!

Informazioni sull'autore

Thomas Marquardt è uno sviluppatore del team ASP.NET di Microsoft. Sta eseguendo il debug e l'analisi dei problemi di prestazioni con le applicazioni ASP.NET dall'inverno del 2000. Thomas vuole ringraziare Dmitry Robsman, development manager per ASP.NET a Microsoft, per ore e ore di assistenza e indicazioni nel corso degli anni.

© Microsoft Corporation. Tutti i diritti sono riservati.