Detaillierte Erklärung von Web.config + Optimierung von asp.net
Autor：Eve Cole
Aktualisierungszeit：2009-07-01 16:44:14
1. Die Datei Web.config verstehen
Die Datei Web.config ist eine XML-Textdatei, die zum Speichern der Konfigurationsinformationen der asp.NET-Webanwendung verwendet wird (z. B. die am häufigsten verwendete Authentifizierungsmethode zum Festlegen der asp.NET-Webanwendung). Sie kann in jedem angezeigt werden Schritt der Anwendung im Verzeichnis. Wenn Sie eine neue Webanwendung über .NET erstellen, wird standardmäßig automatisch eine Standarddatei Web.config im Stammverzeichnis erstellt, einschließlich der Standardkonfigurationseinstellungen, und alle Unterverzeichnisse erben ihre Konfigurationseinstellungen. Wenn Sie die Konfigurationseinstellungen eines Unterverzeichnisses ändern möchten, können Sie im Unterverzeichnis eine neue Web.config-Datei erstellen. Es kann zusätzlich zu den vom übergeordneten Verzeichnis geerbten Konfigurationsinformationen Konfigurationsinformationen bereitstellen und auch im übergeordneten Verzeichnis definierte Einstellungen überschreiben oder ändern.
(1).Web.Config wird in der XML-Dateispezifikation gespeichert und die Konfigurationsdatei ist in die folgenden Formate unterteilt
1. Merkmale der Deklaration des Konfigurationsabschnittshandlers: Befindet sich oben in der Konfigurationsdatei und ist im Tag <configSections> enthalten.
2. Spezifische Anwendungskonfigurationsfunktionen: Befindet sich in <appSetting>. Sie können Informationen wie globale Konstanteneinstellungen für die Anwendung definieren.
3. Einstellungsfunktionen für den Konfigurationsabschnitt: Befindet sich im Abschnitt <system.Web> und steuert das Verhalten der asp.net-Laufzeit.
4. Funktionen von Konfigurationsabschnittsgruppen: Mithilfe des <sectionGroup>-Tags können Sie die Gruppierung anpassen und sie innerhalb von <configSections> oder innerhalb anderer <sectionGroup>-Tags platzieren.
(2). Jeder Abschnitt des Konfigurationsabschnitts
1. <Konfiguration> Abschnittswurzelelement, andere Abschnitte befinden sich darin.
2. Abschnitt <appSetting> Dieser Abschnitt wird zum Definieren von Anwendungseinstellungen verwendet. Für einige unsichere Einstellungen können Benutzer auch ihre eigene Verwendung entsprechend ihrer tatsächlichen Situation festlegen:
I.<appSettings>
<add key="Conntction" value="server=192.168.85.66;userid=sa;password=;database=Info;"/>
<appSettings>
Es wird eine Verbindungszeichenfolgenkonstante definiert, und die Verbindungszeichenfolge kann in tatsächlichen Anwendungen geändert werden, ohne den Programmcode zu ändern.
II.<appSettings>
<add key="ErrPage" value="Error.aspx"/><appSettings> definiert eine Fehlerumleitungsseite.
3. Format des Abschnitts <Zusammenstellung>:
<Zusammenstellung
defaultLanguage="c#"
debug="true"
/>
I.Standardsprache: Definieren Sie die Hintergrundcodesprache. Sie können zwei Sprachen auswählen: c# und vb.net.
IIdebug: Bei „true“ wird das ASPX-Debugging gestartet; bei „false“ wird das ASPX-Debugging nicht gestartet, wodurch die Leistung der Anwendung verbessert wird, wenn sie ausgeführt wird. Im Allgemeinen setzen Programmierer es bei der Entwicklung auf „true“ und bei der Übergabe an Kunden auf „false“.
4. Format des Abschnitts <customErrors>:
<customErrors
mode="RemoteOnly"
defaultRedirect="error.aspx"
<FehlerstatusCode="440" Redirect="err440page.aspx"/>
<FehlerstatusCode="500" Redirect="err500Page.aspx"/>
/>
I.mode: Es gibt drei Zustände: Ein, Aus und RemoteOnly. Ein bedeutet, dass immer benutzerdefinierte Informationen angezeigt werden. Aus bedeutet, dass immer detaillierte asp.net-Fehlerinformationen angezeigt werden. RemoteOnly bedeutet, dass benutzerdefinierte Informationen nur für Benutzer angezeigt werden, die nicht auf dem lokalen Webserver ausgeführt werden.
II.defaultRedirect: URL-Adresse, die zur Umleitung verwendet wird, wenn ein Fehler auftritt
III.statusCode: Gibt den Fehlerstatuscode an, der auf einen bestimmten Fehlerstatus hinweist.
IV. Weiterleitung: Fehler bei der Umleitung der URL.
5. Format des Abschnitts <Globalisierung>:
<Globalisierung
requestEncoding="utf-8"
ResponseEncoding="utf-8"
fileEncoding="utf-8"
/>
I.requestEncoding: Wird verwendet, um die Codierung jeder eingehenden Anfrage zu überprüfen.
II.responseEncoding: Wird verwendet, um die Inhaltskodierung der zurückgesendeten Antwort zu überprüfen.
III.fileEncoding: Wird verwendet, um die Standardkodierung für ASPX, ASAX und andere Dateianalysen zu überprüfen.
6. Format des Abschnitts <sessionState>:
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
Zeitüberschreitung="20"
/>
I.mode: Unterteilt in Off-, Inproc-, StateServer- und SqlServer-Zustände
mode = InProc wird im Prozess gespeichert. Features: Hat die beste Leistung und schnellste Geschwindigkeit, kann aber nicht über mehrere Server hinweg geteilt werden. mode = „StateServer“ wird im State-Server gespeichert. Features: Wenn Benutzersitzungsinformationen aufrechterhalten werden müssen Server verwenden Sie diese Methode. Die Informationen werden jedoch auf dem Statusserver gespeichert. Mode="SqlServer" geht verloren. Die Arbeitslast wird größer, die Informationen gehen jedoch nicht verloren.
II. stateConnectionString: Geben Sie den Servernamen an, auf dem die asp.net-Anwendung den Remote-Sitzungsstatus speichert.
III.sqlConnectionString: Wenn Sie eine Sitzungsstatusdatenbank verwenden, legen Sie hier die Verbindungszeichenfolge fest
IV. Ohne Cookies: Wenn der Wert auf „true“ gesetzt ist, bedeutet dies, dass der Cookie-Sitzungsstatus nicht zur Identifizierung des Kunden verwendet wird, andernfalls ist das Gegenteil der Fall.
V. TimeOut: Wird verwendet, um die Zeit für die Speicherung des Sitzungsstatus zu definieren. Wenn das Zeitlimit überschritten wird, wird die Sitzung automatisch beendet.
7. Format des Abschnitts <Authentifizierung>:
<authentication mode="Forms">
<forms name=".ASPXUSERDEMO" loginUrl="Login.aspx" Protection="All" timeout="30"/>
</authentication>
<Autorisierung>
<Benutzer verweigern="?"/>
</authorization>
I.Windows: Verwenden Sie die IIS-Authentifizierungsmethode
II.Formulare: Verwendung formularbasierter Validierung
III.Passport: Verwenden Sie den Passport-Cookie-Verifizierungsmodus
IV. Keine: Verwendet keine Überprüfungsmethode. Die Bedeutung der darin eingebetteten Attribute des Formularknotens:
I.Name: Gibt den Namen des HTTP-Cookies an, das zur Vervollständigung der Authentifizierung verwendet wird.
II.LoginUrl: Die Seiten-URL, die umgeleitet wird, wenn die Überprüfung fehlschlägt oder eine Zeitüberschreitung auftritt, normalerweise die Anmeldeseite, damit sich der Benutzer erneut anmelden kann.
III.Schutz: Geben Sie die Schutzmethode für Cookie-Daten an.
Kann eingestellt werden auf: Alle Keine Verschlüsselungsvalidierung Vier Schutzmethoden
a. Alles bedeutet, Daten zu verschlüsseln und ihre Gültigkeit auf zwei Arten zu überprüfen.
b. Keine bedeutet, dass Cookies nicht geschützt sind.
c. Unter Verschlüsselung versteht man die Verschlüsselung von Cookie-Inhalten
d. Unter Validierung versteht man die Überprüfung der Gültigkeit des Cookie-Inhalts
IV. TimeOut: Geben Sie die Cookie-Ablaufzeit an. Melden Sie sich nach dem Timeout erneut an.
Änderungen an der Web.config-Datei zur Laufzeit können ohne Neustart des Dienstes wirksam werden (Hinweis: Ausnahme für den Abschnitt <processModel>). Natürlich ist die Datei Web.config erweiterbar. Sie können neue Konfigurationsparameter anpassen und Konfigurationsabschnittshandler schreiben, um sie zu verarbeiten.
In der Konfigurationsdatei web.config (Standardkonfigurationseinstellungen) sollte sich der gesamte folgende Code befinden
<Konfiguration>
<system.web>
Und
</system.web>
</configuration>
Zu Lernzwecken wird in den folgenden Beispielen dieses XML-Tag weggelassen.
1. Die Rolle des Abschnitts <authentication>: Konfigurieren der asp.NET-Authentifizierungsunterstützung (vier Typen: Windows, Forms, PassPort und None). Dieses Element kann nur auf Computer-, Site- oder Anwendungsebene deklariert werden. Das Element <authentication> muss mit dem Abschnitt <authorization> verwendet werden.
Beispiel:
Das folgende Beispiel ist eine formularbasierte Authentifizierungskonfigurationsseite. Wenn ein nicht angemeldeter Benutzer auf eine Webseite zugreift, die eine Authentifizierung erfordert, springt die Webseite automatisch zur Anmeldewebseite.
<authentication mode="Forms" >
<forms loginUrl="logon.aspx" name=".FormsAuthCookie"/>
</authentication>
Das Element loginUrl stellt den Namen der Anmeldewebseite dar und name stellt den Cookie-Namen dar.
2. Die Rolle des Abschnitts <authorization>: Steuert den Clientzugriff auf URL-Ressourcen (z. B. Ermöglichen des Zugriffs anonymer Benutzer). Dieses Element kann auf jeder Ebene deklariert werden (Computer, Site, Anwendung, Unterverzeichnis oder Seite). Erforderlich in Verbindung mit dem Abschnitt <authentication>.
Beispiel: Das folgende Beispiel deaktiviert den Zugriff für anonyme Benutzer
<Autorisierung>
<Benutzer verweigern="?"/>
</authorization>
Hinweis: Sie können user.identity.name verwenden, um den aktuellen authentifizierten Benutzernamen abzurufen. Sie können die Methode web.Security.FormsAuthentication.RedirectFromLoginPage verwenden, um den authentifizierten Benutzer auf die Seite umzuleiten, die der Benutzer gerade angefordert hat
3. Die Rolle des Abschnitts <compilation>: Konfigurieren Sie alle von asp.NET verwendeten Kompilierungseinstellungen. Das Standard-Debug-Attribut ist „True“. Es sollte auf „False“ gesetzt werden, nachdem das Programm kompiliert und zur Verwendung bereitgestellt wurde (Details werden in der Datei „Web.config“ beschrieben und das Beispiel wird hier weggelassen).
4.<customErrors>
Rolle: Bereitstellung von Informationen zu benutzerdefinierten Fehlermeldungen für asp.NET-Anwendungen. Sie gilt nicht für Fehler, die in XML-Webdiensten auftreten.
Beispiel: Wenn ein Fehler auftritt, springen Sie zu einer benutzerdefinierten Fehlerseite.
<customErrors defaultRedirect="ErrorPage.aspx" mode="RemoteOnly">
</customErrors>
Das Element defaultRedirect stellt den Namen der angepassten Fehler-Webseite dar. Das Moduselement gibt Folgendes an: Zeigt benutzerdefinierte (freundliche) Informationen für Benutzer an, die nicht auf dem lokalen Webserver ausgeführt werden.
5. Die Rolle des Abschnitts <httpRuntime>: Konfigurieren Sie die asp.NET HTTP-Laufzeiteinstellungen. Dieser Abschnitt kann auf Computer-, Standort-, Anwendungs- und Unterverzeichnisebene deklariert werden.
Beispiel: Steuern Sie die maximale Größe von Benutzer-Upload-Dateien auf 4 MB, die maximale Zeit auf 60 Sekunden und die maximale Anzahl von Anfragen auf 100
<httpRuntime maxRequestLength="4096" ExecutionTimeout="60" appRequestQueueLimit="100"/>
6. <Seiten>
Rolle: Identifiziert seitenspezifische Konfigurationseinstellungen (z. B. ob der Sitzungsstatus aktiviert werden soll, der Ansichtsstatus, ob Benutzereingaben erkannt werden sollen usw.). <pages> können auf Computer-, Site-, Anwendungs- und Unterverzeichnisebene deklariert werden.
Beispiel: Erkennen Sie nicht, ob der vom Benutzer im Browser eingegebene Inhalt potenziell gefährliche Daten enthält (Hinweis: Dieses Element wird standardmäßig erkannt. Wenn Sie die Nichterkennung verwenden, müssen Sie die Eingabe des Benutzers verschlüsseln oder überprüfen). Client Der verschlüsselte Ansichtsstatus wird überprüft, wenn die Seite zurückgesendet wird, um sicherzustellen, dass der Ansichtsstatus auf der Clientseite nicht manipuliert wurde. (Hinweis: Dieses Element ist standardmäßig nicht überprüft.)
<pages buffer="true" enableViewStateMac="true" validateRequest="false"/>
7. <sessionState>
Funktion: Konfigurieren Sie Sitzungsstatuseinstellungen für die aktuelle Anwendung (z. B. Festlegen, ob der Sitzungsstatus aktiviert werden soll und wo der Sitzungsstatus gespeichert werden soll).
Beispiel:
<sessionState mode="InProc" cookieless="true" timeout="20"/>
</sessionState>
Notiz:
mode="InProc" bedeutet: Sitzungsstatus lokal speichern (Sie können ihn auch auf einem Remote-Server oder SAL-Server speichern oder den Sitzungsstatus deaktivieren)
cookieless="true" bedeutet: Sitzungsstatus aktivieren, wenn der Browser des Benutzers keine Cookies unterstützt (Standard ist False)
timeout="20" bedeutet: die Anzahl der Minuten, die die Sitzung im Leerlauf sein kann
8. <Trace>
Funktion: Konfigurieren Sie den ASP.NET-Tracking-Dienst, der hauptsächlich zum Testen von Programmen verwendet wird, um festzustellen, wo Fehler auftreten.
Beispiel: Das Folgende ist die Standardkonfiguration in Web.config:
<trace aktiviert="false" requestLimit="10" pageOutput="false" TraceMode="SortByTime" localOnly="true" />
Notiz:
aktiviert="false" bedeutet, dass das Tracking nicht aktiviert wird;
requestLimit="10" gibt die Anzahl der auf dem Server gespeicherten Tracking-Anfragen an
pageOutput="false" bedeutet, dass auf die Trace-Ausgabe nur über das Trace-Dienstprogramm zugegriffen werden kann;
TraceMode="SortByTime" gibt an, dass Ablaufverfolgungsinformationen in der Reihenfolge angezeigt werden, in der Ablaufverfolgungen verarbeitet werden.
localOnly="true" bedeutet, dass der Trace-Viewer (trace.axd) nur für den Host-Webserver verwendet wird. Der Prozess der benutzerdefinierten Web.config-Dateikonfiguration ist in zwei Schritte unterteilt.
1. Deklarieren Sie den Namen des Konfigurationsabschnitts und den Namen der .NET Framework-Klasse, die die Konfigurationsdaten verarbeitet, im Abschnitt zwischen den Tags <configSections> und </configSections> oben in der Konfigurationsdatei.
2. Nehmen Sie die tatsächlichen Konfigurationseinstellungen für den deklarierten Abschnitt nach dem Bereich <configSections> vor.
Beispiel: Erstellen Sie einen Abschnitt zum Speichern von Datenbankverbindungszeichenfolgen
<Konfiguration>
<configSections>
<section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</configSections>
<appSettings>
<add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/>
</appSettings>
<system.web>
...
</system.web>
</configuration>
Zugreifen auf die Datei „Web.config“ Sie können auf die Datei „Web.config“ zugreifen, indem Sie die statische Zeichenfolgensammlung „ConfigurationSettings.AppSettings“ verwenden. Beispiel: Rufen Sie die im obigen Beispiel eingerichtete Verbindungszeichenfolge ab. Zum Beispiel:
geschützte statische Zeichenfolge Isdebug = ConfigurationSettings.AppSettings["debug"]
2. Detaillierte Erläuterung der Sitzungskonfiguration in web.config Nach dem Öffnen der Konfigurationsdatei Web.config einer Anwendung finden wir den folgenden Absatz:
< sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
Zeitüberschreitung="20"
/>
In diesem Abschnitt wird konfiguriert, wie die Anwendung Sitzungsinformationen speichert. Unsere verschiedenen nachstehenden Operationen konzentrieren sich hauptsächlich auf diese Konfiguration. Werfen wir zunächst einen Blick auf die Bedeutung des in dieser Konfiguration enthaltenen Inhalts. Die Syntax des sessionState-Knotens lautet wie folgt:
< sessionState mode="Off|InProc|StateServer|SQLServer"
cookieless="true|false"
timeout="Anzahl der Minuten"
stateConnectionString="tcpip=server:port"
sqlConnectionString="SQL-Verbindungszeichenfolge"
stateNetworkTimeout="Anzahl der Sekunden"
/>
Die erforderlichen Attribute sind: Attributoptionsbeschreibung
Der Modus legt fest, wo Sitzungsinformationen gespeichert werden sollen
Ø Aus ist eingestellt, um die Sitzungsfunktion nicht zu verwenden.
Ø InProc ist so eingestellt, dass die Sitzung im Prozess gespeichert wird. Dies ist die Speichermethode in asp.
Ø StateServer ist so eingestellt, dass die Sitzung in einem unabhängigen Statusdienst gespeichert wird.
Ø SQLServer-Einstellungen speichern die Sitzung im SQL Server.
Optionale Attribute sind: Attributoptionsbeschreibung
Ø Cookieless-Sets, in denen die Sitzungsinformationen des Kunden gespeichert werden,
Ø ture verwendet den Cookieless-Modus,
Ø false Cookie-Modus verwenden, dies ist der Standardwert,
Ø Timeout legt die Anzahl der Minuten fest, nach denen der Server automatisch Sitzungsinformationen aufgibt. Der Standardwert beträgt 20 Minuten.
stateConnectionString legt den Servernamen und die Portnummer fest, die beim Speichern von Sitzungsinformationen im Statusdienst verwendet werden, zum Beispiel: „tcpip=127.0.0.1:42424“. Dieses Attribut ist erforderlich, wenn der Wert von mode StateServer ist.
sqlConnectionString legt die Verbindungszeichenfolge fest, wenn eine Verbindung zum SQL-Server hergestellt wird. Zum Beispiel „Datenquelle=localhost;Integrated Security=SSPI;Initial Catalog=northwind“. Dieses Attribut ist erforderlich, wenn der Wert von mode SQLServer ist.
stateNetworkTimeout legt die Anzahl der Leerlaufsekunden fest, nach denen die TCP/IP-Verbindung zwischen dem Webserver und dem Server, der die Statusinformationen speichert, getrennt wird, wenn der StateServer-Modus zum Speichern des Sitzungsstatus verwendet wird. Der Standardwert beträgt 10 Sekunden.
Die Speicherung des Client-Sitzungsstatus in asp.NET wird in unserer Einführung zum Sitzungsmodell oben gezeigt. Sie können feststellen, dass der Sitzungsstatus an zwei Orten gespeichert werden sollte, nämlich am Client und am Server. Der Client ist nur für die Speicherung der SessionID der entsprechenden Website verantwortlich, während andere Sitzungsinformationen serverseitig gespeichert werden. In ASP wird die SessionID des Clients tatsächlich in Form eines Cookies gespeichert. Wenn sich der Benutzer dafür entscheidet, Cookies in den Browsereinstellungen zu deaktivieren, kann er den Komfort der Sitzung nicht genießen und möglicherweise sogar nicht auf bestimmte Websites zugreifen. Um die oben genannten Probleme zu lösen, ist die Methode zum Speichern von Sitzungsinformationen des Clients in asp.NET in zwei Typen unterteilt: Cookie und Cookieless.
In asp.NET werden Cookies standardmäßig weiterhin zum Speichern von Sitzungsinformationen auf dem Client verwendet. Wenn wir Cookieless zum Speichern von Sitzungsinformationen auf dem Client verwenden möchten, ist die Methode wie folgt:
Suchen Sie das Stammverzeichnis der aktuellen Webanwendung, öffnen Sie die Datei Web.Config und suchen Sie den folgenden Absatz:
< sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
Zeitüberschreitung="20"
/>
Das Cookieless="false" in diesem Absatz wird geändert in: cookieless="true". Auf diese Weise werden die Sitzungsinformationen des Clients nicht mehr mithilfe von Cookies, sondern über die URL gespeichert. Schließen Sie den aktuellen IE, öffnen Sie einen neuen IE und besuchen Sie die Webanwendung erneut. Sie werden etwas Ähnliches wie das Folgende sehen:
Darunter ist die Sitzungs-ID des Clients, die in http://localhost/MyTestApplication/(ulqsek45heu3ic2a5zgdl245 )/default.aspx fett markiert ist. Beachten Sie, dass diese Informationen automatisch von IIS hinzugefügt werden und keine Auswirkungen auf frühere normale Verbindungen haben.
Vorbereitungen zum Speichern des Sitzungsstatus auf der Serverseite in asp.NET:
Damit Sie das experimentelle Phänomen besser erleben können, können Sie eine Seite mit dem Namen SessionState.aspx erstellen und dann die folgenden Codes zu <body></body> hinzufügen.
<scriptrunat="server">
Sub Session_Add(sender als Objekt, e als EventArgs)
session("MySession") = text1.Value
span1.InnerHtml = „Sitzungsdaten aktualisiert! < P>Ihre Sitzung enthält: <font color=red>“ & session(“ToString() & „< /font>“).
Sub beenden
Sub CheckSession(sender As Object, eAs EventArgs)
If (Session("MySession")Is Nothing) Then
span1.InnerHtml = „NICHT, Sitzungsdaten verloren!“
Anders
span1.InnerHtml = „Ihre Sitzung enthält: <font color= red>“ & session(“MySession“).ToString() & „< /font>“
Ende wenn
Sub beenden
</script>
< formrunat="server"id="Form2">
< inputid="text1"type="text"runat="server"name="text1">
< inputtype="submit"runat="server"OnServerClick="Session_Add"
value="Zum Sitzungsstatus hinzufügen" id="Submit1"name="Submit1">
< inputtype="submit"runat="server"OnServerClick="CheckSession"
value="Sitzungsstatus anzeigen" id="Submit2"name="Submit2">
< /form>
< hrsize="1">
<fontsize="6">< spanid="span1"runat="server" />< /font>
Mit der Seite „SessionState.aspx“ können Sie testen, ob Sitzungsinformationen auf dem aktuellen Server verloren gehen.
Speichern von Serversitzungsinformationen im Prozess Kehren wir zum vorherigen Absatz der Web.config-Datei zurück:
< sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
Zeitüberschreitung="20"
/>
Wenn der Wert von mode „InProc“ ist, zeigt dies an, dass der Server diesen Modus verwendet.
Diese Methode entspricht dem vorherigen Modus in ASP, dh der Server speichert Sitzungsinformationen im IIS-Prozess. Wenn IIS heruntergefahren und neu gestartet wird, gehen diese Informationen verloren. Dieser Modus hat aber auch seinen größten Vorteil, nämlich die höchste Leistung. Da alle Sitzungsinformationen im IIS-Prozess gespeichert werden, kann IIS schnell auf diese Informationen zugreifen. Die Leistung dieses Modus ist schneller als das Speichern von Sitzungsinformationen außerhalb des Prozesses oder das Speichern von Sitzungsinformationen in großen Mengen. Dieser Modus ist auch die Standardmethode von asp.NET.
Okay, jetzt machen wir ein Experiment. Öffnen Sie gerade die Seite SessionState.aspx und geben Sie einige Zeichen ein, um sie in der Sitzung zu speichern. Dann starten wir IIS neu. Beachten Sie, dass es nicht darum geht, die aktuelle Site zu stoppen und neu zu starten, sondern dass Sie mit der rechten Maustaste auf den Knoten mit dem Namen des lokalen Computers in IIS klicken und „IIS neu starten“ auswählen müssen. (Ich glaube, als ich NT4 verwendet habe, musste ich den Computer neu starten, um IIS neu zu starten. Microsoft ist wirklich @#$%^&) Kehren Sie zur Seite SessionState.aspx zurück, überprüfen Sie gerade die Sitzungsinformationen und stellen Sie fest, dass die Informationen vorhanden sind verloren.
Speichern von Serversitzungsinformationen außerhalb des Prozesses Öffnen wir zunächst die Verwaltungstools -> Dienste, suchen Sie den Dienst mit dem Namen „asp.NET State Service“ und starten Sie ihn. Tatsächlich startet dieser Dienst einen Prozess zum Speichern von Sitzungsinformationen. Nach dem Starten dieses Dienstes können Sie im Windows Task-Manager -> Prozesse einen Prozess mit dem Namen aspnet_state.exe sehen. Dies ist der Prozess, in dem wir Sitzungsinformationen speichern.
Gehen Sie dann zurück zum obigen Absatz in der Datei Web.config und ändern Sie den Moduswert in StateServer. Öffnen Sie nach dem Speichern der Datei erneut einen IE, öffnen Sie die Seite SessionState.aspx und speichern Sie einige Informationen in der Sitzung. Lassen Sie uns zu diesem Zeitpunkt IIS neu starten und zur Seite SessionState.aspx zurückkehren, um die Sitzungsinformationen zu überprüfen und festzustellen, dass sie nicht verloren gegangen sind.
Tatsächlich bedeutet diese Art der Speicherung von Sitzungsinformationen außerhalb des Prozesses nicht nur, dass die Informationen außerhalb des Prozesses des lokalen Computers gespeichert werden können, sondern auch, dass die Sitzungsinformationen in den Prozessen anderer Server gespeichert werden können. Zu diesem Zeitpunkt müssen Sie nicht nur den Moduswert in StateServer ändern, sondern auch die entsprechenden Parameter in stateConnectionString konfigurieren. Ihre Berechnung lautet beispielsweise 192.168.0.1. Wenn Sie die Sitzung im Prozess des Computers mit der IP-Adresse 192.168.0.2 speichern möchten, müssen Sie sie wie folgt festlegen: stateConnectionString="tcpip=192.168.0.2:42424". Vergessen Sie natürlich nicht, das .NET Framework auf dem Computer 192.168.0.2 zu installieren und den Dienst asp.NET State Services zu starten.
Speichern von Serversitzungsinformationen in SQL Server Lassen Sie uns zunächst einige vorbereitende Arbeiten durchführen. Starten Sie die SQL Server- und SQL Server-Proxy-Dienste. Führen Sie eine Skriptdatei namens InstallSqlState.sql auf dem SQL Server aus. Diese Skriptdatei erstellt in SQL Server eine Datenbank speziell zum Speichern von Sitzungsinformationen und einen SQL Server-Agentenauftrag, der die Sitzungsinformationsdatenbank verwaltet. Wir finden diese Datei im folgenden Pfad:
[Systemlaufwerk]winntMicrosoft.NETFramework[Version]
Öffnen Sie dann den Abfrageanalysator, stellen Sie eine Verbindung zum SQL-Server her, öffnen Sie die Datei gerade und führen Sie sie aus. Warten Sie einen Moment und die Datenbank und der Job werden erstellt. Zu diesem Zeitpunkt können Sie den Enterprise Manager öffnen und sehen, dass eine neue Datenbank namens ASPState hinzugefügt wurde. Diese Datenbank enthält jedoch nur einige gespeicherte Prozeduren und keine Benutzertabelle. Tatsächlich werden die Sitzungsinformationen in der ASPStateTempSessions-Tabelle der tempdb-Datenbank gespeichert, und eine andere ASPStateTempApplications-Tabelle speichert die Anwendungsobjektinformationen in asp. Diese beiden Tabellen wurden gerade auch vom Skript erstellt. Überprüfen Sie außerdem Management->SQL Server Agent->Jobs und stellen Sie fest, dass es auch einen zusätzlichen Job namens ASPState_Job_DeleteExpiredSessions gibt. Dieser Job löscht tatsächlich jede Minute abgelaufene Sitzungsinformationen aus der ASPStateTempSessions-Tabelle.
Als nächstes kehren wir zur Datei Web.config zurück und ändern den Moduswert in SQLServer. Beachten Sie, dass Sie gleichzeitig auch den Wert von sqlConnectionString ändern müssen. Das Format ist:
sqlConnectionString="data source=localhost; Integrated Security=SSPI;"
Die Datenquelle bezieht sich auf die IP-Adresse des SQL-Servers. Wenn der SQL-Server und IIS derselbe Computer sind, schreiben Sie einfach 127.0.0.1. Integrierte Sicherheit=SSPI bedeutet, dass der Zugriff auf die Datenbank als asp.NET erfolgt. Durch diese Konfiguration können Sie eine bessere Sicherheit als mit der SQL-Server-Authentifizierungsmethode mit userid=sa;password=password erreichen . Wenn der SQL-Server auf einem anderen Computer ausgeführt wird, müssen Sie möglicherweise die Konsistenz der Authentifizierung auf beiden Seiten über die Active Directory-Domäne aufrechterhalten.
Machen wir noch einmal ein Experiment. Fügen Sie Sitzungsinformationen zu SessionState.aspx hinzu und stellen Sie dann fest, dass die Sitzungsinformationen bereits auf dem SQL Server vorhanden sind. Auch wenn Sie den Computer neu starten, gehen die Sitzungsinformationen nicht verloren. Jetzt haben Sie vollständig gesehen, wie die Sitzungsinformationen aussehen und in SQL Server gespeichert sind. Was Sie tun können, hängt von Ihrer Leistung ab.
Zusammenfassung 3. Allgemeine Einstellungen der asp.net-Formularauthentifizierung
Allgemeine Einstellungen für die asp.net-Formularauthentifizierung:
1: Fügen Sie in web.config die Formularauthentifizierung hinzu;
<authentication mode="Forms">
<forms name="auth" loginUrl="index.aspx" timeout="30"></forms>
</authentication>
<Autorisierung>
<Benutzer verweigern="?" />
</authorization>
2: Wenn eine Registrierungsseite vorhanden ist, sollte es anonymen Benutzern gestattet sein, die Registrierungsseite aufzurufen, um sich zu registrieren.
Der folgende Code sollte zwischen <configuration><system.web> liegen und nicht zwischen <system.web>..</system.web> enthalten sein;
----------------Gibt an, dass anonyme Benutzer auf die Seite „userReg.aspx“ zugreifen dürfen.
<location path="userReg.aspx">
<system.web>
<Autorisierung>
<Benutzer zulassen="?" />
</authorization>
</system.web>
</location>
3. Nach erfolgreicher Anmeldung muss ein Identitätsprüfungsticket erstellt werden, um anzugeben, dass der authentifizierte rechtmäßige Benutzer bestanden hat.
if (Anmeldung erfolgreich)
System.Web.Security.FormsAuthentication.SetAuthCookie(username, false);
4. Greifen Sie auf die Datei Web.config zu, indem Sie die statische Zeichenfolgensammlung „ConfigurationSettings.AppSettings“ verwenden. Beispiel: Rufen Sie die im obigen Beispiel eingerichtete Verbindungszeichenfolge ab. Zum Beispiel:
geschützte statische Zeichenfolge Isdebug = ConfigurationSettings.AppSettings["scon"]
asp.Net-Leistungsoptimierung.
(1). Wählen Sie die Speichermethode für den Sitzungsstatus aus
Konfigurieren Sie in der Webconfig-Datei:
<sessionState mode="???" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false" timeout="20"/>
ASP.NET bietet drei Möglichkeiten zum Speichern von Sitzungsstatusinformationen:
1. Im Prozess gespeichert: Attributmodus = InProc
Eigenschaften: Es bietet die beste Leistung und die schnellste Geschwindigkeit, kann jedoch nicht auf mehrere Server verteilt werden.
2. Im Statusserver gespeichert: Attribut mode = „StateServer“
Funktionen: Verwenden Sie diese Methode, wenn Benutzersitzungsinformationen serverübergreifend verwaltet werden müssen.
Die Informationen werden jedoch auf dem Staatsserver gespeichert, und sobald der Staatsserver ausfällt, gehen die Informationen verloren
3. Auf dem SQL-Server gespeichert: Attribut mode="SqlServer"
Merkmale: Der Arbeitsaufwand wird größer, die Informationen gehen jedoch nicht verloren.
Noch etwas:
I. Da für einige Seiten kein Sitzungsstatus erforderlich ist, kann der Sitzungsstatus deaktiviert werden:
Der Code lautet wie folgt: <%@ Page EnableSessionState="false" %>
II. Wenn die Seite auf Sitzungsvariablen zugreifen muss, diese aber nicht ändern darf, können Sie den Sitzungsstatus der Seite auf schreibgeschützt setzen:
Der Code lautet wie folgt: <%@ Page EnableSessionState="false" %>
Bei der Verwendung können Sie je nach Situation eine bestimmte Methode auswählen
(2).Verwenden Sie Page.IsPostBack
Page.IsPostBack gibt an, ob es vom Client zurückgegeben wird. Bei der ersten Ausführung wird der Wert nicht vom Client zurückgegeben
Ist falsch, wenn ein Ereignis auf der Seite ausgelöst oder die Seite aktualisiert wird, wird der Wert von Page.IsPostBack wahr, da es sich um ein Postback handelt;
Wird im Allgemeinen verwendet in: Page_Load-Methode:
private void Page_Load(Object sender,EventArgs e)
{
if(!Page.IsPostBack)
{
....; //Code zum Initialisieren der Seite. Diese Codes werden ausgeführt, wenn die Seite zum ersten Mal initialisiert wird und wenn sie zum zweiten Mal zurückgesendet wird.
//Wird nicht noch einmal ausgeführt. Verbessern Sie die Effizienz.
}
}
Oft muss IsPostBack verwendet werden, da einige Steuerelemente ihren Status nach der Initialisierung beibehalten müssen.
Beispiel: DropDownList: Wenn es jedes Mal initialisiert wird, wird es unabhängig von der vom Benutzer ausgewählten Option auf den Standardwert initialisiert.
(3). Vermeiden Sie die Verwendung von Serversteuerelementen
1. Versuchen Sie für die Anzeige allgemeiner statischer Informationen, keine serverseitigen Steuerelemente zu verwenden, da serverseitige Steuerelemente zur Ausführung an den Server zurückgesendet werden müssen.
Dies verringert die Effizienz der Programmausführung und kann im Allgemeinen mit <DIV> angezeigt werden.
Wenn serverseitige Steuerelemente verwendet werden, verbessert das Entfernen von: runat="server" auch die Effizienz.
2. Deaktivieren Sie die Statusansicht serverseitiger Steuerelemente. Sie können ihre Eigenschaften festlegen: EnableViewState=false;
Wenn das gesamte Seitensteuerelement keine Statusansicht aufrechterhalten muss, können Sie die Statusansicht der gesamten Seite auf „false“ setzen:
Der Code lautet wie folgt: <%@ Page EnableViewState="false"%>
3. Konfigurieren Sie in der Web.Config-Datei:
asp.NET-Sitzungen können im Sessionsstate-Element in Web.config oder Machine.config konfiguriert werden.
Hier ist ein Beispiel für die Einstellungen in Web.config:
<Sessionsstate timeout="10" cookieless="false" mode="Inproc" />
(4). Vermeiden Sie die Verwendung von DataGrid
Jeder weiß, dass DataGrid leistungsstark ist. Obwohl es leistungsstark ist, erhöht es jedoch auch den Leistungsaufwand. Verwenden Sie im Allgemeinen andere Steuerelemente: DataList
Oder die Repeater-Steuerung kann dies erreichen. Versuchen Sie, DataGrid nicht zu verwenden.
(5).String-Operationen
1. Vermeiden Sie Verpackungsvorgänge, die weniger effizient sind.
Führen Sie beispielsweise zwei Codeausschnitte aus:
string test="";
for(for int i=0;i<10000;i++)
{
test = test + i;
}
Und
string test="";
for(for int i=0;i<10000;i++)
{
test = test + i.ToString();
}
Das folgende Code-Snippet ist offensichtlich effizienter. Da es sich um eine Ganzzahl handelt, muss das System vor dem Herstellen einer Verbindung zunächst i in einen String-Typ umwandeln.
Leser können es auf ihre eigenen Rechner kopieren und testen.
2. Verwenden Sie die StringBulider-Klasse
Bei der Durchführung einer String-Verkettung: string str = str1 + str2 + ....;
Im Allgemeinen ist es bei mehr als drei Verbindungen am besten, StringBuilder anstelle der String-Klasse zu verwenden, um die Neuerstellung von String-Objekten zu vermeiden.
Leistungsverlust.
Wird im Allgemeinen beim Zusammenstellen von SQL-Anweisungen verwendet: StringBulider.
Leser können es auf ihren eigenen Maschinen testen.
3. So wenig wie möglich verwenden:
versuchen
{}
fangen
{}
Endlich
{}
Anweisung Die Ausführungseffizienz dieser Anweisung ist relativ gering.
(6) Optimierung der ADO.Net-Nutzung
1. Datenbankverbindungen werden geöffnet und geschlossen. Öffnen Sie es, wenn eine Verbindung benötigt wird, und schließen Sie die Verbindung sofort nach dem Zugriff auf die Datenbank.
Schauen wir uns zum Beispiel zwei Codeausschnitte an:
ICH.
DataSet ds = new DataSet();
SqlConnection MyConnection = new SqlConnection("server=localhost; uid=sa; pwd=; Database=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
MyConnection.Open(); //Verbindung öffnen
for(int i=0;i<1000;i++) //for-Schleife simuliert Geschäftslogikoperationen vor dem Abrufen von Daten
{
Thread.Sleep(1000);
}
myAdapter.Fill(ds);
for(int i=0;i<1000;i++) //for-Schleife simuliert Geschäftslogikoperationen nach dem Abrufen von Daten
{
Thread.Sleep(1000);
}
MyConnection.Close(); //Verbindung schließen
II.
DataSet ds = new DataSet();
SqlConnection MyConnection = new SqlConnection("server=localhost; uid=sa; pwd=; Database=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
for(int i=0;i<1000;i++) //for-Schleife simuliert Geschäftslogikoperationen vor dem Abrufen von Daten
{
Thread.Sleep(1000);
}
MyConnection.Open(); //Verbindung öffnen
myAdapter.Fill(ds);
MyConnection.Close(); //Verbindung schließen
for(int i=0;i<1000;i++) ////Die for-Schleife simuliert die Geschäftslogikoperation nach dem Abrufen der Daten
{
Thread.Sleep(1000);
}
Der Display-II-Code ist viel besser als der I-Code. Der I-Code belegt die Verbindung früh. Wenn es viele Benutzer gibt, ist der Verbindungspool wahrscheinlich voll. In schweren Fällen kann es zu einem Absturz kommen.
2. Datenbankabfrage
I. SQL-Anweisungen direkt generieren. SQL Server muss es jedes Mal kompilieren, und es wird keine große Leistungsverbesserung geben. Darüber hinaus ist es nicht sicher genug. Leicht angreifbar.
II. Verwenden Sie den SQL-Befehl mit Parametern. Auf diese Weise kompiliert SQL Server es nur einmal und die kompilierten Befehle können für verschiedene Parameter wiederverwendet werden. Verbesserte Leistung.
III. Einmaliges Kompilieren von SQL-Servern. Es kann die Funktion des mehrfachen Sendens von Anweisungen erfüllen.
fließen. Gespeicherte Prozeduren sind nicht unbedingt effizienter als Anweisungen. Wenn die Geschäftslogik sehr komplex ist, sind Anweisungen manchmal effizienter als gespeicherte Prozeduren.
(6). Cache-Optimierung
Es gibt zwei Arten von Cache: Seitencache und API-Cache.
1. Verwenden Sie Seiten-Caching und Fragment-Caching
<%@ OutputCache Duration="5" VaryByParam="None"%>
<%@ OutputCache Duration=60 VaryByParam=“TextBox1,TextBox2“ %>
Hinweis: Mit der Dauer wird die Ablaufzeit des Caches festgelegt.
VarByParam gibt an, ob sich die Einstellung je nach Parameter ändert. Wenn „Keine“ vorhanden ist, verwenden alle Parameter denselben Cache.
Wenn Sie TextBox1 festlegen, werden sie entsprechend den verschiedenen Werten von TextBox1 separat zwischengespeichert. Wenn mehrere Parameter vorhanden sind, werden sie in Kombination zwischengespeichert.
2.API-Cache. für den Einsatz in Anwendungen
I. Ein Beispiel für die Cache-Nutzung:
http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx
II. Achten Sie bei der Verwendung auf den Unterschied zwischen Page.Cache und HttpContext.Current.Cache:
Sie verweisen auf dasselbe Objekt. Wenn Sie es in global.asax oder Ihrer eigenen Klasse verwenden, verwenden Sie in einigen Fällen HttpRuntime.Cache.
