Freigeben über

ASP.NET Leistungsüberwachung und wann Administratoren warnungen müssen

  • Artikel

 

Thomas Marquardt
Microsoft Corporation

Aktualisiert juli 2003

Gilt für:
   Microsoft® ASP.NET

Zusammenfassung: Erläutert, welche Leistungsindikatoren bei der Diagnose von Stress- und Leistungsproblemen in Microsoft ASP.NET-Anwendungen am hilfreichsten sind, welche Schwellenwerte festgelegt werden sollten, um Administratoren auf Probleme aufmerksam zu machen, und andere Ressourcen, die zum Überwachen der Integrität einer ASP.NET-Anwendung verwendet werden können. (17 gedruckte Seiten)

Laden Sie den Quellcode für diesen Artikel herunter.

Contents

Überwachen von Leistungsindikatoren
Überwachen des Ereignisprotokolls
Überwachen der W3C- und HTTPERR-Protokolle
Andere Ressourcen, die zum Überwachen von ASP.NET verwendet werden
Grundlegendes zu den Leistungsindikatoren
   .NET CLR-Ausnahmeindikator
   .NET CLR-Ladeindikatoren
   .NET CLR-Speicherindikatoren
   ASP.NET Indikatoren
   ASP.NET Anwendungsindikatoren
   Prozessindikatoren
   Prozessorindikator
   Speicherindikator
   Systemindikator
   Webdienstindikatoren
Zusammenfassung

Überwachen von Leistungsindikatoren

Für die Überwachung von Anwendungen stehen viele Leistungsindikatoren zur Verfügung. Die Auswahl, welche in Leistungsprotokolle aufgenommen werden sollen, kann schwierig sein, und es ist eine Kunst, sie zu interpretieren. Dieser Artikel sollte Ihnen helfen, sich mit beiden Aufgaben wohler zu fühlen.

Mindestens sollten die folgenden Leistungsindikatoren für Microsoft® ASP.NET-Anwendungen überwacht werden:

  • Processor(_Total)\% Processor Time
  • Process(aspnet_wp)\% Prozessorzeit
  • Process(aspnet_wp)\Private Bytes
  • Process(aspnet_wp)\Virtual Bytes
  • Process(aspnet_wp)\Handle Count
  • Microsoft® .NET CLR-Ausnahmen\# Ausgelöste Auslöse /Sek.
  • ASP.NET\Anwendungsneustarts
  • ASP.NET\Abgelehnte Anforderungen
  • ASP.NET\Workerprozessneustarts (gilt nicht für IIS 6.0)
  • Arbeitsspeicher\Verfügbare MBytes
  • Webdienst\Aktuelle Verbindungen
  • Webdienst\ISAPI-Erweiterungsanforderungen/s

Im Folgenden finden Sie eine größere Liste von Leistungsindikatoren, die für die Überwachung der Leistung nützlich sind. Es ist immer gut, über mehr Leistungsdaten zu verfügen, als nicht ausreichen, insbesondere, wenn ein Problem auftritt, das sich nicht leicht reproduzieren lässt. In der Liste werden mehrere Leistungsindikatoren weggelassen, die in der Regel nicht benötigt werden. Beispielsweise sind die Leistungsindikatoren sitzungsstatus und Transaktionen nur erforderlich, wenn die Features verwendet werden.

Einige Schwellenwerte werden basierend auf meiner Erfahrung mit dem Debuggen und Testen ASP.NET Anwendungen empfohlen. Sie können in diesem Artikel nach "Schwellenwert" suchen, um direkt zu ihnen zu springen. Administratoren sollten basierend auf ihrer Erfahrung ermitteln, ob Warnungen ausgelöst werden sollen, wenn diese Schwellenwerte überschritten werden. In den meisten Fällen sind Warnungen geeignet, insbesondere wenn der Schwellenwert für längere Zeiträume überschritten wird.

Überwachen des Ereignisprotokolls

Es ist wichtig, das Ereignisprotokoll auf Nachrichten von ASP.NET und Microsoft® Internet Information Server (IIS) zu überwachen. ASP.NET schreibt z. B. nachrichten in das Anwendungsprotokoll, z. B. jedes Mal, wenn der aspnet_wp Workerprozess beendet wird. IIS 6.0 schreibt nachrichten in die Anwendungs- und/oder Systemprotokolle, z. B. jedes Mal, wenn sich der w3wp-Workerprozess als fehlerhaft meldet oder abstürzt. Es ist recht einfach, eine .NET-Anwendung zu schreiben, die das Anwendungsprotokoll liest und Nachrichten aus ASP.NET und IIS herausfiltert und bei Bedarf eine Warnung auslöst (E-Mail sendet oder einen Pager wählt).

Überwachen der W3C- und HTTPERR-Protokolle

Aktivieren Sie zunächst die W3C-Protokollierung für IIS 5.0 und IIS 6.0 über den IIS-Manager (Internet Information Services). Dieses Protokoll kann so konfiguriert werden, dass es verschiedene Daten zu den Anforderungen enthält, z. B. den URI, status Code usw. Überprüfen Sie das Protokoll auf Fehlercodes wie 404 Nicht gefunden, und ergreifen Sie ggf. Maßnahmen, um Links zu korrigieren. Unter IIS 6.0 ist der Unterstatuscode im Protokoll enthalten und für das Debuggen nützlich. IIS verwendet Unterstatuscodes, um bestimmte Probleme einzurücken. 404.2 gibt beispielsweise an, dass die ISAPI-Erweiterung, die die Anforderung verarbeitet, gesperrt ist. Eine Liste mit status- und Unterstatuscodes finden Sie im Thema Informationen zu benutzerdefinierten Fehlermeldungen.

Neu für IIS 6.0, werden fehlerhafte oder fehlerhafte Anforderungen und Anforderungen, die nicht von einem Anwendungspool bereitgestellt werden können, im HTTPERR-Protokoll protokolliert, indem HTTP.SYS, dem Kernelmodustreiber für die Verarbeitung von HTTP-Anforderungen. Jeder Eintrag enthält die URL und eine kurze Beschreibung des Fehlers.

Überprüfen Sie das HTTPERR-Protokoll auf abgelehnte Anforderungen. Anforderungen werden von HTTP.SYS abgelehnt, wenn die Kernelanforderungswarteschlange überschritten wird und wenn die Anwendung vom Feature Rapid Fail Protection offline geschaltet wird. Wenn das erste Problem auftritt, wird die URL mit der Meldung QueueFull protokolliert, und wenn das zweite auftritt, lautet die Nachricht AppOffline. Standardmäßig ist die Kernelanforderungswarteschlange auf 1.000 festgelegt und kann im IIS-Manager auf der Seite Anwendungspooleigenschaften konfiguriert werden. Ich empfehle, diese auf 5.000 für einen ausgelasteten Standort zu erhöhen, da die Kernelanforderungswarteschlange leicht 1.000 überschreiten kann, wenn ein Anwendungspool abstürzt, während sich eine Website unter einer sehr hohen Auslastung befindet.

Überprüfen Sie das HTTPERR-Protokoll auf Anforderungen, die aufgrund eines Absturzes des Arbeitsprozesses verloren gehen oder hängen. In diesem Fall wird die URL mit der Nachricht Connection_Abandoned_By_AppPool für jede Anforderung während des Flugs protokolliert. Eine Anforderung im Flug ist eine Anforderung, die zur Verarbeitung an einen Workerprozess gesendet wurde, aber nicht abgeschlossen wurde, bevor der Absturz abstürzt oder aufhängt.

Details zum HTTPERR-Protokoll finden Sie im Microsoft Knowledge Base-Artikel 820729: INFO: Fehlerprotokollierung in der HTTP-API.

Andere Ressourcen, die zum Überwachen von ASP.NET verwendet werden

Leistungsindikatoren und die Ereignisprotokolle erfassen nicht alle auftretenden Fehler und sind daher nicht vollständig ausreichend für die Überwachung ASP.NET. Ich empfehle, eine einfache Anwendung zu schreiben, die eine HTTP-Anforderung für eine oder mehrere Seiten sendet und eine bestimmte Antwort erwartet. Dieses Tool sollte die Zeit bis zum letzten Byte (TTLB) überwachen, um sicherzustellen, dass Seiten rechtzeitig bereitgestellt werden. Außerdem sollten alle auftretenden Fehler erfasst werden, da diese Informationen zur Analyse des Problems benötigt werden.

Das IIS 6.0 Resource Kit enthält Log Parser 2.1, ein Tool zum Analysieren von Protokolldateien (W3C-Protokoll, HTTPERR-Protokoll, Ereignisprotokolle) und zum Speichern der Ergebnisse in einer Datei oder Datenbank. Das Ressourcenkit kann unter Microsoft® Windows® XP und Microsoft® Windows Server™ 2003 installiert werden.

Sie können auch eine Anwendung schreiben, die Leistungsdaten sammelt, das Ereignisprotokoll filtert und Schlüsseldaten in einer Microsoft® SQL Server-Datenbank aufzeichnet. Dies ist erstaunlich einfach mit dem System.Diagnostics-Namespace . Sie können sogar Workerprozessneustarts mit der System.Diagnostics.Process-Klasse überwachen.

Verwenden Sie den Link am Anfang dieses Artikels, um Beispielcode für mehrere nützliche Tools herunterzuladen:

  1. Quellcode für snap.exe, ein Befehlszeilentool zum Protokollieren von Leistungsdaten für Prozesse. Die Datei Snap.cs enthält eine kurze Beschreibung und erläutert, wie das Tool kompiliert wird.
  2. Quellcode für HttpClient.exe, ein einfacher Client, der die Zeit bis zum letzten Byte (TTLB) für HTTP-Anforderungen aufzeichnet. Die Datei HttpClient.cs enthält eine kurze Beschreibung und erläutert, wie das Tool kompiliert wird.
  3. Quellcode für qqq.exe, ein Befehlszeilentool zum Stresstesten einer ASP.NET Anwendung. Bei Verwendung in Kombination mit einem Stressclient, z. B. Microsoft® Application Center Test (ACT), fügt dieses Tool Debugger an den Arbeitsprozess an und überwacht bestimmte Leistungsindikatoren. Sie kann so eingestellt werden, dass sie in die Debugger einbricht, wenn die Leistung beeinträchtigt wird. Die Datei qqq.cs enthält eine breif-Beschreibung und erläutert, wie das Tool kompiliert wird.
  4. Die Seite pminfo.aspx verwendet die System.Web.ProcessModelInfo-Klasse , um Informationen zu Prozessneustarts von aspnet_wp anzuzeigen. Der Verlauf wird beibehalten, bis der w3svc-Dienst beendet wird.
  5. Quellcode für ErrorHandler.dll. Dies ist ein IHttpModule, das Sie der HTTP-Pipeline hinzufügen können, um nicht behandelte Ausnahmen im Ereignisprotokoll zu protokollieren. Es ist besser, Fehler in einer SQL Server Datenbank zu protokollieren, aber im Beispiel wird der Einfachheit halber das Ereignisprotokoll verwendet.

Ein weiterer einfacher Schritt ist die Implementierung Application_Error. Sie können global.asax den folgenden Text hinzufügen und sofort mit der Protokollierung der meisten nicht behandelten Fehler im Anwendungsprotokoll beginnen:

<%@ 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 werden Parser-, Kompilierungs- und Laufzeitfehler innerhalb von Seiten abfangen. Es werden weder Konfigurationsprobleme abfangen noch Fehler abfangen, die in inetinfo auftreten, während aspnet_isapi die Anforderung verarbeitet. Außerdem muss das identitätswechselbasierte Token über die Berechtigung zum Schreiben in diese Ereignisquelle verfügen. Sie können das Problem mit dem Identitätswechsel vermeiden, indem Sie Fehler in einer SQL Server Datenbank protokollieren.

Nicht zuletzt sind die Microsoft-Debugtools® für Windows sehr nützlich für das Debuggen von Problemen auf einem Produktionswebserver. Diese Tools können von https://www.microsoft.com/whdc/ddk/debugging/installx86.mspxheruntergeladen werden. Es gibt eine Debuggererweiterung namens sos.dll, die Sie in den Debugger laden können, windbg.exe oder cdb.exe, um verwalteten Code zu debuggen. Es kann Inhalte des Garbage Collection-Heaps (GC) abspeichern, verwaltete Stapelablaufverfolgungen anzeigen, die Untersuchung von Konflikten für verwaltete Sperren unterstützen, Threadpoolstatistiken anzeigen und vieles mehr. Dies kann als Teil des Debugtoolsets heruntergeladen werden, das unter Produktionsdebuggen für .NET Framework Anwendungen erwähnt wird.

Grundlegendes zu den Leistungsindikatoren

Im Folgenden finden Sie eine kurze Beschreibung der wichtigen Leistungsindikatoren und deren Verwendung.

.NET CLR-Ausnahmeindikator

Der _Global_-Indikator instance sollte nicht mit diesem Indikator verwendet werden, da er von allen verwalteten Prozessen aktualisiert wird. Verwenden Sie stattdessen die aspnet_wp instance.

  • #Exceps ausgelöst/Sek. Die Gesamtanzahl der verwalteten Ausnahmen, die pro Sekunde ausgelöst werden. Wenn diese Zahl zunimmt, verschlechtert sich die Leistung. Ausnahmen sollten nicht im Rahmen der normalen Verarbeitung ausgelöst werden. Beachten Sie jedoch, dass Response.Redirect, Server.Transfer und Response.End alle dazu führen, dass eine ThreadAbortException mehrmals ausgelöst wird, und eine Website, die stark von diesen Methoden abhängig ist, eine Leistungseinbuße verursacht. Wenn Sie Response.Redirect verwenden müssen, rufen Sie Response.Redirect(url, false) auf, wodurch Response.End nicht aufgerufen wird und daher nicht ausgelöst wird. Der Nachteil ist, dass der Benutzercode, der dem Aufruf von Response.Redirect(url, false) folgt, ausgeführt wird. Es ist auch möglich, eine statische HTML-Seite zur Umleitung zu verwenden. Der Microsoft Knowledge Base-Artikel 312629 enthält weitere Details.

    Zusätzlich zur Überwachung dieses sehr nützlichen Leistungsindikators sollte das Application_Error-Ereignis verwendet werden, um Administratoren auf Probleme hinzuweisen.

    Schwellenwert: 5 % der RPS. Werte, die größer sind, sollten untersucht werden, und bei Bedarf sollte ein neuer Schwellenwert festgelegt werden.

.NET CLR-Ladeindikatoren

Der _Global_-Indikator instance sollte nicht mit diesen Leistungsindikatoren verwendet werden, da er von allen verwalteten Prozessen aktualisiert wird. Verwenden Sie stattdessen die aspnet_wp instance.

  • Aktuelle AppDomains. Die aktuelle Anzahl der im Prozess geladenen AppDomains. Der Wert dieses Indikators sollte mit der Anzahl von Webanwendungen plus 1 identisch sein. Die zusätzliche AppDomain ist die Standarddomäne.

  • Aktuelle Assemblys. Die aktuelle Anzahl der im Prozess geladenen Assemblys. Standardmäßig werden ASPX- und ASCX-Dateien in einem Verzeichnis "batch" kompiliert. Dies ergibt in der Regel ein bis drei Assemblys, abhängig von Abhängigkeiten. Wenn beispielsweise ASPX-Seiten mit Analysezeitabhängigkeiten von ASCX-Dateien vorhanden sind, werden in der Regel zwei Assemblys generiert. Eine enthält die ASPX-Dateien, die anderen ASCX-Dateien. Zu den Analysezeitabhängigkeiten gehören die Von den <Anweisungen %@ import %>, <%@ reference %> und <%@ register %> erstellt wurden. Ein Steuerelement, das über die LoadControl-Methode geladen wird, erstellt keine Analysezeitabhängigkeit. Beachten Sie, dass global.asax selbst zu einer Assembly kompiliert wird.

    Gelegentlich wird ein übermäßiger Arbeitsspeicherverbrauch durch eine ungewöhnlich große Anzahl geladener Assemblys verursacht. Beispielsweise funktioniert eine Website, auf der Nachrichtenartikel angezeigt werden, mit einer kleinen Gruppe von ASPX-Dateien, die die Nachrichten aus einer Datenbank abrufen, besser als eine einzelne ASPX-Datei, die für jeden Artikel verwendet wird. Websitedesigner sollten versuchen, Inhalte dynamisch zu generieren, die Zwischenspeicherung zu nutzen und die Anzahl von ASPX- und ASCX-Seiten zu reduzieren.

    Assemblys können nicht aus einer AppDomain entladen werden. Um übermäßigen Arbeitsspeicherverbrauch zu verhindern, wird die AppDomain entladen, wenn die Anzahl der neu kompilierungsfähigen (ASPX, ASCX, ASAX) den durch <die Kompilierung numRecompilesBeforeAppRestart=/>angegebenen Grenzwert überschreitet. Beachten Sie, dass die Batchkompilierung deaktiviert ist, wenn das <%@ page debug=%> -Attribut auf true festgelegt ist oder wenn <kompilierung debug=/> auf true festgelegt ist.

  • Bytes im Ladeprogramm heap. Die Anzahl der vom Klassenladeprogramm für alle AppDomains zugesagten Bytes. Dieser Indikator sollte einen stabilen Zustand erreichen. Wenn dieser Indikator kontinuierlich erhöht wird, überwachen Sie den Zähler "Aktuelle Assemblys". Möglicherweise werden zu viele Assemblys pro AppDomain geladen.

.NET CLR-Speicherindikatoren

Der _Global_-Indikator instance sollte nicht mit diesen Leistungsindikatoren verwendet werden, da er von allen verwalteten Prozessen aktualisiert wird. Verwenden Sie stattdessen die aspnet_wp instance.

  • # Bytes in allen Heaps. Die Anzahl der von verwalteten Objekten zugesagten Bytes. Dies ist die Summe des großen Objektheaps und der Heaps der Generation 0, 1 und 2. Diese Speicherbereiche sind vom Typ MEM_COMMIT (siehe Platform SDK-Dokumentation für VirtualAlloc). Der Wert dieses Leistungsindikators ist immer kleiner als der Wert von Process\Private Bytes, der alle MEM_COMMIT Regionen für den Prozess zählt. Private Bytes minus # Bytes in allen Heaps ist die Anzahl von Bytes, die von nicht verwalteten Objekten committet werden. Der erste Schritt bei der Untersuchung übermäßiger Speicherauslastung besteht darin, zu ermitteln, ob er von verwalteten oder nicht verwalteten Objekten verwendet wird.

    Um eine übermäßige Auslastung des verwalteten Arbeitsspeichers zu untersuchen, empfehle ich WINDBG.EXE und SOS.DLL, über die Sie sich unter Produktionsdebugging für .NET Framework-Anwendungen informieren können. SOS.DLL verfügt über einen Befehl "!dumpheap –stat", der die Anzahl, Größe und den Typ der Objekte im verwalteten Heap auflistet. Sie können "!dumpheap –mt" verwenden, um die Adresse eines Objekts abzurufen, und "!gcroot", um seine Wurzeln anzuzeigen. Der Befehl "!eeheap" zeigt Statistiken zur Speichernutzung für die verwalteten Heaps an.

    Ein weiteres nützliches Tool zur Diagnose der Speicherauslastung ist der CLR-Profiler, der unten ausführlicher erläutert wird.

    Übermäßige Auslastung des verwalteten Speichers hat im Allgemeinen folgende Ursachen:

    1. Einlesen umfangreicher Datasets in den Arbeitsspeicher.
    2. Erstellen übermäßig vieler Cacheeinträge.
    3. Hoch- oder Herunterladen großer Dateien.
    4. Übermäßige Verwendung von regulären Ausdrücken oder Zeichenfolgen während des Analysieren von Dateien.
    5. Übermäßiger ViewState-Wert.
    6. Zu viele Daten im Sitzungszustand oder zu viele Sitzungen.

  • # Gen 0-Sammlungen. Die Häufigkeit, mit der Objekte der Generation 0 gesammelt wurden. Objekte, die überleben, werden zur 1. Generation heraufgestuft. Eine Auflistung wird ausgeführt, wenn Raum zum Zuweisen eines Objekts erforderlich ist, oder wenn jemand eine Sammlung erzwingt, indem System.GC.Collect aufgerufen wird. Sammlungen, die höhere Generationen umfassen, dauern länger, da ihnen Sammlungen niedrigerer Generationen vorangestellt werden. Versuchen Sie, den Prozentsatz der Sammlungen der 2. Generation zu minimieren. Als Faustregel gilt, dass die Anzahl der Sammlungen der Generation 0 10 mal größer sein sollte als die Anzahl der Sammlungen der Generation 1, und ähnlich für generation 1 und 2. Die Indikatoren #Gen N Collections und % Time in GC sind am besten geeignet, um Leistungsprobleme zu identifizieren, die durch übermäßige Zuordnungen verursacht werden. Schritte zum Verbessern der Leistung finden Sie in der Beschreibung für % Time in GC.

  • # Gen1-Sammlungen. Die Häufigkeit, in der Objekte der 1. Generation gesammelt wurden. Objekte, die überleben, werden auf Generation 2 heraufgestuft.

    Schwellenwert: ein Zehntel des Werts von # Gen 0 Collections. Anwendungen, die eine gute Leistung erbringen, befolgen die Faustregel, die in der Beschreibung für den Indikator #Gen 0 Collections erwähnt wird.

  • # Gen2-Sammlungen. Die Häufigkeit, mit der Objekte der 2. Generation gesammelt wurden. Generation 2 ist die höchste, daher verbleiben Objekte, die eine Sammlung überleben, in generation 2. Gen2-Sammlungen können sehr teuer sein, besonders wenn die Größe des Gen 2-Heaps übermäßig groß ist.

    Schwellenwert: ein Zehntel des Werts von # Gen1 Collections. Anwendungen, die eine gute Leistung erbringen, befolgen die Faustregel, die in der Beschreibung für den Indikator #Gen 0 Collections erwähnt wird.

  • GC-Zeitdauer in Prozent. Der Prozentsatz der Zeit, die für die letzte Garbage Collection aufgewendet wurde. Ein Durchschnittswert von 5 % oder weniger würde als fehlerfrei gelten, aber Spitzen, die größer sind, sind nicht ungewöhnlich. Beachten Sie, dass alle Threads während einer Garbage Collection angehalten werden.

    Die häufigste Ursache für eine hohe % Time in GC ist, dass zu viele Zuordnungen pro Anforderungsbasis durchgeführt werden. Die zweithäufigste Ursache ist das Einfügen einer großen Datenmenge in den ASP.NET Cache, das Entfernen, das Erneute Generieren und alle paar Minuten das erneute Einfügen in den Cache. Es gibt oft kleine Änderungen, die vorgenommen werden können, um die Zuordnungen erheblich zu reduzieren. Beispielsweise kann die Zeichenfolgenverkettung auf Anforderungsbasis teuer sein, da die verketteten Zeichenfolgen mit Garbage Collection gesammelt werden müssen. StringBuilder mit einer geeigneten Anfangskapazität ist besser als die Zeichenfolgenverkettung. StringBuilder muss jedoch auch garbage collection sein und kann bei falscher Verwendung zu mehr Zuordnungen als erwartet führen, da die Größe der internen Puffer geändert wird. Das mehrfache Aufrufen von Response.Write für jede Zeichenfolge ist noch besser als die Kombination mit StringBuilder. Wenn Sie also stringBuilder altogther vermeiden können, sollten Sie dies tun.

    Anwendungen speichern Daten häufig vorübergehend in einem StringBuilder oder MemoryStream, während sie eine Antwort generieren. Anstatt diesen temporären Speicher für jede Anforderung neu zu erstellen, sollten Sie erwägen, einen wiederverwendbaren Pufferpool mit Zeichen- oder Bytearrays zu erstellen. Ein Pufferpool ist ein Objekt mit einem GetBuffer und einer ReturnBuffer-Routine . Die GetBuffer-Routine versucht, einen Puffer aus einem internen Pufferspeicher zurückzugeben, erstellt jedoch einen neuen Puffer, wenn der Speicher leer ist. Die ReturnBuffer-Routine gibt den Puffer an den Speicher zurück, wenn die maximale Anzahl gespeicherter Puffer noch nicht erreicht wurde, gibt ihn aber ansonsten frei. Der Nachteil dieser Pufferpoolimplementierung besteht darin, dass für die Threadsicherheit eine Sperre erforderlich ist. Alternativ können Sie die Auswirkungen der Sperrung auf die Leistung vermeiden, indem Sie httpContext.ApplicationInstance verwenden, um auf ein in global.asax definiertes instance Feld zuzugreifen. Es gibt einen instance von global.asax für jede Pipeline instance. Daher ist das Feld jeweils nur von einer Anforderung aus zugänglich, sodass es ein hervorragender Ort zum Speichern eines wiederverwendbaren Zeichens oder Bytepuffers ist.

    Um die Zeit in % in GC zu reduzieren, müssen Sie Ihr Zuordnungsmuster kennen. Verwenden Sie den CLR Profiler , um höchstens ein paar Minuten lang ein Profil für eine einzelne Anforderung oder eine leichte Belastung zu erstellen. (Diese Werkzeuge sind invasiv und nicht für den Einsatz in producton vorgesehen.) In der Ansicht Zuordnungsdiagramm werden der gesamt für jeden Objekttyp zugeordnete Arbeitsspeicher und die Aufrufliste angezeigt, die die Zuordnung durchgeführt hat. Verwenden Sie dies, um übermäßige Zuordnungen zu reduzieren. Die Ansicht Histogramm nach Größe (wählen Sie im Menü Ansicht die Option Zugeordnete Histogrammtypen aus) fasst die Größe der zugeordneten Objekte zusammen. Vermeiden Sie die Zuweisung von kurzlebigen Objekten, die größer als 85.000 Bytes sind. Diese Objekte werden im großen Objektheap zugeordnet und sind teurer zu sammeln. In der Ansicht Histogramm nach Größe können Sie Objekte mit der Maus auswählen und mit der rechten Maustaste klicken, um zu sehen, wer sie zugeordnet hat. Das Reduzieren von Zuordnungen ist ein iterativer Prozess von Codeänderungen und Der Profilerstellung.

    Schwellenwert: Ein Durchschnitt von 5 % oder weniger; kurzlebige Spitzen, die größer sind, sind häufig. Mittelwerte, die größer sind, sollten untersucht werden. Bei Bedarf sollte ein neuer Schwellenwert festgelegt werden.

ASP.NET Leistungsindikatoren

Leistungsindikatoren in dieser Kategorie werden nur auf 0 zurückgesetzt, wenn der w3svc-Dienst gestartet wird.

  • Anwendungsneustarts. Die Anzahl der Anwendungsneustarts. Das Erneute Erstellen der Anwendungsdomäne und das erneute Kompilieren von Seiten dauert Zeit. Daher sollten unvorhergesehene Anwendungsneustarts untersucht werden. Die Anwendungsdomäne wird entladen, wenn einer der folgenden Ereignisse auftritt:

    • Änderung von machine.config, web.configoder global.asax.
    • Änderung des Bin-Verzeichnisses oder des Inhalts der Anwendung.
    • Wenn die Anzahl der Kompilierungen (ASPX, ASCX oder ASAX) den durch <kompilieren numRecompilesBeforeAppRestart=/>angegebenen Grenzwert überschreitet.
    • Änderung des physischen Pfads eines virtuellen Verzeichnisses.
    • Änderung der Codezugriffssicherheitsrichtlinie.
    • Der Webdienst wird neu gestartet.

    Für Webfarmen in der Produktion wird empfohlen, einen Server aus der Rotation zu entfernen, bevor Inhalte aktualisiert werden, um optimale Leistung und Zuverlässigkeit zu erzielen. Für einen einzelnen Webserver in der Produktion können Inhalte aktualisiert werden, während der Server unter Last ist. Der im Knowledge Base-Artikel 810281 beschriebene Hotfix ist für alle Benutzer von Interesse, die nach dem Neustart einer Anwendung Fehler auftreten, z. B. bei der Freigabe von Verstößen mit einem Fehler ähnlich wie "Dateiname> kann nicht zugreifen<, weil es von einem anderen Prozess verwendet wird" auftreten.

    Ein Problem mit Neustarten von Antivirensoftware und Anwendungen wird im Knowledge Base-Artikel 820746: FIX: Einige Antivirenprogramme können dazu führen, dass Webanwendungen für v1.0 unerwartet neu gestartet werden, und im Knowledge Base-Artikel 821438 für v1.1 behoben.

    Schwellenwert: 0. In einer perfekten Welt wird die Anwendungsdomäne für die Lebensdauer des Prozesses überleben. Übermäßige Werte sollten untersucht und bei Bedarf ein neuer Schwellenwert festgelegt werden.

  • Ausgeführte Anwendungen. Die Anzahl der ausgeführten Anwendungen.

  • Anforderungen aktuell. Die Anzahl der Anforderungen, die derzeit vom ASP.NET ISAPI verarbeitet werden. Dies schließt diejenigen ein, die sich in der Warteschlange befinden, ausgeführt werden oder darauf warten, in den Client geschrieben zu werden. Dieser Leistungsindikator wurde zu Version 1.0 von ASP.NET im Vorab-SP3-Hotfix hinzugefügt, der im Knowledge Base-Artikel 329959 beschrieben wird.

    ASP.NET beginnt, Anforderungen abzulehnen, wenn dieser Leistungsindikator das im abschnitt processModel-Konfiguration definierte requestQueueLimit überschreitet. Beachten Sie, dass requestQueueLimit für ASP.NET in IIS 5.0 gilt, wenn sie in aspnet_wp ausgeführt wird, aber vielleicht überraschenderweise gilt es auch für IIS 6.0, wenn in w3wp ausgeführt wird. Es ist nicht bekannt, dass mehrere processModel-Konfigurationseinstellungen weiterhin gelten, wenn in IIS 6.0 ausgeführt wird. Dazu gehören requestQueueLimit, responseDeadlockInterval, maxWorkerThreads, maxIoThreads, minWorkerThreads und minIoThreads. Ein Fehler in Version 1.1 des Frameworks, der in ASP.NET 1.1- Hotfixrolluppaket vom Juni 2003 behoben wurde, ermöglichte ASP.NET, eine unbegrenzte Anzahl von Anforderungen zu verarbeiten, wenn sie in IIS 6.0 ausgeführt werden. Die Korrektur bewirkt, dass ASP.NET Anforderungen ablehnen, wenn Requests Current das requestQueueLimit überschreitet.

    Bei klassischen ASP-Anwendungen wird mit Anforderungen in die Warteschlange eine Warnung angezeigt, wenn Anforderungen abgelehnt werden. Für ASP.NET stellen Aktuelle Anforderungen zusammen mit Anforderungen in der Anwendungswarteschlange diese Funktionalität bereit. Dieser Indikator wird auch vom Mechanismus für die ASP.NET Deadlockerkennung verwendet. Wenn Requests Current größer als 0 ist und keine Antworten vom Arbeitsprozess für einen Zeitraum empfangen wurden, der den durch <processModel responseDeadlockInterval=/>angegebenen Grenzwert überschreitet, wird der Prozess beendet und ein neuer Prozess gestartet. Im Vorab-SP3-Hotfix, der im Knowledge Base-Artikel 328267 beschrieben wurde, wurde der Algorithmus so geändert, dass Anforderungen Current größer als die Summe von maxWorkerThreads plus maxIoThreads sein muss, die < im Abschnitt processModel/>configuration angegeben ist. Beachten Sie, dass das Timeout für die Anforderungsausführung standardmäßig 90 Sekunden beträgt und absichtlich kleiner als responseDeadlockInterval ist. Das Anforderungsausführungstimeout kann über die < Konfigurationseinstellung httpRuntime executionTime=/oder> die Server.ScriptTimeout-Eigenschaft geändert werden, sollte aber immer kleiner als responseDeadlockInterval sein.

  • Anforderungsausführungszeit. Die Anzahl der Millisekunden, die zum Ausführen der letzten Anforderung verbraucht wurden. In Version 1.0 des Frameworks beginnt die Ausführungszeit, wenn der Arbeitsprozess die Anforderung empfängt, und wird beendet, wenn die ASP.NET ISAPI HSE_REQ_DONE_WITH_SESSION an IIS sendet. Für IIS Version 5 umfasst dies die Zeit, die zum Schreiben der Antwort an den Client erforderlich ist, aber bei IIS Version 6 werden die Antwortpuffer asynchron gesendet, sodass die Zeit, die zum Schreiben der Antwort an den Client erforderlich ist, nicht enthalten ist. In IIS Version 5 erhöht also ein Client mit einer langsamen Netzwerkverbindung den Wert dieses Indikators erheblich.

    In Version 1.1 des Frameworks beginnt die Ausführungszeit, wenn der HttpContext für die Anforderung erstellt wird, und endet, bevor die Antwort an IIS gesendet wird. Unter der Annahme, dass der Benutzercode httpResponse.Flush nicht aufruft, bedeutet dies, dass die Ausführungszeit beendet wird, bevor Bytes an IIS oder an den Client gesendet werden.

    ASP.NET\Anforderungsausführungszeit ist ein instance Zähler und sehr flüchtig. Andererseits kann die Zeit bis zum letzten Byte (TTLB) leicht gemittelt und verwendet werden, um eine bessere Schätzung der Leistung über einen bestimmten Zeitraum zu berechnen. TTLB kann über einen einfachen HTTP-Client berechnet werden, der in verwaltetem Code geschrieben ist, oder Sie können einen der vielen verfügbaren HTTP-Clients verwenden, die TTLB berechnen, z. B. Application Center Test (ACT).

    Beachten Sie, dass die Batchkompilierung deaktiviert und die < Konfigurationseinstellung httpRuntime executionTime=/sowie Aufrufe von Server.ScriptTimeout ignoriert werden, wenn <Kompilierung debug=/>> auf TRUE festgelegt ist. Dies kann Zu Problemen führen, wenn die <Einstellung processModel responseDeadlockInterval=/> nicht auf Infinite festgelegt ist, da Anforderungen für Debugseiten theoretisch für immer ausgeführt werden können.

    Schwellenwert: N.A. Der Wert dieses Indikators sollte stabil sein. Die Erfahrung hilft dabei, einen Schwellenwert für eine bestimmte Website festzulegen. Wenn das Prozessmodell aktiviert ist, umfasst die Ausführungszeit der Anforderung die Zeit, die zum Schreiben der Antwort an den Client erforderlich ist, und hängt daher von der Bandbreite der Clientverbindung ab.

  • Anforderungen in die Warteschlange gestellt. Die Anzahl der Anforderungen, die derzeit in die Warteschlange eingereiht werden. Bei der Ausführung unter IIS 5.0 gibt es eine Warteschlange zwischen inetinfo und aspnet_wp, und es gibt eine Warteschlange für jedes virtuelle Verzeichnis. Bei der Ausführung unter IIS 6.0 gibt es eine Warteschlange, in der Anforderungen aus nativem Code an den verwalteten ThreadPool gesendet werden, und eine Warteschlange für jedes virtuelle Verzeichnis. Dieser Leistungsindikator enthält Anforderungen in allen Warteschlangen. Die Warteschlange zwischen inetinfo und aspnet_wp ist eine Named Pipe, über die die Anforderung von einem Prozess an den anderen gesendet wird. Die Anzahl der Anforderungen in dieser Warteschlange nimmt zu, wenn es im aspnet_wp Prozess zu einem Mangel an verfügbaren E/A-Threads kommt. In IIS 6.0 erhöht sich dies, wenn eingehende Anforderungen und ein Mangel an Arbeitsthreads vorhanden sind.

    Beachten Sie, dass Anforderungen abgelehnt werden, wenn der Leistungsindikator "Requests Current" den <processModel requestQueueLimit=/>-Wert überschreitet. Viele Benutzer denken, dass dies geschieht, wenn der Leistungsindikator "Anforderungen in die Warteschlange" requestQueueLimit überschreitet, aber dies ist nicht der Fall. Wenn dieser Grenzwert überschritten wird, werden Anforderungen mit dem Code 503 status und der Meldung "Server ist zu ausgelastet" abgelehnt. Wenn eine Anforderung aus diesem Grund abgelehnt wird, erreicht sie nie verwalteten Code, und Fehlerhandler werden nicht benachrichtigt. Normalerweise ist dies nur ein Problem, wenn der Server unter einer sehr hohen Last steht, obwohl auch eine Burstlast pro Stunde dies verursachen kann. Für das ungewöhnliche Burstlastszenario ist möglicherweise der im Knowledge Base-Artikel 810259 beschriebene Hotfix interessant, mit dem Sie die Mindestanzahl von E/A-Threads von 1 pro CPU erhöhen können.

    Jedes virtuelle Verzeichnis verfügt über eine Warteschlange, die verwendet wird, um die Verfügbarkeit von Worker- und E/A-Threads aufrechtzuerhalten. Die Anzahl der Anforderungen in dieser Warteschlange steigt, wenn die Anzahl der verfügbaren Arbeitsthreads oder verfügbaren E/A-Threads unter den durch <httpRuntime minFreeThreads=/>angegebenen Grenzwert fällt. Wenn der von <httpRuntime appRequestQueueLimit=/> angegebene Grenzwert überschritten wird, wird die Anforderung mit dem Code 503 status abgelehnt, und der Client empfängt eine HttpException mit der Meldung "Server zu beschäftigt".

    Dieser Indikator allein ist kein eindeutiger Indikator für Leistungsprobleme und kann auch nicht verwendet werden, um zu bestimmen, wann Anforderungen abgelehnt werden. Im Knowledge Base-Artikel 329959 wurden zwei neue Leistungsindikatoren eingeführt, um dieses Problem zu beheben: Aktuelle Anforderungen und Anforderungen in der Anwendungswarteschlange. Sehen Sie sich die Beschreibungen für diese beiden Leistungsindikatoren sowie für Abgelehnte Anforderungen an.

  • Abgelehnte Anforderungen. Die Anzahl zurückgewiesener Anforderungen. Anforderungen werden abgelehnt, wenn einer der Warteschlangengrenzwerte überschritten wird (siehe Beschreibung von Anforderungen in Warteschlange). Anforderungen können aus verschiedenen Gründen abgelehnt werden. Back-End-Latenz, wie sie durch einen langsamen SQL Server verursacht wird, geht häufig einem plötzlichen Anstieg der Anzahl von Pipelineinstanzen und einer Abnahme der CPU-Auslastung und Anforderungen/Sek. voraus. Ein Server kann in Zeiten hoher Auslastung aufgrund von Prozessor- oder Arbeitsspeichereinschränkungen überlastet sein, die letztendlich zur Ablehnung von Anforderungen führen.

    Der Entwurf einer Anwendung kann zu einer übermäßigen Anforderungsausführungszeit führen. Beispielsweise ist die Batchkompilierung ein Feature, bei dem alle Seiten in einem Verzeichnis in einer einzelnen Assembly kompiliert werden, wenn die erste Anforderung für eine Seite empfangen wird. Wenn mehrere hundert Seiten in einem Verzeichnis vorhanden sind, kann die ausführung der ersten Anforderung in diesem Verzeichnis lange dauern. Wenn <die Kompilierung batchTimeout=/> überschritten wird, wird die Batchkompilierung in einem Hintergrundthread fortgesetzt, und die angeforderte Seite wird einzeln kompiliert. Wenn die Batchkompilierung erfolgreich ist, wird die Assembly auf dem Datenträger beibehalten und kann nach einem Anwendungsneustart wiederverwendet werden. Wenn jedoch global.asax, web.config, machine.config oder eine Assembly im Ordner bin der Anwendung geändert wird, wird der Batchkompilierungsprozess aufgrund der Abhängigkeitsänderung erneut ausgeführt.

    Ein sorgfältiger Entwurf einer großen Website kann erhebliche Auswirkungen auf die Leistung haben. In diesem Fall ist es besser, nur wenige Seiten zu verwenden, die das Verhalten basierend auf Abfragezeichenfolgendaten variieren. Im Allgemeinen müssen Sie die Ausführungszeit von Anforderungen minimieren, was am besten durch die Mittelungszeit bis zum letzten Byte (TTLB) mithilfe eines HTTP-Clients überwacht wird, der mindestens eine Seite von der Website anfordert.

    Die folgenden Leistungsindikatoren eignen sich am besten, um die Ursache abgelehnter Anforderungen zu ermitteln:

    • Prozess\% Prozessorzeit
    • Prozess\Private Bytes
    • Prozess\Threadanzahl
    • Webdienst\ISAPI-Erweiterungsanforderungen/s
    • ASP.NET\Aktuelle Anforderungen
    • ASP.NET\Anforderungen in die Warteschlange
    • ASP.NET\Wartezeit anfordern
    • ASP.NET Anwendungen\Anzahl von Pipelineinstanzen
    • ASP.NET Anwendungen\Anforderungen in der Anwendungswarteschlange

    Schwellenwert: 0. Der Wert dieses Indikators sollte 0 sein. Werte, die größer sind, sollten untersucht werden.

  • Anforderungswartezeit. Die Anzahl der Millisekunden, die die letzte Anforderung in der Warteschlange oder der Named Pipe gewartet hat, die zwischen inetinfo und aspnet_wp vorhanden ist (siehe Beschreibung von Anforderungen in die Warteschlange). Dies schließt keine Wartezeit in den Anwendungswarteschlangen ein.

    Schwellenwert: 1000. Die durchschnittliche Anforderung sollte 0 Millisekunden in der Warteschlange warten.

  • Workerprozesse werden ausgeführt. Die aktuelle Anzahl von aspnet_wp Workerprozessen. Für einen kurzen Zeitraum können ein neuer Workerprozess und der ersetzte Arbeitsprozess nebeneinander existieren. Obwohl selten, verarbeitet manchmal Deadlocks, während sie beenden. Wenn Sie dies vermuten, sollten Sie ein Tool verwenden, um die Anzahl der Instanzen des Workerprozesses zu überwachen. Alternativ kann der Leistungsindikator Arbeitsspeicher\Verfügbare MBytes verwendet werden, da diese hängenden Prozesse Arbeitsspeicher beanspruchen.

    Schwellenwert: 2. Beim Herunterfahren des vorherigen Workerprozesses kann es zwei Instanzen geben. Wenn webGarden aktiviert ist, sollte der Schwellenwert #CPUs plus 1 liegen. Werte, die größer sind, können auf übermäßige Prozessneustarts innerhalb eines sehr kurzen Zeitraums hinweisen.

  • Der Workerprozess wird neu gestartet. Die Anzahl aspnet_wp Prozessneustarts.

    Schwellenwert: 1. Prozessneustarts sind teuer und unerwünscht. Werte sind abhängig von den Konfigurationseinstellungen des Prozessmodells sowie unvorhergesehenen Zugriffsverletzungen, Speicherverlusten und Deadlocks. Wenn aspnet_wp neu gestartet wird, gibt ein Anwendungsereignisprotokolleintrag an, warum. Anforderungen gehen verloren, wenn eine Zugriffsverletzung oder ein Deadlock auftritt. Wenn Prozessmodelleinstellungen verwendet werden, um den Prozess vorzeitig zu recyceln, muss ein entsprechender Schwellenwert festgelegt werden.

ASP.NET Anwendungsindikatoren

Die Leistungsindikatoren in dieser Kategorie werden auf 0 zurückgesetzt, wenn entweder die Anwendungsdomäne oder der Webdienst neu gestartet wird.

  • Zwischenspeichern gesamter Einträge. Die aktuelle Anzahl von Einträgen im Cache (sowohl User als auch Internal). Intern verwendet ASP.NET den Cache zum Speichern von Objekten, die teuer zu erstellen sind, einschließlich Konfigurationsobjekten, beibehaltenen Assemblyeinträgen, Pfaden, die von der MapPath-Methode zugeordnet werden, und In-Process-Sitzungsstatusobjekte.

    Hinweis Die Familie der Leistungsindikatoren "Cache Total" ist nützlich für die Diagnose von Problemen mit dem Sitzungsstatus während des Prozesses. Das Speichern von zu vielen Objekten im Cache ist häufig die Ursache von Speicherverlusten.

  • Cache-Trefferquote insgesamt. Das Treffer-zu-Miss-Verhältnis aller Cacheanforderungen (sowohl benutzerseitig als auch intern).

  • Gesamtumsatzrate zwischenspeichern. Die Anzahl der Ergänzungen und Entfernungen in den Cache pro Sekunde (sowohl benutzerseitig als auch intern). Eine hohe Fluktuationsrate deutet darauf hin, dass Artikel schnell hinzugefügt und entfernt werden, was teuer sein kann.

  • Zwischenspeichern von API-Einträgen Die Anzahl der Einträge, die sich derzeit im Benutzercache befinden.

  • Cache-API-Trefferquote. Das Treffer-zu-Fehl-Gesamtverhältnis von Benutzercacheanforderungen.

  • Cache-API-Fluktuationsrate. Die Anzahl der Ergänzungen und Entfernungen zum Benutzercache pro Sekunde. Eine hohe Fluktuationsrate deutet darauf hin, dass Artikel schnell hinzugefügt und entfernt werden, was teuer sein kann.

  • Ausgabecacheeinträge. Die Anzahl der Einträge, die derzeit im Ausgabecache enthalten sind.

  • Trefferverhältnis des Ausgabecaches. Das Treffer-zu-Miss-Verhältnis der Ausgabecacheanforderungen insgesamt.

  • Fluktuationsrate des Ausgabecaches. Die Anzahl der Ergänzungen und Entfernungen zum Ausgabecache pro Sekunde. Eine hohe Fluktuationsrate deutet darauf hin, dass Artikel schnell hinzugefügt und entfernt werden, was teuer sein kann.

  • Anzahl der Pipelineinstanzen. Die Anzahl der aktiven Pipelineinstanzen. Nur ein Ausführungsthread kann innerhalb einer Pipeline instance ausgeführt werden, sodass diese Zahl die maximale Anzahl gleichzeitiger Anforderungen angibt, die für eine bestimmte Anwendung verarbeitet werden. Die Anzahl der Pipelineinstanzen sollte konstant sein. Plötzliche Erhöhungen deuten auf die Back-End-Latenz hin (siehe die Beschreibung von Abgelehnten Anforderungen oben).

  • Kompilierungen Insgesamt. Die Anzahl der ASAX-, ASCX-, ASHX-, ASPX- oder ASMX-Dateien, die kompiliert wurden. Dies ist die Anzahl der kompilierten Dateien, nicht die Anzahl der generierten Assemblys. Assemblys werden auf dem Datenträger beibehalten und wiederverwendet, bis sich die Erstellungszeit, die letzte Schreibzeit oder die Länge einer Dateiabhängigkeit ändert. Zu den Abhängigkeiten einer ASPX-Seite gehören global.asax, web.config, machine.config, abhängige Assemblys im Ordner bin und ASCX-Dateien, auf die die Seite verweist. Wenn Sie die Anwendung neu starten, ohne eine der Dateiabhängigkeiten zu ändern, wird die beibehaltene Assembly ohne Kompilierung neu geladen. Dieser Leistungsindikator erhöht sich nur, wenn eine Datei zunächst analysiert und in eine Assembly kompiliert wird.

    Standardmäßig ist die Batchkompilierung aktiviert. Dieser Leistungsindikator erhöht sich jedoch einmal für jede Datei, die analysiert und in eine Assembly kompiliert wird, unabhängig davon, wie viele Assemblys erstellt werden.

    Wenn die Kompilierung fehlschlägt, wird der Zähler nicht erhöht.

  • Fehler während der Vorverarbeitung. Die Gesamtanzahl von Konfigurations- und Analysefehlern. Dieser Indikator wird jedes Mal erhöht, wenn ein Konfigurations- oder Analysefehler auftritt. Auch wenn Konfigurationsfehler zwischengespeichert werden, erhöht der Zähler jedes Mal, wenn der Fehler auftritt.

    Hinweis Verlassen Sie sich nicht ausschließlich auf die Leistungsindikatoren "Fehler", um zu ermitteln, ob der Server fehlerfrei ist. Sie werden auf Null zurückgesetzt, wenn die AppDomain entladen wird. Sie können jedoch verwendet werden, um ein bestimmtes Problem genauer zu untersuchen. Verwenden Sie im Allgemeinen das Application_Error-Ereignis , um Administratoren auf Probleme hinzuweisen.

  • Fehler während der Kompilierung. Die Gesamtzahl der Kompilierungsfehler. Die Antwort wird zwischengespeichert, und dieser Zähler erhöht sich nur einmal, bis die Neukompilierung durch eine Dateiänderung erzwungen wird. Implementieren Sie benutzerdefinierte Fehlerbehandlung, um ein Ereignis auszulösen.

  • Fehler während der Ausführung. Die Gesamtanzahl der Laufzeitfehler.

  • Fehler, die während der Ausführung nicht behandelt werden. Die Gesamtzahl der nicht behandelten Ausnahmen zur Laufzeit. Dies umfasst nicht Folgendes:

    1. Fehler, die von einem Ereignishandler gelöscht werden (z. B. durch Page_Error oder Application_Error).
    2. Fehler, die von einer Umleitungsseite behandelt werden.
    3. Fehler, die innerhalb eines Try/Catch-Blocks auftreten.

  • Fehler, die während der Ausführung/Sek. nicht behandelt werden. Die Gesamtzahl der nicht behandelten Ausnahmen pro Sekunde zur Laufzeit.

  • Fehler gesamt. Die Summe der Fehler während der Vorverarbeitung, Fehler während der Kompilierung und Fehler während der Ausführung.

  • Fehler Gesamt/Sek. Die Summe der Fehler während der Vorverarbeitung, Fehler während der Kompilierung und Fehler während der Ausführung pro Sekunde.

  • Anforderungen werden ausgeführt. Die Anzahl der derzeit ausgeführten Anforderungen. Dieser Leistungsindikator wird erhöht, wenn httpRuntime beginnt, die Anforderung zu verarbeiten, und wird dekrementiert, nachdem die HttpRuntime die Anforderung abgeschlossen hat. In Version 1.1 des Frameworks gibt es einen Fehler in diesem Leistungsindikator, der im ASP.NET 1.1 Juni 2003 Hotfix-Rolluppaket behoben wird. Leider wird der Fehler nicht im Knowledge Base-Artikel beschrieben. Vor dem Fix enthielt der Indikator die Zeit, die zum Schreiben der Antwort an den Client benötigte.

  • Anforderungen in der Anwendungswarteschlange. Die Anzahl der Anforderungen in der Anwendungsanforderungswarteschlange (siehe Beschreibung von Anforderungen in Warteschlange oben). Zusätzlich zu aktuellen Anforderungen enthält Die Anforderungen in der Anwendungswarteschlange eine Warnung, wenn Anforderungen abgelehnt werden. Wenn nur einige virtuelle Verzeichnisse vorhanden sind, kann die Erhöhung des Standardlimits appRequestQueueLimit auf 200 oder 300 geeignet sein, insbesondere für langsame Anwendungen unter hoher Last.

  • Anforderungen wurden nicht gefunden. Die Anzahl der Anforderungen für nicht gefundene Ressourcen.

  • Anforderungen nicht autorisiert. Die Anzahl der Anforderungen ist aufgrund eines nicht autorisierten Zugriffs fehlgeschlagen.

  • Timeout für Anforderungen. Die Anzahl der Anforderungen, für die ein Timeout aufgetreten ist.

  • Anforderungen erfolgreich. Die Anzahl der Anforderungen, die erfolgreich ausgeführt wurden.

  • Anforderungen gesamt. Die Anzahl der Anforderungen seit dem Start der Anwendung.

  • Anforderungen/Sek. Die Anzahl der pro Sekunde ausgeführten Anforderungen. Ich bevorzuge "Webdienst\ISAPI-Erweiterungsanforderungen/s", da es nicht von Anwendungsneustarts betroffen ist.

Prozessindikatoren

Mit diesen Indikatoren werden die prozesse von Interesse aspnet_wp und inetinfo.

  • Prozessorzeit in %. Der Prozentsatz der Zeit, die die Threads dieses Prozesses mit den Prozessoren verbringen.

    Schwellenwert: 70 %. Werte, die über einen längeren Zeitraum größer sind, weisen auf die Notwendigkeit hin, Hardware zu erwerben oder Ihre Anwendung zu optimieren.

  • Handle Count.

    Schwellenwert: 10000. Eine Griffanzahl von 2000 in aspnet_wp ist verdächtig, und 10.000 ist weit über die zulässigen Grenzen hinaus. Eine spürbare Leistungsminderung tritt auf, wenn die Gesamthandleanzahl für alle Prozesse ungefähr 40.000 überschreitet, was bei einem Denial-of-Service-Angriff gegen IIS vollständig erreichbar ist.

  • Private Bytes. Die aktuelle Größe des zugesicherten Arbeitsspeichers in Bytes, der diesem Prozess gehört. Speicherverluste werden durch eine konsistente und anhaltende Zunahme privater Bytes identifiziert. Dies ist der beste Leistungsindikator zum Erkennen von Speicherverlusten.

    Bei der Ausführung unter IIS 5.0 sollte im <Abschnitt processModel memoryLimit=/> configuration ein Arbeitsspeicherlimit für private Bytes festgelegt werden. Bei der Ausführung unter IIS 6.0 sollte das Arbeitsspeicherlimit im IIS-Manager festgelegt werden. Öffnen Sie Eigenschaften für den Anwendungspool, und geben Sie auf der Registerkarte Recycling einen Grenzwert für den maximal verwendeten Arbeitsspeicher (in Megabyte) an. Dieser Grenzwert entspricht private Bytes. Private Bytes für den Workerprozess werden mit dem Arbeitsspeicherlimit verglichen, um zu bestimmen, wann der Prozess wiederverwendet werden soll. System.Web.Caching.Cache verwendet auch private Bytes und das Arbeitsspeicherlimit, um zu bestimmen, wann Elemente aus dem Cache entfernt werden sollen, und so das Recycling des Prozesses zu vermeiden. Ein Arbeitsspeicherlimit von 60 % des physischen RAM wird empfohlen, um Paging zu vermeiden, insbesondere wenn ein neuer Prozess den alten aufgrund übermäßigen Arbeitsspeicherverbrauchs ersetzt. Beachten Sie, dass der Knowledge Base-Artikel 330469 ein Problem mit ASP.NET behebt, bei dem private Bytes auf Servern mit einer großen Anzahl ausgeführter Prozesse nicht überwacht werden können. Dieser Hotfix ermöglicht es auch, dass der Cachespeicher-Manager ordnungsgemäß funktioniert, wenn eine große Anzahl von ausgeführten Prozessen vorhanden ist.

    Es ist wichtig, das Arbeitsspeicherlimit auf Computern mit großem physischem RAM so anzupassen, dass der Cachespeicher-Manager und das Prozessrecycling ordnungsgemäß funktionieren. Angenommen, Sie verfügen über einen Server mit 4 GB physischem RAM, der das Standardspeicherlimit verwendet. Das ist ein Problem. Sechzig Prozent des physischen RAM ist 2,4 GB und damit größer als der standardmäßige virtuelle Adressraum von 2 GB. Auf was sollte also das Speicherlimit festgelegt werden?

    Es gibt einige Dinge zu beachten: Erstens steigt die Wahrscheinlichkeit einer OutOfMemoryException dramatisch, wenn "Process\Virtual Bytes" innerhalb von 600 MB des Grenzwerts für den virtuellen Adressraum liegt (in der Regel 2 GB), und zweitens haben Tests gezeigt, dass "Process\Virtual Bytes" oft größer ist als "Process\Private Bytes" um nicht mehr als 600 MB. Dieser Unterschied ist zum Teil auf die MEM_RESERVE Regionen zurückzuführen, die vom GC verwaltet werden, sodass er bei Bedarf schnell mehr Arbeitsspeicher commiten kann. Zusammengenommen bedeutet dies, dass die Wahrscheinlichkeit einer OutOfMemoryException steigt, wenn "Process\Private Bytes" 800 MB überschreitet. In diesem Beispiel verfügt der Computer über 4 GB physischen RAM, sodass Sie das Arbeitsspeicherlimit auf 20 % festlegen müssen, um Nicht-Arbeitsspeicher-Bedingungen zu vermeiden. Sie können mit diesen Zahlen experimentieren, um die Auslastung des Arbeitsspeichers auf einem Computer zu maximieren. Wenn Sie jedoch auf Nummer sicher gehen möchten, funktionieren die Zahlen im Beispiel.

    Legen Sie zusammenfassend das Arbeitsspeicherlimit auf den kleineren wert von 60 % des physischen RAM oder 800 MB fest. Da v1.1 3 GB virtuellen Adressraum unterstützt, können Sie beim Hinzufügen von /3GB zu boot.ini sicher 1.800 MB anstelle von 800 MB als Obergrenze verwenden.

    Beachten Sie, dass Sie system.GC.GetTotalMemory(true) einmal aufrufen können, wenn Sie beim Ausführen von Tests eine Gc-Instanz erzwingen und den verwalteten Arbeitsspeicher stabilisieren möchten. Diese Methode ruft GC auf. Collect und WaitForPendingFinalizers() wiederholt, bis sich der Arbeitsspeicher innerhalb von 5 % stabilisiert.

    Schwellenwert: Mindestens 60 % des physischen RAM und 800 MB. Werte, die größer als 60 % des gesamten physischen RAM sind, wirken sich insbesondere bei Anwendungs- und Prozessneustarts auf die Leistung aus. Die Liklihood einer OutOfMemoryException erhöht sich erheblich, wenn private Bytes in einem Prozess mit einem Grenzwert für den virtuellen Adressraum von 2 GB 800 MB überschreiten.

  • Threadanzahl. Die Anzahl der in diesem Prozess aktiven Threads. Die Threadanzahl steigt häufig, wenn die Last zu hoch ist.

    Schwellenwert: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs). Der Schwellenwert sollte erhöht werden, wenn der aspcompat-Modus verwendet wird: Schwellenwert: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs * 2).

  • Virtuelle Bytes. Die aktuelle Größe des virtuellen Adressraums für diesen Prozess in Bytes.

    Der Grenzwert für den virtuellen Adressraum eines Benutzermodusprozesses beträgt 2 GB, es sei denn, 3 GB Adressraum wird mithilfe des Schalters /3GB in boot.ini aktiviert. Die Leistung nimmt ab, wenn diese Grenze erreicht wird, und führt in der Regel zu einem Prozess- oder Systemabsturz. Der Adressraum wird fragmentiert, wenn der Grenzwert von 2 GB oder 3 GB erreicht wird. Daher empfehle ich einen konservativen Schwellenwert von 1,4 bzw. 2,4 GB. Wenn hier Probleme auftreten, wird System.OutOfMemoryException ausgelöst, und dies kann den Prozess abstürzen oder nicht.

    Bei der Ausführung unter IIS 6.0 kann im IIS-Manager ein Grenzwert für den virtuellen Arbeitsspeicher festgelegt werden. Wenn Sie dies jedoch nicht ordnungsgemäß festlegen, kann dies zu Problemen bei ASP.NET führen. ASP.NET Elemente aus dem Cache entfernt, um eine Überschreitung des Grenzwerts für private Bytes zu vermeiden, aber der Algorithmus verwendet bei dieser Bestimmung private Bytes und den Grenzwert für private Bytes. Es überwacht weder virtuelle Bytes noch den Grenzwert für virtuelle Bytes. Da der Unterschied zwischen virtuellen Bytes und privaten Bytes in der Regel nicht mehr als 600 MB beträgt, können Sie den Grenzwert für virtuelle Bytes auf einen Wert von 600 MB höher als den Grenzwert für private Bytes festlegen, wenn Sie sich Gedanken über die Möglichkeit von Lecks oder Fragmentierung des virtuellen Speichers machen. Wenn dies wünschenswert ist, legen Sie einen Grenzwert für den maximalen virtuellen Arbeitsspeicher (in Megabyte) fest, der auf der Registerkarte Recycling für die Eigenschaften des Anwendungspools gefunden wird.

    Version 1.0 des Frameworks unterstützt keinen Adressraum von 3 GB im Workerprozess oder im Zustandsdienst. Anweisungen zum Aktivieren von 3 GB Adressraum innerhalb inetinfo.exe finden Sie jedoch im Knowledge Base-Artikel 320353. Version 1.1 unterstützt vollständig 3 GB Adressraum für den Workerprozess und den Zustandsdienst.

    Schwellenwert: 600 MB kleiner als die Größe des virtuellen Adressraums; entweder 1,4 oder 2,4 GB.

Prozessorindikator

  • Prozessorzeit in %. Der Prozentsatz der Zeit, die alle Threads mit den Prozessoren verbringen.

    Schwellenwert: 70 %. Werte, die über einen längeren Zeitraum größer sind, weisen auf die Notwendigkeit hin, Hardware zu erwerben oder Ihre Anwendung zu optimieren.

Speicherindikator

  • Verfügbare MB. Die Menge des verfügbaren physischen RAM.

    Schwellenwert: 20 % des physischen RAM. Werte, die kleiner als diese sind, sollten untersucht werden und können darauf hindeuten, dass Hardware erworben werden muss.

Systemzähler

  • Kontextwechsel/Sekunde. Die Rate, mit der die Prozessoren threadkontexte wechseln. Eine hohe Zahl kann auf hohe Sperrenkonflikte oder Übergänge zwischen Benutzer- und Kernelmodus hinweisen. Kontextswitches/Sekunde sollten linear mit Durchsatz, Auslastung und der Anzahl der CPUs erhöht werden. Wenn sie exponentiell zunimmt, liegt ein Problem vor. Für weitere Untersuchungen sollte ein Profiler verwendet werden.

Webdienstzähler

  • Aktuelle Verbindungen. Ein Schwellenwert für diesen Leistungsindikator hängt von vielen Variablen ab, z. B. vom Typ der Anforderungen (ISAPI, CGI, statischem HTML usw.), der CPU-Auslastung usw. Eine Schwelle sollte durch Erfahrung entwickelt werden.
  • Gesamtzahl der Methodenanforderungen/Sekunde. Wird hauptsächlich als Metrik zur Diagnose von Leistungsproblemen verwendet. Es kann interessant sein, dies mit "ASP.NET Applications\Requests/sec" und "Webdienst\ISAPI-Erweiterungsanforderungen/Sekunde" zu vergleichen, um den Prozentsatz der bereitgestellten statischen Seiten im Vergleich zu Seiten anzuzeigen, die von aspnet_isapi.dll gerendert werden.
  • ISAPI-Erweiterungsanforderungen/s. Wird hauptsächlich als Metrik zur Diagnose von Leistungsproblemen verwendet. Es kann interessant sein, dies mit "ASP.NET Applications\Requests/sec" und "Webdienst\Total Method Requests/s" zu vergleichen. Beachten Sie, dass dies Anforderungen an alle ISAPI-Erweiterungen umfasst, nicht nur an aspnet_isapi.dll.

Zusammenfassung

Sorgfältige Belastungs- und Leistungstests einer Anwendung vor dem Live-Schalten können große Kopfschmerzen verhindern. Es scheint zwei große Stolpersteine zu geben, auf die viele Menschen stoßen:

  1. Sie müssen einen HTTP-Client verwenden, der den Datenverkehr und die Last simulieren kann, die von der Website erwartet wird.
  2. Sie müssen die gesamte Anwendung in einer Umgebung testen, die nahezu identisch mit der Produktionsumgebung ist.

Es ist nicht einfach, echten Websitedatenverkehr zu simulieren, aber ich kann ehrlich sagen, dass die meisten Anwendungen, die Probleme haben, nie ausreichend stressgeprüft wurden. Dieser Artikel soll Ihnen helfen, Leistungsindikatoren zu verstehen und einige nützliche Tools zum Überwachen der Leistung zu erstellen. Um die Last anzuwenden, empfehle ich Microsoft Application Center Test (ACT), der in Microsoft® Visual Studio® .NET enthalten ist. Weitere Informationen zu diesem Belastungstool finden Sie unter Microsoft Application Center Test 1.0, Visual Studio .NET Edition. Ich empfehle auch das Microsoft® Web Application Stress Tool (WAST). Dieser kann kostenlos von TechNet heruntergeladen werden. Wenn Ihre Anwendung ViewState verwendet, müssen Sie ACT verwenden, da WAST die Antwort nicht dynamisch analysieren kann.

Ich weiß nicht, was es mit Produktionsumgebungen auf sich hat, aber es gibt definitiv etwas Besonderes an ihnen. Ich kann nicht zählen, wie oft ich die Aussage gehört habe: "Das Problem tritt nur auf unserem Produktionsstandort auf." In der Regel ist der Unterschied die Anwendung selbst. Häufig gibt es einen Teil der Anwendung, der im Lab nicht simuliert werden kann. Beispielsweise wurde der Anzeigenserver beim Testen ausgelassen, oder die Datenbank, die zum Simulieren der realen Datenbank verwendet wird, unterscheidet sich erheblich. Manchmal sind Netzwerk- oder DNS-Unterschiede die Ursache, manchmal ist es ein Unterschied in der Hardware, auf der die Server ausgeführt werden.

Ich debuge und überwachte die Leistung von ASP.NET Anwendungen seit mehreren Jahren, aber es gibt immer noch Zeiten, in denen ich Hilfe benötige. Wenn Sie sich in dieser Position befinden, sind die Foren auf der ASP.NET Website ein guter Ort für Antworten. Wenn Sie sich jedoch wirklich in einer Bindung befinden, zögern Sie nicht, den Microsoft-Produktsupport mithilfe der auf dieser Website bereitgestellten Kontaktinformationen zu kontaktieren. Beachten Sie, dass Ihnen dieser Vorfall nicht in Rechnung gestellt wird, wenn microsoft ein Problem als Ergebnis eines Fehlers in einem Microsoft-Produkt feststellt.

Hoffentlich hat dieses Dokument Sie mit den Tools und Informationen ausgestattet, die Sie benötigen, um die Zuverlässigkeit und Leistung Ihrer Anwendung sicherzustellen. Wenn Sie Fragen haben, posten Sie sie auf ASP.NET Web , und ich werde mein Bestes tun, um sie zu beantworten. Viel Glück!

Zum Autor

Thomas Marquardt ist Entwickler im ASP.NET Team bei Microsoft. Seit Winter 2000 debuggen und untersuchen er Leistungsprobleme mit ASP.NET Anwendungen. Thomas bedankt sich bei Dmitry Robsman, dem Entwicklungsleiter für ASP.NET bei Microsoft, für die stunden- und stundenübergreifende Hilfe und Anleitung im Laufe der Jahre.

© Microsoft Corporation. Alle Rechte vorbehalten.