Übersicht über die Leistung

Artikel
10/22/2014

Aktualisiert: November 2007

Die Leistung ist ein wichtiger Faktor für den Erfolg einer Website oder eines Projekts. Das folgende Thema beinhaltet Richtlinien zur Verbesserung der Leistung einer Site sowie Links zur Dokumentation über optimale Vorgehensweisen.

Dieses Thema enthält folgende Abschnitte:

Optimale Vorgehensweisen
Background
Codebeispiele

Optimale Vorgehensweisen

Die folgende Liste bietet Links zu Ressourcen auf der Microsoft-Website, in denen optimale Vorgehensweisen zur Verbesserung der Leistung von ASP.NET-Websites erläutert werden.

Zurück nach oben

Background

In diesem Abschnitt werden Techniken vorgestellt, mit deren Hilfe Sie die Leistung von ASP.NET-Webanwendungen maximieren können. Die Richtlinien sind in folgende Abschnitte unterteilt:

Verarbeitung von Seiten und Serversteuerelementen
Zustandsverwaltung
Datenzugriff
Webanwendungen
Codierungstechniken

Verarbeitung von Seiten und Serversteuerelementen

In den folgenden Richtlinien werden Möglichkeiten präsentiert, die Arbeit mit ASP.NET-Seiten und -Steuerelementen besonders effizient zu gestalten.

Vermeiden Sie unnötige Serverschleifen (Roundtrips): Sie können in bestimmten Situationen ASP.NET-AJAX und das Teilrendering von Seiten verwenden, um Aufgaben im Browsercode ohne ein vollständiges Postback auszuführen. Die Features von ASP.NET-AJAX ermöglichen Ihnen beispielsweise, Benutzereingaben im Browser zu validieren, bevor diese an den Server übergeben werden. Weitere Informationen finden Sie unter Übersicht über ASP.NET-AJAX und unter Übersicht über das Teilrendering von Seiten.
Grundsätzlich gilt: Sofern Sie keine Informationen an den Server weiterleiten müssen, um sie zu überprüfen oder in einen Datenspeicher zu schreiben, können Sie die Leistung (und damit die Benutzfreundlichkeit) der Seite verbessern, indem Sie Roundtrips zum Server vermeiden.
Bei der Entwicklung benutzerdefinierter Serversteuerelemente sollten Sie diese so konzipieren, dass für einen Teil der Funktionen ein Clientskript gerendert wird. Hierdurch kann die Häufigkeit, mit der Informationen an den Webserver gesendet werden, drastisch reduziert werden. Weitere Informationen finden Sie unter Entwickeln von benutzerdefinierten ASP.NET-Serversteuerelementen und unter Erstellen von benutzerdefiniertem Clientskript mithilfe der Microsoft AJAX-Bibliothek.
Verwenden Sie die IsPostBack-Eigenschaft eines Seitenobjekts, um unnötige Verarbeitungsvorgänge zu vermeiden: Vermeiden Sie die Ausführung von Code bei jedem Postback, wenn dieser nur beim ersten Rendern der Seite ausgeführt werden muss. Prüfen Sie die IsPostBack-Eigenschaft, um Code bedingt auszuführen, d. h. abhängig davon, ob die Seite als Reaktion auf ein Serversteuerelementereignis ausgeführt wird.
Lassen Sie die Pufferung aktiviert, sofern es keinen bestimmten Grund gibt, sie zu deaktivieren: Die Leistung von ASP.NET-Webseiten wird durch das Deaktivieren der Pufferung erheblich beeinträchtigt. Weitere Informationen finden Sie in den Ausführungen zur Buffer-Eigenschaft.
Verwenden Sie die Transfer-Methode des Server**-Objekts oder das seitenübergreifende Senden von Daten, um ASP.NET-Seiten in der gleichen Anwendung umzuleiten.**Weitere Informationen finden Sie unter Umleiten von Benutzern auf eine andere Seite.

Zustandsverwaltung

In den folgenden Richtlinien werden Möglichkeiten vorgeschlagen, die Zustandsverwaltung effizient zu gestalten.

Speichern Sie den Ansichtszustand von Serversteuerelementen nur, wenn dies notwendig ist: Der Ansichtszustand ermöglicht Ihnen, Eigenschaftenwerte bei einem Roundtrip neu aufzufüllen, ohne dass Sie Code schreiben müssen. Dies wirkt sich jedoch auf die Leistung und Seitengröße aus, da der Ansichtszustand in einem ausgeblendeten Formularfeld vom Server empfangen und gesendet wird. Wenn Sie ein Serversteuerelement bei jedem Roundtrip an Daten binden, bringt der gespeicherte Ansichtszustand keinen Nutzen, da die Werte des Steuerelements während der Datenbindung durch neue Werte ersetzt werden. In diesem Fall wird durch Deaktivieren des Ansichtszustands Verarbeitungszeit gespart und die Größe der Seite reduziert.

Der Ansichtszustand ist standardmäßig für alle Serversteuerelemente aktiviert. Um ihn für ein Steuerelement zu deaktivieren, legen Sie die EnableViewState-Eigenschaft des Steuerelements auf false fest, wie im folgenden Beispiel dargestellt:

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

Mithilfe der @ Page-Direktive kann der Ansichtszustand auch für eine Seite deaktiviert werden, wie im folgenden Beispiel dargestellt:

<%@ Page EnableViewState="false" %>

Dies ist nützlich, wenn für die Seite keine Postbackverarbeitung erforderlich ist.

Hinweis:
Das EnableViewState-Attribut wird auch in der @ Control-Direktive unterstützt, und Sie können mit ihm festlegen, ob der Ansichtszustand für ein Benutzersteuerelement aktiviert ist.

Um die Größe des Ansichtszustands für eine Seite zu analysieren, aktivieren Sie die Ablaufverfolgung für die Seite, indem Sie die @ Page-Direktive auf trace="true" festlegen. Überprüfen Sie in der Ablaufverfolgungsausgabe in der Tabelle Steuerungshierarchie die Spalte Viewstate. Weitere Informationen hierzu finden Sie unter Übersicht über die ASP.NET-Ablaufverfolgung.

Verschlüsseln Sie den Ansichtszustand nur, wenn dies erforderlich ist: Die Verschlüsselung des Ansichtszustands verhindert, dass Benutzer Ansichtszustandswerte im ausgeblendeten Formularfeld lesen können. Sie können den Ansichtszustand beispielsweise verschlüsseln, wenn eine Seite ein GridView-Steuerelement mit einem Bezeichnerfeld in der DataKeyNames-Eigenschaft enthält, um die Aktualisierung von Datensätzen zu koordinieren. Da der Bezeichner für Benutzer nicht sichtbar sein soll, können Sie den Ansichtszustand verschlüsseln. Die Verschlüsselung führt jedoch zu konstanten Leistungseinbußen bei der Initialisierung und zu weiteren Leistungseinbußen, die vom Umfang des verschlüsselten Ansichtszustands abhängen. Die Verschlüsselung wird bei jedem Laden der Seite ausgeführt. Daher treten sowohl beim ersten Aufruf der Seite als auch bei jedem Postback die gleichen Leistungseinbußen auf.

Deaktivieren Sie den Sitzungszustand, wenn dieser nicht verwendet wird: Legen Sie zum Deaktivieren des Sitzungszustands für eine Seite das EnableSessionState-Attribut in der @ Page-Direktive auf false fest, wie im folgenden Beispiel dargestellt:

<%@ Page EnableSessionState="false" %>

Hinweis:
Wenn eine Seite Zugriff auf Sitzungsvariablen benötigt, diese aber nicht erstellen oder ändern muss, legen Sie das EnableSessionState-Attribut in der @ Page-Direktive auf ReadOnly fest.

Der Sitzungszustand kann auch für ASP.NET-Webdienstmethoden deaktiviert werden. Weitere Informationen hierzu finden Sie unter Übersicht über die ASP.NET-Anwendungsdienste.

Um den Sitzungszustand für eine Anwendung zu deaktivieren, legen Sie im SessionState-Abschnitt der Datei Web.config der Anwendung das Mode-Attribut auf Off fest, wie im folgenden Beispiel gezeigt:

<sessionState mode="Off" />

Wählen Sie den geeigneten Sitzungszustandsanbieter für Ihre Anwendung aus: ASP.NET bietet verschiedene Möglichkeiten, die Sitzungsdaten für Ihre Anwendung zu speichern. Hierzu zählen der prozessinterne Sitzungszustand, der prozessexterne Sitzungszustand als Windows-Dienst und der prozessexterne Sitzungszustand in einer SQL Server-Datenbank. (Sie können auch einen benutzerdefinierten Sitzungszustandsanbieter erstellen, um Sitzungsdaten in einem Datenspeicher Ihrer Wahl zu speichern.) Jeder dieser Ansätze hat bestimmte Vorteile, der prozessinterne Sitzungszustand bietet jedoch mit Abstand die höchste Geschwindigkeit. Verwenden Sie den prozessinternen Anbieter, wenn Sie den Sitzungszustand lediglich für geringe Datenmengen verwenden. Die Optionen für den prozessexternen Sitzungszustand eignen sich, wenn die Anwendung auf mehrere Prozessoren oder Computer skaliert wird oder wenn Sie Sitzungsdaten bei einem Neustart eines Servers oder Prozesses beibehalten möchten. Weitere Informationen hierzu finden Sie unter Übersicht über den ASP.NET-Sitzungszustand.

Datenzugriff

In den folgenden Richtlinien werden Möglichkeiten vorgeschlagen, den Datenzugriff in der Anwendung effizient zu gestalten.

Verwenden Sie SQL Server und gespeicherte Prozeduren für den Datenzugriff: SQL Server ist die bevorzugte Datenspeichermethode, wenn Sie leistungsfähige, skalierbare Webanwendungen entwickeln möchten. Bei Verwendung des verwalteten Anbieters für SQL Server sollten Sie nach Möglichkeit kompilierte gespeicherte Prozeduren anstelle von SQL-Befehlen verwenden, um eine zusätzliche Leistungssteigerung zu erzielen. Weitere Informationen finden Sie unter Konfigurieren von Parametern und Parameterdatentypen (ADO.NET).
Verwenden Sie die SqlDataReader-Klasse für einen schnellen Vorwärtsdatencursor: Die SqlDataReader-Klasse erzeugt einen schreibgeschützten Vorwärtsdatenstream, der aus einer SQL Server-Datenbank abgerufen wird. Die SqlDataReader-Klasse verwendet das systemeigene SQL Server-Format für die Netzwerkdatenübertragung, um Daten direkt über eine Datenbankverbindung zu lesen. Verwenden Sie nach Möglichkeit die SqlDataReader-Klasse, da diese eine höhere Leistung bietet als die DataSet-Klasse. Beispielsweise wird beim Binden eines Datensteuerelements an das SqlDataSource-Steuerelement die Leistung verbessert, wenn Sie die DataSourceMode-Eigenschaft auf DataReader festlegen. (Ein Datenreader unterstützt jedoch weniger Funktionen als der DataSet-Modus.) Die SqlDataReader-Klasse implementiert die IEnumerable-Schnittstelle, mit deren Hilfe Serversteuerelemente gebunden werden können. Weitere Informationen finden Sie in den Ausführungen zur SqlDataReader-Klasse und unter Zugreifen auf Daten mit ASP.NET.
Daten und Seitenausgaben sollten, falls möglich, zwischengespeichert werden: Verwenden Sie die ASP.NET-Zwischenspeicherung, wenn Seiten oder Daten für jede Seitenanforderung dynamisch berechnet werden müssen. Entwerfen Sie Seiten- und Datenanforderungen nach Möglichkeit mit Zwischenspeicherung, insbesondere wenn mit hohem Datenverkehr zu rechnen ist. Die richtige Verwendung des Zwischenspeichers kann mehr als alle anderen .NET Framework-Features zur Optimierung der Leistung einer Site beitragen.

Beachten Sie bei Verwendung der ASP.NET-Zwischenspeicherung die folgenden Richtlinien. Es sollten nicht zu viele Elemente zwischengespeichert werden, da jedes zwischengespeicherte Element Serverspeicher beansprucht. Elemente, die auf einfache Weise neu berechnet werden können oder die selten verwendet werden, sollten beispielsweise nicht zwischengespeichert werden. Weiterhin sollten Sie zwischengespeicherten Elementen keine kurze Ablaufzeit zuweisen. Elemente mit kurzer Ablaufzeit können einen höheren Arbeitsaufwand für den Bereinigungscode und den Garbage Collector zur Folge haben. Die durch ablaufende Elemente verursachte Turnoverrate im Cache kann mit dem Leistungsindikator Gesamte Cachturnoverrate überwacht werden, der dem Leistungsobjekt der ASP.NET-Anwendungen zugeordnet ist. Eine hohe Turnoverrate weist u. U. auf ein Problem hin, besonders wenn Elemente entfernt werden, bevor sie abgelaufen sind. (Dies wird gelegentlich auch als Speicherdruck bezeichnet.)

Informationen zum Zwischenspeichern von Seitenausgaben und Datenanforderungen finden Sie unter Übersicht über das Zwischenspeichern in ASP.NET.
Verwenden Sie SQL-Cacheabhängigkeit bedarfsgerecht: ASP.NET unterstützt für die Zwischenspeicherung von Daten aus SQL Server je nach verwendeter Version von SQL Server sowohl tabellenbasierte Abrufe als auch Abfragebenachrichtigungen. Tabellenbasierte Abrufe werden von allen Versionen von SQL Server unterstützt. Wenn sich bei einem tabellenbasierten Abruf Daten in einer Tabelle ändern, werden alle Cacheelemente ungültig, die auf der Tabelle basieren. Dies kann zu einer unnötig hohen Turnoverrate im Cache führen. Sie sollten tabellenbasierte Abrufe daher nicht für Tabellen verwenden, an denen häufig Änderungen vorgenommen werden. Tabellenbasierte Abrufe empfehlen sich beispielsweise für Katalogtabellen, die selten geändert werden. Sie sind jedoch nicht für eine Bestellungstabelle geeignet, die häufig aktualisiert wird.

Abfragebenachrichtigungen werden von SQL Server 2005 und höheren Versionen unterstützt. Bei der Abfragebenachrichtigung werden SQL-Abfragen verwendet, um Änderungen in einem bestimmten Satz von Zeilen zu erkennen. Dies reduziert die Anzahl der Benachrichtigungen, die bei einer Änderung von Tabellen gesendet werden. Die Leistung bei Abfragebenachrichtigungen ist höher als bei tabellenbasierten Abrufen. Abfragebenachrichtigungen sind jedoch nicht für mehrere Tausend Abfragen geeignet.

Weitere Informationen über SQL-Cacheabhängigkeiten finden Sie unter Exemplarische Vorgehensweise: Verwenden der ASP.NET-Ausgabecachefunktion mit SQL Server und Zwischenspeichern in ASP.NET mithilfe der SqlCacheDependency-Klasse.
Verwenden Sie Datenquellenpaging und -sortierung anstelle von Benutzeroberflächenpaging und -sortierung: Das Benutzeroberflächenpaging-Feature von Datensteuerelementen, z. B. von DetailsView und GridView, kann für jedes Datenquellenobjekt verwendet werden, das die ICollection-Schnittstelle unterstützt. Das Datensteuerelement fragt für jeden Pagingvorgang die gesamte Datenauflistung von der Datenquelle ab, wählt die anzuzeigenden Zeilen aus und verwirft die restlichen Daten.

Wenn eine Datenquelle DataSourceView implementiert und die CanPage-Eigenschaft true zurückgibt, verwendet das Datensteuerelement Datenquellenpaging anstelle von Benutzeroberflächenpaging. In diesem Fall fragt das Datensteuerelement nur die für die Anzeige jeder Seite erforderlichen Zeilen ab. Daher ist das Datenquellenpaging effizienter als das Benutzeroberflächenpaging. Von den standardmäßigen ASP.NET-Steuerelementen unterstützen nur die Datenquellensteuerelemente ObjectDataSource und LinqDataSource Datenquellenpaging. Um Datenquellenpaging für andere Datenquellensteuerelemente zu aktivieren, müssen Sie das gewünschte Datenquellensteuerelement vererben und sein Verhalten ändern.
Verwenden Sie eine Timestamp-Spalte, um die Parallelität mit dem LinqDataSource-Steuerelement zu steuern: Wenn eine SQL Server-Datenbanktabelle keine Timestamp-Spalte (ein SQL Server-Datentyp) enthält, überprüft das LinqDataSource-Steuerelement die Parallelität der Daten, indem die ursprünglichen Datenwerte in der Webseite sortiert werden. LINQ to SQL vergleicht die Originalwerte mit denen in der Datenbank, bevor die Daten aktualisiert oder gelöscht werden. Durch dieses Vorgehen kann eine große Webseite entstehen, wenn der Datensatz viele Spalten oder große Spaltenwerte enthält. Außerdem kann es ein Sicherheitsrisiko darstellen, wenn der Datensatz Daten enthält, die Sie nicht auf der Seite offenlegen sollten. Wenn eine Datenbanktabelle eine Timestamp-Spalte enthält, speichert das LinqDataSource-Steuerelement nur den Zeitstempelwert für spätere Vergleiche. LINQ to SQL überprüft die Daten auf Konsistenz, indem ermittelt wird, ob der ursprüngliche Zeitstempel mit dem aktuellen Zeitstempel in der Tabelle übereinstimmt. Weitere Informationen über Zeitstempel finden Sie auf der MSDN-Website unter Timestamp (Transact-SQL).

Wägen Sie den Sicherheitsgewinn durch Ereignisvalidierung gegen die resultierende Leistungseinbuße ab: Steuerelemente, die von der System.Web.UI.WebControls-Klasse und der System.Web.UI.HtmlControls-Klasse abgeleitet werden, können überprüfen, ob ein Ereignis von der Benutzeroberfläche stammt, die vom Steuerelement gerendert wurde. Dies hilft zu verhindern, dass das Steuerelement auf eine vorgetäuschte Ereignisbenachrichtigung reagiert. Beispielsweise kann das DetailsView-Steuerelement mittels Ereignisvalidierung verhindern, dass ein böswilliger Benutzer einen Delete-Aufruf (der im Steuerelement nicht grundsätzlich unterstützt wird) ausführt und das Steuerelement so manipuliert, dass Daten gelöscht werden. Die Ereignisvalidierung führt zu gewissen Leistungseinbußen. Sie steuern die Ereignisvalidierung mithilfe des EnableEventValidation-Konfigurationselements und der RegisterForEventValidation-Methode. Die Leistungseinbuße durch Validierung hängt von der Anzahl der Steuerelemente auf der Seite ab und liegt im Bereich von einigen Prozent.

Sicherheitshinweis:
Es wird dringend davon abgeraten, die Ereignisvalidierung zu deaktivieren. Stellen Sie vor dem Deaktivieren der Ereignisvalidierung sicher, dass kein Postback erstellt werden kann, das unerwünschte Auswirkungen auf die Anwendung hat.

Verwenden Sie die Zwischenspeicherung, Sortierung und Filterung mit dem SqlDataSource-Steuerelement: Wenn die DataSourceMode-Eigenschaft des SqlDataSource-Steuerelements auf DataSet festgelegt ist, kann das SqlDataSource-Steuerelement das Resultset einer Abfrage zwischenspeichern. Die zwischengespeicherten Daten können dann in den Filter- und Sortiervorgängen des SqlDataSource-Steuerelements verwendet werden. Eine Anwendung wird schneller ausgeführt, wenn Sie das gesamte Dataset zwischenspeichern und wenn Sie zum Sortieren und Filtern die Eigenschaften FilterExpression und SortParameterName verwenden. Wenn Benutzer Daten in der Benutzeroberfläche filtern oder sortieren, muss das Datenquellensteuerelement in diesem Fall keine SQL-Anfragen mit Where- und Sort By-Klauseln ausführen, um auf die Datenbank zuzugreifen.

Webanwendungen

Die in den folgenden Richtlinien empfohlenen Vorgehensweisen tragen zu einer insgesamt effizienteren Ausführung von Webanwendungen bei.

Kompilieren Sie die Site vor: Eine Webanwendung wird bei der ersten Anforderung einer Ressource, z. B. einer ASP.NET-Webseite, als Batch kompiliert. Wenn keine Seite in der Anwendung kompiliert wurde, werden bei der Batchkompilierung alle Seiten in einem Verzeichnis in Segmente kompiliert, um die Datenträger- und Speicherauslastung zu optimieren. Sie können eine Webanwendung mit dem ASP.NET-Kompilierungstool (Aspnet_compiler.exe) vorkompilieren. Bei einer direkten Kompilierung ruft das Kompilierungstool die ASP.NET-Laufzeit auf, um die Website auf die gleiche Weise zu kompilieren wie bei der Anforderung einer Seite durch den Benutzer von der Website aus. Sie können eine Webanwendung vorkompilieren, damit das UI-Markup beibehalten wird, oder Sie können die Seiten vorkompilieren, damit der Quellcode nicht geändert werden kann. Weitere Informationen hierzu finden Sie unter Gewusst wie: Vorkompilieren von ASP.NET-Websites.
Deaktivieren Sie den Debugmodus: Deaktivieren Sie immer den Debugmodus, bevor Sie eine Produktionsanwendung bereitstellen oder Leistungstests durchführen. Bei aktiviertem Debugmodus kann die Anwendungsleistung gemindert werden. Weitere Informationen zum Festlegen des Debugmodus finden Sie unter Bearbeiten von ASP.NET-Konfigurationsdateien.
Passen Sie die Konfigurationsdateien an den Webservercomputer und die jeweiligen Anwendungen an: In der Standardkonfiguration von ASP.NET werden die meisten Features aktiviert und die gängigsten Szenarios unterstützt. Sie können jedoch je nach verwendeten Features einige Einstellungen in der Standardkonfiguration ändern, um die Leistung der Anwendungen zu verbessern. In der folgenden Liste sind Konfigurationsänderungen aufgeführt, die Sie in Betracht ziehen sollten:
- Aktivieren Sie die Authentifizierung nur für Anwendungen, die sie benötigen: Standardmäßig ist der Authentifizierungsmodus für ASP.NET-Anwendungen Windows bzw. integriertes NTLM. In den meisten Fällen empfiehlt es sich, die Authentifizierung in der Datei Machine.config zu deaktivieren und sie in den Dateien Web.config für die Anwendungen zu aktivieren, für die sie erforderlich ist.
- Konfigurieren Sie die Anwendung mit den entsprechenden Anforderungs- und Antwortcodierungseinstellungen: Die Standardcodierung von ASP.NET ist UTF-8. Wenn in der Anwendung nur ASCII-Zeichen verwendet werden, sollten Sie die Anwendung für ASCII konfigurieren. Hierdurch wird eine geringe Leistungssteigerung erzielt.
- Deaktivieren Sie AutoEventWireup für die Anwendung: Legen Sie das AutoEventWireup-Attribut in der Datei Web.config auf false fest, um zu verhindern, dass Seitenereignisse basierend auf Namensübereinstimmungen an Methoden gebunden werden (z. B. Page_Load). Sie erzielen so eine geringe Leistungssteigerung auf der Seite. Verwenden Sie zum Verarbeiten von Seitenereignissen eine der beiden folgenden Strategien. Die erste Strategie besteht darin, die Methoden zu überschreiben. Sie können beispielsweise die OnLoad-Methode des Page-Objekts überschreiben, um Code für das Ladeereignis der Seite zu schreiben. (Stellen Sie sicher, dass Sie die Basismethode aufrufen, damit alle Ereignisse ausgelöst werden.) Die zweite Strategie besteht darin, die Seitenereignisse mithilfe des Handles-Schlüsselworts in Visual Basic oder der Delegatverknüpfung in C# zu binden.
- Entfernen Sie nicht verwendete Module aus der Pipeline für die Anforderungsverarbeitung: Standardmäßig sind alle Features im Knoten HttpModules in der Datei Machine.config für den Webservercomputer aktiviert. Abhängig von den in Ihrer Anwendung verwendeten Features können Sie die nicht verwendeten Module aus der Anforderungspipeline entfernen, um eine geringe Leistungssteigerung zu erzielen. Überprüfen Sie jedes Modul und seine Funktionen, und passen Sie es an die Erfordernisse an. Wenn Sie beispielsweise in einer Anwendung weder den Sitzungszustand noch den Ausgabecache verwenden, können Sie die Module für diese Features aus der HttpModules-Liste entfernen.
Führen Sie Webanwendungen in Internetinformationsdienste 5.0 prozessextern aus: ASP.NET verarbeitet in IIS 5.0 Anforderungen standardmäßig mit einem prozessexternen Workerprozess. Dieses Feature wurde auf einen schnellen Durchsatz abgestimmt. Aufgrund der zahlreichen Features und Vorteile wird die Ausführung von ASP.NET in einem prozessexternen Workerprozess für Produktionssites empfohlen.
Verwenden Sie Prozesse regelmäßig wieder: Aus Gründen der Stabilität und Leistung sollten Sie Prozesse regelmäßig wiederverwenden. Über längere Zeiträume hinweg können mit Fehlern behaftete und Speicherverlust verursachende Ressourcen den Durchsatz des Webservers beeinträchtigen. Durch die Wiederverwendung von Prozessen wird bei derartigen Problemen der Speicher bereinigt. Allerdings muss beachtet werden, dass eine zu häufige Wiederverwendung von Prozessen auch Nachteile bergen kann, wenn der Aufwand für das Unterbrechen von Workerprozessen, das erneute Laden von Seiten und das erneute Abrufen von Ressourcen und Daten die Vorteile der Wiederverwendung überwiegt.

Bei ASP.NET-Webanwendungen, die unter Windows Server 2003 und IIS 6.0 ausgeführt werden, muss das Prozessmodell nicht angepasst werden, da ASP.NET die Prozessmodelleinstellungen von IIS 6.0 verwendet.
Geben Sie die Anzahl von Threads pro Workerprozess für die Anwendung richtig an: Die Anforderungsarchitektur von ASP.NET versucht, ein Gleichgewicht zwischen den verfügbaren Ressourcen und den Threads herzustellen, die Anforderungen ausführen. Die Architektur lässt nur so viele gleichzeitig ausgeführte Anforderungen zu, wie von der verfügbaren CPU-Leistung verarbeitet werden können. Diese Technik wird als Threadgating bezeichnet. Unter bestimmten Bedingungen funktioniert der Threadgating-Algorithmus jedoch nur eingeschränkt. Zum Überwachen des Threadgating im Windows-Systemmonitor kann der Leistungsindikator Pipeline-Instanzenzahl verwendet werden, der dem Leistungsobjekt der ASP.NET-Anwendungen zugeordnet ist.

Wenn eine ASP.NET-Webseite eine externe Ressource aufruft, z. B. bei der Durchführung von Datenbankzugriffen oder ASP.NET-Webdienstanforderungen, wird die Seitenanforderung im Allgemeinen bis zur Beantwortung durch die externe Ressource unterbrochen. Hierdurch wird die CPU für die Verarbeitung anderer Threads freigegeben. Wenn eine weitere Anforderung auf ihre Verarbeitung wartet und ein Thread im Threadpool frei ist, wird die wartende Anforderung verarbeitet. Dies kann zur Folge haben, dass zahlreiche Anforderungen gleichzeitig verarbeitet werden und dass zahlreiche Threads im ASP.NET-Workerprozess oder -Anwendungstool auf die Verarbeitung warten. Hierdurch werden der Durchsatz des Webservers und die Leistung beeinträchtigt.

Um diese Leistungseinbußen zu mindern, können Sie manuell einen Grenzwert für die Anzahl der Threads im Prozess festlegen. Ändern Sie hierzu die Attribute MaxWorkerThreads und MaxIOThreads im Abschnitt processModel der Datei Machine.config.

Hinweis:

Arbeitsthreads dienen der Verarbeitung von ASP.NET-Anforderungen. EA-Threads werden verwendet, um Daten aus Dateien, Datenbanken oder ASP.NET-Webdiensten bereitzustellen.

Die den Prozessmodellattributen zugewiesenen Werte geben die maximale Anzahl des jeweiligen Threadtyps pro CPU im Prozess an. Bei einem Computer mit zwei Prozessoren ist die maximale Anzahl doppelt so hoch wie der festgelegte Wert. Für Computer mit vier Prozessoren wird der festgelegte Wert vervierfacht. Die Standardeinstellungen sind für einen Computer mit einem oder zwei Prozessoren geeignet. Bei mehr als 100 oder 200 Threads im Prozess kann die Leistung jedoch auch auf einem Computer mit mehr als zwei Prozessoren beeinträchtigt werden. Sind zu viele Threads im Prozess enthalten, nimmt die Verarbeitungsgeschwindigkeit ab. Der Server muss in diesem Fall zusätzliche Kontextwechsel durchführen, sodass das Betriebssystem CPU-Zyklen zum Verwalten von Threads aufwenden muss, anstatt diese zum Verarbeiten der Anforderungen zu nutzen. Die geeignete Anzahl von Threads ermitteln Sie, indem Sie Leistungstests für die Anwendung durchführen.
Aktivieren Sie bei Anwendungen, die in hohem Maße auf externe Ressourcen angewiesen sind, die Verwendung eines Webgartens auf Multiprozessorcomputern: Das ASP.NET-Prozessmodell unterstützt die Skalierbarkeit auf Multiprozessorcomputern, indem die Arbeitslast auf mehrere Prozesse (einen pro CPU) verteilt und die Prozessorzugehörigkeit auf die jeweilige CPU festgelegt wird. Diese Technik wird auch als Web Gardening (Verwendung eines Webgartens) bezeichnet. Webanwendungen profitieren von der Verwendung eines Webgartens, wenn sie in hohem Maße externe Ressourcen verwenden. Die positiven Auswirkungen zeigen sich beispielsweise bei Anwendungen, die einen Datenbankserver verwenden oder die COM-Objekte mit externen Abhängigkeiten aufrufen. Sie sollten jedoch die Leistung einer Webanwendung in einem Webgarten testen, bevor Sie diese Technik für eine Produktionswebsite aktivieren.

Hinweis:
Arbeitsthreads dienen der Verarbeitung von ASP.NET-Anforderungen. EA-Threads werden verwendet, um Daten aus Dateien, Datenbanken oder ASP.NET-Webdiensten bereitzustellen.

Codierungstechniken

In den folgenden Richtlinien werden Möglichkeiten vorgeschlagen, wie das Schreiben von Code effizienter gestaltet werden kann.

Verwenden Sie möglichst keine Ausnahmen im Code: Ausnahmen können zu beträchtlichen Leistungseinbußen führen. Sie sollten daher nach Möglichkeit keine Ausnahmen verwenden, um den normalen Programmablauf zu steuern. Fügen Sie dem Code stattdessen Logik hinzu, um Bedingungen zu erkennen und zu verarbeiten, die eine Ausnahme auslösen könnten. Zu den gängigen Szenarios, bei denen die Ermittlung im Code erfolgt, gehören die Überprüfung auf null-Werte, die Übertragung von Zeichenfolgen in numerische Werte oder die Suche spezifischer Werte vor mathematischen Operationen. Die folgenden Beispiele zeigen Code, der eine Ausnahme auslösen könnte, sowie alternativen Code zum Testen einer Bedingung. In beiden Fällen wird dasselbe Ergebnis erzielt.
```
// This is not recommended.
try {
   result = 100 / num;
}
catch (Exception e) {
  result = 0;
}

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

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