Entwurf und Konfiguration zur Leistungsoptimierung
Aktualisiert: November 2007
In diesem Thema werden verfügbare Optionen für Entwurf, Konfiguration, Kompilierung und Speicher erörtert, mit denen die Leistung einer Webanwendung erhöht werden kann.
Asynchrone Programmiermodelle
ASP.NET unterstützt asynchrone Programmierverfahren, mit denen Sie zeitintensive Aufgaben, z. B. eine Datenbankabfrage, in einen Thread verschieben können, der getrennt vom Hauptanwendungsthread ausgeführt wird. Sie können folgende Verfahren verwenden:
BackgroundWorker-Komponente Die BackgroundWorker-Klasse im System.ComponentModel-Namespace ermöglicht es Ihnen, dem DoWork-Ereignishandler den Code für die zeitintensive Aufgabe hinzuzufügen und die RunWorkerAsync-Methode aufzurufen, um das DoWork-Ereignis auszulösen. Der aufrufende Thread wird weiterhin ausgeführt, während die Workermethode asynchron ausgeführt wird. Wenn die Methode beendet wurde, benachrichtigt die BackgroundWorker-Komponente den aufrufenden Thread, indem sie das RunWorkerCompleted-Ereignis auslöst. Weitere Informationen hierzu finden Sie unter BackgroundWorker-Komponente.
Ereignisbasierte asynchrone Programmierung Das ereignisbasierte asynchrone Muster kann mehrere Formen aufweisen, die von der Komplexität der von einer bestimmten Klasse unterstützten Operationen abhängen. Die einfachsten Klassen verfügen möglicherweise nur über eine einzige MethodNameAsync-Methode und ein entsprechendes MethodNameCompleted-Ereignis. Komplexere Klassen können mehrere MethodNameAsync-Methoden zusammen mit dem jeweiligen MethodNameCompleted-Ereignis und außerdem synchrone Versionen dieser Methoden enthalten. Klassen können wahlweise für jede asynchrone Methode einen Abbruch, eine Statusmeldung und inkrementelle Ergebnisse unterstützen.
Zusätzlich unterstützt eine asynchrone Methode mehrere ausstehende Aufrufe (mehrere gleichzeitige Aufrufe). Dadurch kann die Methode vom Code beliebig oft aufgerufen werden, bevor weitere ausstehende Operationen zum Abschluss gebracht werden. Damit die Anwendung diese Situation meistern kann, muss sie ggf. den Abschluss jeder einzelnen Operation verfolgen.
Eine vollständige Beschreibung dieses Musters und seiner Implementierung finden Sie unter Übersicht über ereignisbasierte asynchrone Muster.
Asynchrone Programmierung mit IAsyncResult Ein asynchroner Vorgang, der das IAsyncResult-Entwurfsmuster verwendet, wird über zwei Methoden mit den Namen BeginOperationName und EndOperationName implementiert, die am Anfang und am Ende des asynchronen Vorgangs OperationName stehen. Von BeginOperationName wird die Steuerung sofort an den aufrufenden Thread zurückgegeben. Durch die EndOperationName-Methode wird der asynchrone Vorgang OperationName beendet. Der Zeitpunkt zum Aufrufen von EndOperationName ist wichtig, da der aufrufende Thread blockiert wird, wenn OperationName noch nicht abgeschlossen wurde. Weitere Informationen finden Sie unter Übersicht über die asynchrone Programmierung.
Clients callbacks Bei einem Clientrückruf sendet eine Clientskriptfunktion eine Anforderung an eine ASP.NET-Webseite, ohne dass der Aufwand eines Postbacks erforderlich ist.
Ein Beispiel, in dem einige dieser Verfahren verwendet werden, finden Sie unter Technologiebeispiel für das ereignisbasierte asynchrone Muster.
Optionen für Kompilierung und Konfiguration
Die Leistung einer Anwendung ist von ihrer Kompilierung und Konfiguration abhängig. In den folgenden Richtlinien werden Verfahren vorgeschlagen, um die Effizienz von Webanwendungen insgesamt zu erhöhen.
Kompilieren Sie umfangreiche Webanwendungen vor.
Verwenden Sie Prozesse wieder, wenn Sie ASP.NET-Webanwendungen in Internetinformationsdienste 5.0 ausführen.
Passen Sie die Anzahl von Threads pro Workerprozess ggf. an die Anwendung an. Ziehen Sie bei Anwendungen, die in großem Umfang auf externe Ressourcen angewiesen sind, die Verwendung eines Webgartens auf Multiprozessorcomputern in Betracht.
Deaktivieren Sie den Debugmodus.
Passen Sie die Konfigurationsdateien Ihren Anforderungen entsprechend an den Webservercomputer und die jeweiligen Anwendungen an.
Aktivieren Sie Authentifizierung nur für Anwendungen, die Authentifizierung erfordern.
Konfigurieren Sie die Anwendung zum Verwenden der geeigneten Einstellungen zum Codieren von Anforderungen und Antworten.
Ziehen Sie die Deaktivierung von AutoEventWireup für die Anwendung in Betracht.
Entfernen Sie nicht verwendete Module aus der Pipeline für die Anforderungsverarbeitung.
Weitere Informationen finden Sie unter Übersicht über die Leistung.
Optionen für die Cachekonfiguration
Um die Anwendungsleistung zu erhöhen, können Sie die Zwischenspeicherung auf den folgenden Ebenen konfigurieren:
Anwendung In der Datei Web.config einer Anwendung können Sie mithilfe des OutputCacheSection-Elements die Zwischenspeicherung für die gesamte Anwendung steuern. Mithilfe des OutputCacheSettingsSection-Elements können Sie Cacheprofile einrichten, die dann auf einzelne Seiten angewendet werden können.
Computer In der Datei Machine.config können Sie die gleichen Optionen wie in der Datei Web.config konfigurieren.
Seite Sie können das Zwischenspeichern in einzelnen Seiten konfigurieren, indem Sie Cacheprofile anwenden, die in einer Konfigurationsdatei definiert wurden. Sie können aber auch einzelne Cacheeigenschaften konfigurieren, und zwar entweder in der @ OutputCache-Direktive oder durch das Festlegen von Attributen in der Klassendefinition der Seite.
Steuerelement Sie können die Zwischenspeicherung des Benutzersteuerelements konfigurieren, indem Sie die @ OutputCache-Direktive in der Datei des Benutzersteuerelements oder das PartialCachingAttribute-Attribut in der Klassendefinition des Steuerelements einstellen.
Weitere Informationen hierzu finden Sie unter Cachekonfiguration in ASP.NET.
Speicherrecycling mit IIS 6.0
Wenn eine Anwendung Code enthält, der Probleme verursacht, z. B. eine COM Interop-Anwendung mit bekannten Speicherverlusten, und Sie den Code nicht einfach neu schreiben können, empfiehlt es sich möglicherweise, das Ausmaß der Probleme einzugrenzen, indem der Workerprozess für die Anwendung regelmäßig wiederverwendet wird. Die Wiederverwendung des Workerprozesses ersetzt eine Instanz der Anwendung im Arbeitsspeicher. IIS 6.0 kann Workerprozesse automatisch wiederverwenden, indem die einem Anwendungspool zugewiesenen Workerprozesse neu gestartet werden. Dies trägt zur reibungslosen Ausführung von Programmen bei.
Beibehalten des Zustands während der Wiederverwendung
Wenn ein Anwendungspool Anwendungen enthält, die von Zustandsdaten abhängen, müssen Sie bestimmen, ob die Workerprozesse wiederverwendet werden sollen, die diesem Anwendungspool zugewiesen sind. Wenn Sie einen Workerprozess wiederverwenden, gehen die vom Prozess verwalteten Anwendungszustandsdaten verloren. In diesem Fall empfiehlt es sich möglicherweise, auf die Wiederverwendung zu verzichten.
Sie können Prozesse wiederverwenden und das Zustandsproblem lösen, indem Sie Zustandsdaten außerhalb des Workerprozesses verwalten, z. B. in einer Datenbank. Das prozessexterne Verwalten von Zustandsdaten zur Wiederverwendung kann die Serverleistung jedoch auf zweierlei Weise beeinträchtigen:
Aufgrund des Verwaltungsaufwands zum Verschieben der Daten zwischen Anwendung und Datenspeicher wird die Leistung verringert.
Durch die Wiederverwendung werden prozessinterne Datencaches geleert, sodass die Caches neu erstellt werden müssen.
ASP.NET ermöglicht es Ihnen, den Sitzungszustand mithilfe eines Sitzungszustandsdienstes oder einer SQL-Datenbank beizubehalten. Weitere Informationen hierzu finden Sie unter Sitzungszustandsmodi.
Weitere Informationen finden Sie unter Recycling Worker Processes (IIS 6.0).
Dienst für systemeigene Abbilder
Der Dienst für systemeigene Abbilder ist ein Windows-Dienst zum Generieren und Verwalten systemeigener Abbilder. Systemeigene Abbilder sind Dateien, die kompilierten prozessorspezifischen Computercode enthalten. Der Dienst für systemeigene Abbilder ermöglicht es Ihnen, die Installation und Aktualisierung systemeigener Abbilder auf einen Zeitraum zu verschieben, in dem sich der Computer im Leerlauf befindet. Native Image Generator (Ngen.exe) ist ein Tool zur Leistungsoptimierung verwalteter Anwendungen. Ngen.exe erstellt systemeigene Abbilder und installiert sie auf dem lokalen Computer im Cache für systemeigene Abbilder. Die Laufzeit kann systemeigene Abbilder aus dem Cache nutzen und muss nicht den JIT (Just-In-Time)-Compiler verwenden, um die ursprüngliche Assembly zu kompilieren.
Weitere Informationen finden Sie auf der MSDN Magazine-Website im Artikel NGen Revs Up Your Performance with Powerful New Features.
Globaler Assemblycache und das Workingset
Beim Workingset eines Prozesses handelt es sich um den Satz der gegenwärtig im physikalischen Arbeitsspeicher für den Prozess verfügbaren Speicherseiten. Diese Seiten sind resident und für die Verwendung durch eine Anwendung verfügbar, ohne dass ein Seitenfehler ausgelöst wird. Sie können die Größe des Workingsets mithilfe der PeakWorkingSet-Eigenschaft und der WorkingSet-Eigenschaft überwachen. Durch das Platzieren von Assemblys im Globalen Assemblycache können Sie die Größe des Workingsets einer Anwendung verringern. Diese Option empfiehlt sich hauptsächlich für Assemblys der mittleren Ebene und freigegebene Assemblys.