Die 10 besten Möglichkeiten zur Verbesserung der ASP.Net-Anwendungsleistung
Autor：Eve Cole
Aktualisierungszeit：2009-06-30 15:49:49
In diesem Artikel wird Folgendes behandelt:
Häufig erzählte Mythen über die Verbesserung der Leistung von asp.net-Anwendungen. Nützliche Tipps zur Verbesserung der Leistung von asp.net-Anwendungen
Empfehlungen zum Betrieb von Datenbanken mit Asp.net-Anwendungen
Caching und Hintergrundverarbeitung in Asp.net
Heutzutage ist das Schreiben einer ASP.NET-Webanwendung sehr einfach geworden, und viele Programmierer sind nicht bereit, Zeit in die Entwicklung einer Anwendung mit guter Leistung zu investieren. In diesem Artikel werden die zehn besten Möglichkeiten zur Verbesserung der Leistung von Webanwendungen erläutert. Ich werde meine Diskussion nicht nur auf ASP.NET-Anwendungen beschränken, da es sich lediglich um eine Teilmenge der Webanwendungen handelt. Dieser Artikel kann auch keinen vollständigen Leitfaden zur Verbesserung der Leistung von Webanwendungen bieten, da dies den Umfang eines Buches erfordern würde. Dieser Artikel bietet lediglich einen guten Ausgangspunkt für die Verbesserung der Leistung von Webanwendungen. (Das Einzige, was noch übrig bleibt, ist, langsam selbst zu lernen).
Außerhalb der Arbeit gehe ich oft klettern. Vor jedem Klettern schaue ich mir die Kletterroutenkarte an und lese die Ratschläge früherer erfolgreicher Kletterer. Denn wir brauchen ihre Erfolgserfahrung. Wenn Sie ein Programm mit Leistungsproblemen ändern oder eine leistungsstarke Website entwickeln müssen, müssen Sie auch lernen, wie man eine leistungsstarke Webanwendung schreibt.
Meine persönlichen Erfahrungen stammen hauptsächlich aus meiner Arbeit als Programmmanager in der asp.net-Gruppe von Microsoft, dem Betrieb und der Verwaltung der Website www.asp.net und der Unterstützung bei der Entwicklung von Community Server (einer integrierten und aktualisierten Version der asp.net-Foren). , .Text und nGallery-Software). Ich denke, diese Erfahrungen können mir helfen.
Sie könnten darüber nachdenken, Ihre Anwendung in verschiedene logische Schichten zu unterteilen. Möglicherweise haben Sie auch von der dreischichtigen physischen Architektur oder der N-schichtigen Architektur gehört, dem am häufigsten verwendeten Architekturmodell. Es weist verschiedenen Hardwarefunktionen verschiedene Programmfunktionen zur Ausführung zu. Wenn wir auf diese Weise die Leistung der Anwendung verbessern möchten, können wir das Ziel durch Hinzufügen von Hardware erreichen. Es liegt auf der Hand, dass diese Methode die Leistung der Anwendung verbessern kann, wir sollten jedoch die Verwendung dieser Methode vermeiden. Deshalb sollten wir, wann immer möglich, die ASP.NET-Seite und die von ihr verwendeten Komponenten in eine Anwendung integrieren.
Aufgrund der verteilten Bereitstellung und der Verwendung von Webdiensten oder Remoting verringert sich die Leistung der Anwendung um 20 % oder mehr.
Die Datenschicht ist etwas anders. Es ist besser, sie unabhängig bereitzustellen und eine separate Hardware zu verwenden, um sie auszuführen. Trotzdem ist die Datenbank immer noch der Flaschenhals für die Anwendungsleistung. Wenn Sie Ihr Programm optimieren möchten, sollte Ihnen daher zunächst die Optimierung der Datenschicht in den Sinn kommen.
Bevor Sie einen Bereich Ihrer Anwendung ändern, der Leistungsprobleme verursacht, sollten Sie sicherstellen, dass das Programm, das das Problem verursacht, genau aussieht. Leistungsprofiler sind sehr nützlich, um herauszufinden, wo in Ihrer Anwendung es wie lange dauert. Das sind Orte, die wir nicht intuitiv spüren können.
In diesem Artikel werden zwei Arten von Leistungsoptimierungen erläutert: Zum einen handelt es sich um große Leistungsoptimierungen (große Optimierungen), z. B. die Verwendung des Caches von asp.net, zum anderen um kleine Leistungsoptimierungen (winzige Optimierungen). Kleine Leistungsoptimierungen können manchmal sehr nützlich sein. Sie nehmen eine kleine Änderung an Ihrem Code vor und rufen ihn tausend- oder zehntausendmal auf einmal auf. Wenn Sie eine große Leistungsoptimierung vornehmen, werden Sie eine deutliche Verbesserung der Geschwindigkeit Ihrer Anwendung feststellen. Eine kleine Leistungsoptimierung verbessert möglicherweise nur eine Mikrosekunde pro Anfrage, aber wenn die Anzahl der Anfragen pro Tag groß ist, wird die Anwendung eine erhebliche Leistungsverbesserung erzielen.
Leistung der Datenschicht
Wenn Sie die Leistung einer Anwendung optimieren möchten, können Sie in der folgenden Reihenfolge vorgehen: Muss Ihr Code auf die Datenbank zugreifen? Wenn ja, wie oft sollte auf die Datenbank zugegriffen werden? Ebenso kann diese Testmethode auch in Programmcode verwendet werden, der Webdienste oder Remoting nutzt. In diesem Artikel wird nicht auf das Problem der Programmoptimierung mithilfe von Webdiensten und Remoting eingegangen.
Wenn es in Ihrem Code eine Anforderung gibt, die auf die Datenbank zugreifen muss, und Sie Code sehen, der dieselbe Funktion an anderer Stelle implementiert, müssen Sie ihn zuerst optimieren. Ändern, verbessern und testen Sie weiter, es sei denn, Sie haben ein sehr großes Leistungsproblem. Ihre Zeit sollten Sie besser für die Optimierung von Abfragen, die Verbindung zur Datenbank, die Rückgabe der Größe des Datensatzes und die für die Rückgabe einer Abfrage benötigte Zeit aufwenden.
Basierend auf der Zusammenfassung der Erfahrungen werfen wir einen Blick auf zehn Erfahrungen, die Ihnen dabei helfen können, die Leistung Ihrer Anwendung zu verbessern. Ich werde sie in der Reihenfolge vom größten zum kleinsten hinsichtlich der Effizienzsteigerung erläutern.
1. Mehrere Datensätze zurückgeben
Überprüfen Sie Ihren Datenbankzugriffscode, um festzustellen, ob es Anfragen gibt, die mehrmals zurückgegeben werden. Jeder Roundtrip reduziert die Anzahl der Anfragen pro Sekunde, auf die Ihre Anwendung reagieren kann. Indem Sie mehrere Ergebnismengen in einer einzigen Datenbankanforderung zurückgeben, reduzieren Sie die Zeit, die für die Kommunikation mit der Datenbank benötigt wird, machen Ihr System skalierbar und reduzieren die Arbeitslast auf dem Datenbankserver, um auf Anfragen zu antworten.
Wenn Sie dynamische SQL-Anweisungen verwenden, um mehrere Datensätze zurückzugeben, empfehle ich Ihnen, gespeicherte Prozeduren anstelle dynamischer SQL-Anweisungen zu verwenden. Ob Geschäftslogik in gespeicherte Prozeduren geschrieben werden soll, ist etwas umstritten. Aber ich denke, dass das Schreiben von Geschäftslogik in gespeicherte Prozeduren die Größe der zurückgegebenen Ergebnismenge begrenzen, den Netzwerkdatenverkehr reduzieren und die Notwendigkeit beseitigen kann, Daten auf der Logikebene zu filtern. Das ist eine gute Sache.
Verwenden Sie die ExecuteReader-Methode des SqlCommand-Objekts, um ein stark typisiertes Geschäftsobjekt zurückzugeben, und rufen Sie dann die NextResult-Methode auf, um den Datensatzzeiger zu verschieben und den Datensatz zu lokalisieren. Beispiel 1 zeigt ein Beispiel für die Rückgabe mehrerer stark typisierter ArrayList-Objekte. Wenn Sie nur die Daten aus der Datenbank zurückgeben, die Sie benötigen, kann dies den Speicherverbrauch Ihres Servers erheblich reduzieren.
2. Paging der Daten
ASP. NETs DataGrid verfügt über eine sehr nützliche Funktion: Paging. Wenn das DataGrid Paging zulässt, werden die Daten einer bestimmten Seite nur zu einem bestimmten Zeitpunkt heruntergeladen. Darüber hinaus verfügt es über eine Navigationsleiste für das Daten-Paging, die es Ihnen ermöglicht, eine bestimmte Seite zu durchsuchen und nur eine Seite davon herunterzuladen Daten gleichzeitig.
Es hat jedoch einen kleinen Nachteil: Sie müssen alle Daten an das DataGrid binden. Mit anderen Worten: Ihre Datenschicht muss alle Daten zurückgeben, und dann filtert das DataGrid die für die aktuelle Seite erforderlichen Daten heraus und zeigt sie an. Wenn ein Ergebnissatz von 10.000 Datensätzen vorhanden ist, der mit dem DataGrid paginiert werden muss, bedeutet dies unter der Annahme, dass das DataGrid nur 25 Daten pro Seite anzeigt, dass bei jeder Anforderung 9.975 Daten verworfen werden. Jede Anfrage muss einen so großen Datensatz zurückgeben, was einen großen Einfluss auf die Leistung der Anwendung hat.
Eine gute Lösung besteht darin, eine gespeicherte Paging-Prozedur zu schreiben. Beispiel 2 ist eine gespeicherte Paging-Prozedur für die Auftragstabelle der Northwind-Datenbank. Sie müssen lediglich die aktuelle Seitenzahl und die Anzahl der auf jeder Seite angezeigten Elemente übergeben, und die gespeicherte Prozedur gibt die entsprechenden Ergebnisse zurück.
Auf der Serverseite habe ich speziell ein Paging-Steuerelement geschrieben, um das Paging von Daten zu verwalten. Hier habe ich die erste Methode verwendet und zwei Ergebnismengen in einer gespeicherten Prozedur zurückgegeben: die Gesamtzahl der Datensätze und die erforderliche Ergebnismenge.
Die Gesamtzahl der zurückgegebenen Datensätze hängt von der ausgeführten Abfrage ab; eine Where-Bedingung kann beispielsweise die Größe des zurückgegebenen Ergebnissatzes begrenzen. Da die Gesamtzahl der Seiten anhand der Größe der Datensatzdatensätze in der Paging-Schnittstelle berechnet werden muss, muss die Anzahl der Datensätze im Ergebnissatz zurückgegeben werden. Wenn beispielsweise insgesamt 1.000.000 Datensätze vorhanden sind und Sie die Where-Bedingung verwenden, können Sie so filtern, dass nur 1.000 Datensätze zurückgegeben werden. Die Paging-Logik der gespeicherten Prozedur sollte wissen, welche Daten zurückgegeben werden müssen.
3. Verbindungspool
Die Verwendung von TCP zum Verbinden Ihrer Anwendung mit der Datenbank ist teuer (und zeitaufwändig). Microsoft-Entwickler können Verbindungspools verwenden, um Datenbankverbindungen wiederzuverwenden. Anstatt für jede Anforderung TCP zu verwenden, um eine Verbindung zur Datenbank herzustellen, erstellt der Verbindungspool nur dann eine neue TCP-Verbindung, wenn keine gültige Verbindung besteht. Wenn eine Verbindung geschlossen wird, wird sie in den Pool gestellt und behält weiterhin eine Verbindung zur Datenbank bei, wodurch die Anzahl der TCP-Verbindungen zur Datenbank reduziert wird.
Natürlich sollten Sie auf die Anschlüsse achten, die Sie vergessen haben, nach jedem Gebrauch zu schließen. Was ich betonen möchte ist: Egal was jemand sagt, der GC (Garbage Collector) im .net Framework ruft immer die Close- oder Dispose-Methode des Verbindungsobjekts auf, um Ihre Verbindung explizit zu schließen, nachdem Sie die Verwendung des Verbindungsobjekts beendet haben. Erwarten Sie nicht, dass die CLR die Verbindung innerhalb der Zeit schließt, die Sie sich vorstellen. Obwohl die CLR das Objekt irgendwann zerstören und die Verbindung schließen wird, sind wir nicht sicher, wann sie diese Dinge tun wird.
Für die Verwendung der Verbindungspooloptimierung gibt es zwei Regeln: Öffnen Sie zunächst die Verbindung, verarbeiten Sie die Daten und schließen Sie dann die Verbindung. Wenn Sie die Verbindung mehrmals pro Anfrage öffnen oder schließen müssen, ist es besser, als ständig eine Nebenverbindung zu öffnen und diese an jede Methode zu übergeben. Zweitens verwenden Sie dieselbe Verbindungszeichenfolge (oder dieselbe Benutzer-ID, wenn Sie die integrierte Authentifizierung verwenden). Wenn Sie nicht dieselbe Verbindungszeichenfolge verwenden, beispielsweise wenn Sie eine Verbindungszeichenfolge verwenden, die auf dem angemeldeten Benutzer basiert, werden die Optimierungsfunktionen des Verbindungspools nicht genutzt. Wenn Sie integrierte Argumente verwenden, können Sie die Optimierungsfunktion des Verbindungspools nicht vollständig nutzen, da viele Benutzer vorhanden sind. .NET CLR bietet einen Datenleistungsindikator, der sehr nützlich ist, wenn wir Programmleistungsmerkmale, einschließlich der Verfolgung von Verbindungspools, verfolgen müssen.
Immer wenn Ihre Anwendung eine Verbindung zu einer Ressource auf einem anderen Computer herstellt, beispielsweise einer Datenbank, sollten Sie sich darauf konzentrieren, die Zeit zu optimieren, die Sie zum Herstellen einer Verbindung mit der Ressource benötigen, die Zeit, die zum Empfangen und Senden von Daten benötigt wird, und die Häufigkeit, mit der Sie zurückgehen . Die Optimierung jedes Prozesssprungs in Ihrer Anwendung ist der Ausgangspunkt für die Verbesserung der Leistung Ihrer Anwendung.
Die Anwendungsschicht enthält die Logik für die Verbindung zur Datenschicht, die Übertragung von Daten an Instanzen der entsprechenden Klassen und die Geschäftsverarbeitung. Im Community Server müssen Sie beispielsweise eine Foren- oder Thread-Sammlung zusammenstellen und dann Geschäftslogik anwenden, z. B. Autorisierung. Noch wichtiger ist, dass Sie hier die Caching-Logik vervollständigen.
4. ASP. NET-Cache-API
Bevor Sie eine Anwendung schreiben, müssen Sie zunächst dafür sorgen, dass die Anwendung die Caching-Funktionen von ASP.NET optimal nutzt.
Wenn Ihre Komponente in einer Asp.net-Anwendung ausgeführt werden soll, müssen Sie in Ihrem Projekt nur auf System.Web.dll verweisen. Verwenden Sie dann die HttpRuntime.Cache-Eigenschaft, um auf den Cache zuzugreifen (der Zugriff kann auch über Page.Cache oder HttpContext.Cache erfolgen).
Es gibt verschiedene Regeln für das Zwischenspeichern von Daten. Erstens können die Daten häufig verwendet werden und diese Daten können zwischengespeichert werden. Zweitens ist die Zugriffshäufigkeit auf Daten sehr hoch, oder die Zugriffshäufigkeit auf ein Datenelement ist nicht hoch, aber sein Lebenszyklus ist sehr lang. Es ist am besten, solche Daten zwischenzuspeichern. Das dritte Problem wird oft ignoriert. Wenn auf einem X86-Computer normalerweise zu viele Daten zwischengespeichert werden, tritt ein Speicherüberlauffehler auf. Der Cache ist also begrenzt. Mit anderen Worten: Sie sollten die Größe des Cache-Sets schätzen und die Größe des Cache-Sets auf weniger als 10 begrenzen, da es sonst zu Problemen kommen kann. Wenn in Asp.net der Cache zu groß ist, wird ein Speicherüberlauffehler gemeldet, insbesondere wenn ein großes DataSet-Objekt zwischengespeichert wird.
Hier sind einige wichtige Caching-Mechanismen, die Sie verstehen müssen. Erstens implementiert der Cache das „Zuletzt verwendet“-Prinzip (einen Algorithmus, der am wenigsten verwendet wird). Wenn nur wenige Caches vorhanden sind, werden nutzlose Caches automatisch gelöscht. Zweitens erzwingt das Prinzip der „bedingten Abhängigkeit“ die Eliminierung (Ablaufabhängigkeit). Die Bedingungen können Zeit, Schlüsselwörter und Dateien sein. Zeit als Bedingung wird am häufigsten verwendet. In asp.net2.0 wird eine stärkere Bedingung hinzugefügt, nämlich die Datenbankbedingung. Wenn sich die Daten in der Datenbank ändern, muss der Cache geleert werden. Weitere Informationen zu datenbankbedingten Abhängigkeiten finden Sie in der Kolumne „Cutting Edge“ von Dino Esposito in der Juli-Ausgabe 2004 des MSDN Magazine. Die Cache-Architektur von Asp.net ist in der folgenden Abbildung dargestellt:
5. Zwischenspeicherung vor der Anfrage
Ich habe bereits erwähnt, dass wir, selbst wenn wir an einigen Stellen nur eine kleine Leistungsverbesserung erzielen, eine große Leistungsverbesserung erzielen können. Mir gefällt die Verwendung von Pre-Request-Caching sehr gut, um die Leistung des Programms zu verbessern.
Obwohl die Cache-API darauf ausgelegt ist, Daten für einen bestimmten Zeitraum zu speichern, speichert der Pre-Request-Cache nur den Inhalt einer bestimmten Anfrage für einen bestimmten Zeitraum. Wenn die Zugriffshäufigkeit einer bestimmten Anfrage hoch ist und diese Anfrage die Daten nur einmal extrahieren, anwenden, ändern oder aktualisieren muss. Anschließend kann die Anfrage vorab zwischengespeichert werden. Lassen Sie uns zur Veranschaulichung ein Beispiel geben.
In der CS-Forum-Anwendung erfordert die Serversteuerung jeder Seite angepasste Daten, um deren Skin, das zu verwendende Stylesheet und andere personalisierte Dinge zu bestimmen. Einige der Daten müssen möglicherweise über einen längeren Zeitraum gespeichert werden, manchmal jedoch nicht. Beispielsweise müssen die Skin-Daten einer Steuerung nur einmal angewendet werden und können ständig verwendet werden.
Um das Pre-Request-Caching zu implementieren, verwenden Sie die HttpContext-Klasse von Asp.net. Bei jeder Anfrage wird eine Instanz der HttpContext-Klasse erstellt, auf die über die HttpContext.Current-Eigenschaft überall während der Anfrage zugegriffen werden kann. Die HttpContext-Klasse verfügt über eine Items-Sammlungseigenschaft, und alle Objekte und Daten werden dieser Sammlung hinzugefügt und während der Anforderung zwischengespeichert. So wie Sie Cache zum Zwischenspeichern häufig aufgerufener Daten verwenden, können Sie HttpContext.Items zum Zwischenspeichern grundlegender Daten verwenden, die in jeder Anforderung verwendet werden. Die Logik dahinter ist einfach: Wir fügen Daten zu HttpContext.Items hinzu und lesen dann die Daten daraus.
6. Hintergrundverarbeitung
Mit der oben genannten Methode sollte Ihre Anwendung sehr schnell laufen, oder? Aber irgendwann kann es sein, dass eine sehr zeitaufwändige Aufgabe in einer Anfrage im Programm ausgeführt wird. Zum Beispiel das Versenden von E-Mails oder die Überprüfung der Richtigkeit übermittelter Daten usw.
Als wir asp.net Forums 1.0 in CS integriert haben, stellten wir fest, dass das Einreichen eines neuen Beitrags sehr langsam war. Jedes Mal, wenn ein neuer Beitrag hinzugefügt wird, muss die Anwendung zunächst prüfen, ob es sich bei dem Beitrag um ein Duplikat handelt, ihn dann mit dem „Badword“-Filter filtern, den Bildanhangscode überprüfen, den Beitrag indizieren und ihn zur entsprechenden Warteschlange hinzufügen und validieren Fügen Sie den Anhang hinzu und senden Sie die E-Mail schließlich an die Mailbox des Abonnenten. Offensichtlich ist das eine Menge Arbeit.
Das Ergebnis ist, dass viel Zeit mit der Indizierung und dem Versenden von E-Mails verbracht wird. Das Indizieren von Beiträgen ist ein zeitaufwändiger Vorgang, und das Versenden von E-Mails an Abonnenten erfordert eine Verbindung zum SMTP-Dienst und das anschließende Versenden einer E-Mail an jeden Abonnenten.
Das Indizieren und Versenden von E-Mails muss nicht bei jeder Anfrage ausgelöst werden. Idealerweise möchten wir diese Vorgänge stapelweise verarbeiten und jeweils nur 25 E-Mails oder alle 5 Minuten alle neuen E-Mails versenden. Wir haben beschlossen, denselben Code wie den Datenbank-Prototyp-Cache zu verwenden, aber das schlug fehl, sodass wir zu VS.NET 2005 zurückkehren mussten.
Wir finden die Timer-Klasse im System.Threading-Namespace. Diese Klasse ist sehr nützlich, aber nur wenige Leute kennen sie und noch weniger Webentwickler kennen sie. Sobald er eine Instanz dieser Klasse erstellt, ruft die Timer-Klasse zu jedem angegebenen Zeitpunkt die angegebene Rückruffunktion von einem Thread im Thread-Pool auf. Dies bedeutet, dass Ihre ASP.NET-Anwendung auch dann ausgeführt werden kann, wenn keine Anforderungen vorliegen. Dies ist die Lösung, mit der wir uns später befassen. Sie können die Indizierung und den E-Mail-Versand im Hintergrund ausführen lassen, anstatt sie bei jeder Anfrage ausführen zu müssen.
Es gibt zwei Probleme mit der Hintergrundlauftechnologie. Das erste besteht darin, dass die Timer-Klasseninstanz nicht mehr ausgeführt wird, wenn Ihre Anwendungsdomäne deinstalliert wird. Das heißt, die Rückrufmethode wird nicht aufgerufen. Da in jedem Prozess der CLR viele Threads ausgeführt werden, ist es außerdem schwierig, einen Thread für den Timer zu finden, der ihn ausführt, oder er kann ihn ausführen, aber es wird verzögert. Die Asp.net-Schicht sollte diese Technik so wenig wie möglich verwenden, um die Anzahl der Threads im Prozess zu reduzieren, oder nur zulassen, dass Anforderungen einen kleinen Teil der Threads verwenden. Natürlich können Sie es nur verwenden, wenn Sie viel asynchrone Arbeit haben.
Es ist nicht genügend Platz vorhanden, um den Code hier zu veröffentlichen. Sie können das Beispielprogramm von http://www.rob-howard.net/ herunterladen. Bitte laden Sie das Blackbelt TechEd 2004-Beispielprogramm herunter.
7. Seitenausgabe-Caching und Proxy-Dienste
Asp.net ist Ihre Schnittstellenschicht (oder sollte es sein), sie enthält Seiten, Benutzersteuerelemente, Serversteuerelemente (HttpHandlers und HttpModules) und die von ihnen generierten Inhalte. Wenn Sie über eine Asp.net-Seite verfügen, die HTML-, XML-, Bild- oder andere Daten ausgibt, und Sie Code verwenden, um für jede Anforderung denselben Ausgabeinhalt zu generieren, müssen Sie die Verwendung von Seitenausgabe-Caching in Betracht ziehen.
Sie können dies tun, indem Sie einfach die folgende Codezeile in Ihre Seite kopieren:
<%@ PageOutputCache VaryByParams=“none“ Duration=“60“ %>
Sie können die in der ersten Anforderung generierte Seite effektiv zum Ausgeben des zwischengespeicherten Inhalts verwenden und den Seiteninhalt nach 60 Sekunden neu generieren. Diese Technologie wird tatsächlich mithilfe einer Low-Level-Cache-API implementiert. Es gibt mehrere Parameter, die für das Zwischenspeichern der Seitenausgabe konfiguriert werden können, z. B. der oben erwähnte Parameter VaryByParams. Dieser Parameter gibt an, wann die Bedingungen für die erneute Ausgabe zwischengespeichert werden sollen. Wenn wir diesen Parameter beispielsweise auf VaryByParams="Report" setzen, wird die von „default.aspx?Report=1“ oder „default.aspx?Report=2“ angeforderte Ausgabe zwischengespeichert. Der Wert eines Parameters kann aus mehreren, durch Semikolons getrennten Parametern bestehen.
Viele Leute wissen nicht, dass ASP.NET bei Verwendung des Seitenausgabe-Cachings auch einen HTTP-Header-Satz (HTTP-Header) generiert und ihn auf dem Downstream-Cache-Server speichert. Diese Informationen können für die Internetsicherheit von Microsoft und zur Beschleunigung verwendet werden Reaktionsgeschwindigkeit des Servers. Wenn der HTTP-Cache-Header zurückgesetzt wird, wird der angeforderte Inhalt in der Netzwerkressource zwischengespeichert. Wenn der Client den Inhalt erneut anfordert, erhält er den Inhalt nicht mehr vom Ursprungsserver, sondern direkt aus dem Cache.
Die Verwendung des Seitenausgabe-Caching verbessert zwar nicht die Leistung Ihrer Anwendung, verringert jedoch die Häufigkeit, mit der zwischengespeicherter Seiteninhalt vom Server geladen wird. Dies beschränkt sich natürlich auf das Caching von Seiten, die für anonyme Benutzer zugänglich sind. Denn sobald die Seite zwischengespeichert ist, können keine Autorisierungsvorgänge mehr ausgeführt werden.
8. Verwenden Sie das Kernel-Caching von IIS6.0
Wenn Ihre Anwendung nicht in IIS 6.0 (Windows Server 2003) ausgeführt wird, haben Sie einige großartige Möglichkeiten zur Verbesserung der Anwendungsleistung verpasst. In der siebten Methode habe ich darüber gesprochen, wie das Seitenausgabe-Caching verwendet werden kann, um die Anwendungsleistung zu verbessern. Wenn in IIS5.0 eine Anforderung an IIS eingeht, überträgt IIS diese an asp.net. Wenn der Seitenausgabecache angewendet wird, empfängt der HttpHandler in ASP.NET die Anforderung und der HttpHandler überträgt den Inhalt aus dem Cache . Nehmen Sie es heraus und geben Sie es zurück.
Wenn Sie IIS6.0 verwenden, verfügt es über eine sehr gute Funktion namens Kernel-Caching und Sie müssen keinen Code im asp.net-Programm ändern. Wenn asp.net eine zwischengespeicherte Anfrage empfängt, ruft der Kernel-Cache von IIS eine Kopie davon aus dem Cache ab. Wenn eine Anfrage vom Netzwerk kommt, erhält die Kernel-Schicht die Anfrage. Wenn die Anfrage zwischengespeichert wird, werden die zwischengespeicherten Daten direkt zurückgegeben, und Sie sind fertig. Das bedeutet, dass Sie unglaubliche Leistungsverbesserungen erzielen, wenn Sie IIS-Kernel-Caching zum Zwischenspeichern der Seitenausgabe verwenden. Bei der Entwicklung von asp.net für VS.NET 2005 war ich als Programmmanager speziell für die Leistung von asp.net verantwortlich. Ich habe mir alle täglichen Berichtsdaten angesehen und festgestellt, dass dies der Fall ist am schnellsten. Ein gemeinsames Merkmal ist, dass die Netzwerkanforderungen und -antworten umfangreich sind, IIS jedoch nur 5 % der CPU-Ressourcen beansprucht. Das ist erstaunlich. Es gibt viele Gründe, IIS 6.0 zu verwenden, aber Kernel-Cashing ist der beste.
9. Komprimieren Sie Daten mit Gzip
Sofern Ihre CPU-Auslastung nicht zu hoch ist, müssen Techniken zur Verbesserung der Serverleistung eingesetzt werden. Die Verwendung von gzip zum Komprimieren von Daten kann die Datenmenge reduzieren, die Sie an den Server senden, die Ausführungsgeschwindigkeit der Seite verbessern und auch den Netzwerkverkehr reduzieren. Wie die Daten besser komprimiert werden können, hängt von den Daten ab, die Sie senden möchten, und davon, ob der Browser des Clients dies unterstützt (IIS sendet gzip-komprimierte Daten an den Client, und der Client muss gzip unterstützen, um sie zu analysieren, IE6.0 und Firefox). Auf diese Weise kann Ihr Server auf mehr Anfragen pro Sekunde antworten. Gleichzeitig reduzieren Sie die Menge der in der Antwort gesendeten Daten und können mehr Anfragen senden.
Gute Nachrichten, die GZIP-Komprimierung wurde in IIS6.0 integriert und ist besser als GZIP in IIS5.0. Um die gzip-Komprimierung in IIS 6.0 zu aktivieren, können Sie sie leider nicht im Eigenschaftendialog von IIS 6.0 festlegen. Das IIS-Entwicklungsteam hat die gzip-Komprimierungsfunktion entwickelt, aber vergessen, es Administratoren leicht zu machen, sie im Administratorfenster zu aktivieren. Um die gzip-Komprimierung zu aktivieren, können Sie die Konfiguration nur in der IIS6.0-XML-Konfigurationsdatei ändern.
Zusätzlich zum Lesen dieses Artikels muss ich den Artikel <<IIS6-Komprimierung>> von Brad Wilson lesen ( http://www.dotnetdevs.com/articles/IIS6compression.aspx ); es gibt auch einen Artikel, der das Grundwissen vorstellt der ASPX-Komprimierung. Aktivieren Sie die ASPX-Komprimierung in IIS. Beachten Sie jedoch, dass sich dynamische Komprimierung und Kernel-Cashing in IIS6 gegenseitig ausschließen.
10. ViewState der Serversteuerelemente
ViewState ist eine Funktion in asp.net, die zum Speichern eines Statuswerts verwendet wird, der zum Generieren einer Seite in einem ausgeblendeten Feld verwendet wird. Wenn die Seite an den Server zurückgesendet wird, analysiert, überprüft und wendet der Server die Daten in ViewState an, um den Kontrollbaum der Seite wiederherzustellen. ViewState ist eine sehr nützliche Funktion, die den Clientstatus beibehalten kann, ohne Cookies oder Serverspeicher zu verwenden. Die meisten Serversteuerelemente verwenden ViewState, um die Statuswerte von Elementen beizubehalten, die mit dem Benutzer auf der Seite interagieren. Zum Beispiel, um die Seitenzahl der aktuellen Seite zum Blättern zu speichern.
Die Verwendung von ViewState hat einige negative Auswirkungen. Erstens erhöht es die Antwort- und Anfragezeiten des Servers. Zweitens erhöht jedes Postback die Zeit zum Serialisieren und Deserialisieren von Daten. Schließlich verbraucht es auch mehr Speicher auf dem Server.
Viele Serversteuerelemente verwenden in der Regel ViewState, z. B. das bekannte DataGrid, und manchmal besteht keine Notwendigkeit, es zu verwenden. ViewState ist standardmäßig aktiviert. Wenn Sie ViewState nicht verwenden möchten, können Sie es auf Steuerelement- oder Seitenebene deaktivieren. Im Steuerelement müssen Sie nur die Eigenschaft „EnableViewState“ auf „False“ setzen. Sie können sie auch auf der Seite festlegen, um ihren Geltungsbereich auf die gesamte Seite auszudehnen:
<%@ Page EnableViewState=“false“ %>
Wenn für die Seite kein Postback erforderlich ist oder die Seite bei jeder Anforderung nur mit Steuerelementen gerendert wird. Sie sollten ViewState auf Seitenebene deaktivieren.
Zusammenfassen
Ich gebe nur ein paar Tipps, die meiner Meinung nach dazu beitragen werden, das Schreiben leistungsstarker ASP.NET-Anwendungen zu verbessern. Die in diesem Artikel erwähnten Tipps zur Verbesserung der ASP.NET-Leistung sind nur ein Ausgangspunkt. Weitere Informationen finden Sie unter „ASP verbessern“. NET-Buch „Performance“. Nur durch Ihre eigene Praxis können Sie die Techniken finden, die für Ihr Projekt am hilfreichsten sind. Diese Tipps können jedoch als Leitfaden auf Ihrem Entwicklungsweg dienen. In der Softwareentwicklung ist keines davon unbedingt sinnvoll, da jedes Projekt anders ist.
