Explication détaillée de Web.config + optimisation asp.net
Auteur：Eve Cole
Date de mise à jour：2009-07-01 16:44:14
1. Comprendre le fichier Web.config
Le fichier Web.config est un fichier texte XML utilisé pour stocker les informations de configuration de l'application Web asp.NET (telles que la méthode d'authentification la plus couramment utilisée pour configurer l'application Web asp.NET). Il peut apparaître dans chaque application Web. étape de l’application dans le répertoire. Lorsque vous créez une nouvelle application Web via .NET, un fichier Web.config par défaut est automatiquement créé dans le répertoire racine par défaut, y compris les paramètres de configuration par défaut, et tous les sous-répertoires héritent de ses paramètres de configuration. Si vous souhaitez modifier les paramètres de configuration d'un sous-répertoire, vous pouvez créer un nouveau fichier Web.config dans le sous-répertoire. Il peut fournir des informations de configuration en plus des informations de configuration héritées du répertoire parent, et peut également remplacer ou modifier les paramètres définis dans le répertoire parent.
(1) .Web.Config est stocké dans la spécification du fichier XML et le fichier de configuration est divisé dans les formats suivants
1. Caractéristiques de la déclaration du gestionnaire de section de configuration : située en haut du fichier de configuration et contenue dans la balise <configSections>.
2. Fonctionnalités spécifiques de configuration de l'application : Situées dans <appSetting>. Vous pouvez définir des informations telles que les paramètres de constante globale pour l'application.
3. Fonctionnalités de configuration de la section de configuration : située dans la section <system.Web>, elle contrôle le comportement du runtime asp.net.
4. Caractéristiques des groupes de sections de configuration : à l'aide de la balise <sectionGroup>, vous pouvez personnaliser le regroupement et le placer dans <configSections> ou dans d'autres balises <sectionGroup>.
(2). Chaque section de la section de configuration
1.<configuration> élément racine de la section, d'autres sections se trouvent à l'intérieur.
2. Section <appSetting> Cette section est utilisée pour définir les paramètres de l'application. Pour certains paramètres incertains, les utilisateurs peuvent également définir leur propre utilisation en fonction de leur situation réelle :
I.<appSettings>
<add key="Conntction" value="server=192.168.85.66;userid=sa;password=;database=Info;"/>
<paramètres de l'application>
Une constante de chaîne de connexion est définie et la chaîne de connexion peut être modifiée dans les applications réelles sans modifier le code du programme.
II.<paramètres de l'application>
<add key="ErrPage" value="Error.aspx"/><appSettings> définit une page de redirection d'erreur.
3.Format de la section <compilation> :
<compilation
langue par défaut="c#"
débogage = "vrai"
/>
I.langue par défaut : définissez la langue du code d'arrière-plan, vous pouvez choisir deux langues : c# et vb.net.
IIdebug : lorsque vrai, le débogage aspx est démarré ; lorsqu'il est faux, le débogage aspx n'est pas démarré, améliorant ainsi les performances de l'application lorsqu'elle est en cours d'exécution. Généralement, les programmeurs le définissent sur true lors du développement et sur false lorsqu'ils le transmettent aux clients.
4. Format de la section <customErrors> :
<erreurspersonnalisées
mode="RemoteOnly"
defaultRedirect="erreur.aspx"
<error statusCode="440" redirect="err440page.aspx"/>
<error statusCode="500" redirect="err500Page.aspx"/>
/>
I.mode : Il a 3 états : On, Off et RemoteOnly. On signifie que les informations personnalisées sont toujours affichées ; Off signifie que les informations détaillées sur les erreurs asp.net sont toujours affichées ; RemoteOnly signifie que les informations personnalisées ne sont affichées que pour les utilisateurs qui n'exécutent pas sur le serveur Web local.
II.defaultRedirect : adresse URL utilisée pour rediriger lorsqu'une erreur se produit. Facultatif.
III.statusCode : indique le code d'état d'erreur, indiquant un état d'erreur spécifique.
IV. redirection : URL de redirection d'erreur.
5.Format de la section <mondialisation> :
<mondialisation
requestEncoding="utf-8"
réponseEncoding="utf-8"
fichierEncodage="utf-8"
/>
I.requestEncoding : Il permet de vérifier l'encodage de chaque requête entrante.
II.responseEncoding : utilisé pour vérifier l'encodage du contenu de la réponse renvoyée.
III.fileEncoding : utilisé pour vérifier l'encodage par défaut pour l'aspx, l'asax et d'autres analyses de fichiers.
6.Format de la section<sessionState> :
<étatdesession
mode="EnProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="source de données=127.0.0.1;Trusted_Connection=oui"
sans cookie = "faux"
délai d'attente = "20"
/>
I.mode : divisé en états off, Inproc, StateServer, SqlServer
mode = InProc est stocké dans le processus. Caractéristiques : offre les meilleures performances et la vitesse la plus rapide, mais ne peut pas être partagé sur plusieurs serveurs. mode = "StateServer" est stocké dans le serveur d'état. Caractéristiques : lorsque les informations de session utilisateur doivent être conservées sur plusieurs serveurs. serveurs, utilisez cette méthode. Cependant, les informations sont stockées sur le serveur d'état. Une fois le serveur d'état défaillant, les informations seront perdues. Mode="SqlServer" est stocké dans le serveur SQL. Caractéristiques : La charge de travail deviendra plus importante, mais les informations ne seront pas perdues.
II. stateConnectionString : spécifiez le nom du serveur sur lequel l'application asp.net stocke l'état de la session distante. La valeur par défaut est la machine locale.
III.sqlConnectionString : lors de l'utilisation d'une base de données d'état de session, définissez la chaîne de connexion ici
IV. Sans cookie : lorsqu'il est défini sur true, cela signifie que l'état de la session du cookie n'est pas utilisé pour identifier le client, sinon c'est le contraire qui est vrai.
V. TimeOut : utilisé pour définir la durée de stockage de l'état de la session. Si la limite de temps est dépassée, la session sera automatiquement terminée.
7. Format de la section <authentification> :
<mode d'authentification="Formulaires">
<forms name=".ASPXUSERDEMO" loginUrl="Login.aspx" protection="All" timeout="30"/>
</authentification>
<autorisation>
<refuser les utilisateurs="?"/>
</autorisation>
I.Windows : Utiliser la méthode d'authentification IIS
II.Forms : utilisation de la validation basée sur des formulaires
III.Passport : Utiliser le mode de vérification des cookies du Passeport
IV.Aucun : n'utilise aucune méthode de vérification. La signification des attributs du nœud Forms qui y est intégré :
I.Name : Spécifie le nom du cookie HTTP utilisé pour terminer l'authentification.
II.LoginUrl : l'URL de la page qui est redirigée si la vérification échoue ou expire, généralement la page de connexion, permettant à l'utilisateur de se reconnecter.
III.Protection : Précisez le mode de protection des données des cookies.
Peut être défini sur : Tous Aucun Chiffrement Validation Quatre méthodes de protection
a. Tout signifie chiffrer les données et effectuer une vérification de validité de deux manières.
b. Aucun signifie que les cookies ne sont pas protégés.
c. Le cryptage signifie le cryptage du contenu des cookies
d. La validation signifie vérifier la validité du contenu des cookies
IV. TimeOut : Spécifiez le délai d'expiration du cookie. Reconnectez-vous après l'expiration du délai.
Les modifications apportées au fichier Web.config au moment de l'exécution peuvent prendre effet sans redémarrer le service (Remarque : exception pour la section <processModel>). Bien entendu, le fichier Web.config est extensible. Vous pouvez personnaliser de nouveaux paramètres de configuration et écrire des gestionnaires de section de configuration pour les gérer.
Le fichier de configuration web.config (paramètres de configuration par défaut), tout le code suivant doit être situé dans
<configuration>
<système.web>
et
</system.web>
</configuration>
À des fins d'apprentissage, les exemples suivants omettent cette balise XML.
1. Le rôle de la section <authentication> : configurer la prise en charge de l'authentification asp.NET (quatre types : Windows, Forms, PassPort et Aucun). Cet élément ne peut être déclaré qu'au niveau de l'ordinateur, du site ou de l'application. L'élément <authentication> doit être utilisé avec la section <authorization>.
Exemple:
L'exemple suivant est un site de configuration d'authentification basée sur un formulaire Lorsqu'un utilisateur non connecté accède à une page Web nécessitant une authentification, la page Web passe automatiquement à la page Web de connexion.
<mode d'authentification="Formulaires" >
<forms loginUrl="logon.aspx" name=".FormsAuthCookie"/>
</authentification>
L'élément loginUrl représente le nom de la page Web de connexion et name représente le nom du cookie.
2. Le rôle de la section <authorization> : contrôle l'accès du client aux ressources URL (par exemple, autoriser l'accès des utilisateurs anonymes). Cet élément peut être déclaré à n'importe quel niveau (ordinateur, site, application, sous-répertoire ou page). Requis en conjonction avec la section <authentification>.
Exemple : L'exemple suivant désactive l'accès aux utilisateurs anonymes
<autorisation>
<refuser les utilisateurs="?"/>
</autorisation>
Remarque : Vous pouvez utiliser user.identity.name pour obtenir le nom d'utilisateur authentifié actuel ; vous pouvez utiliser la méthode web.Security.FormsAuthentication.RedirectFromLoginPage pour rediriger l'utilisateur authentifié vers la page spécifique que l'utilisateur vient de demander.
3. Le rôle de la section <compilation> : configurer tous les paramètres de compilation utilisés par asp.NET. L'attribut de débogage par défaut est "True". Il doit être défini sur False une fois le programme compilé et livré pour utilisation (les détails sont décrits dans le fichier Web.config et l'exemple est omis ici)
4.<customErrors>
Rôle : fournir des informations sur les messages d'erreur personnalisés pour les applications asp.NET. Cela ne s'applique pas aux erreurs survenant dans les services Web XML.
Exemple : lorsqu'une erreur se produit, accédez à une page d'erreur personnalisée.
<customErrors defaultRedirect="ErrorPage.aspx" mode="RemoteOnly">
</customErreurs>
L'élément defaultRedirect représente le nom de la page Web d'erreur personnalisée. L'élément mode indique : afficher des informations personnalisées (conviviales) aux utilisateurs qui n'exécutent pas sur le serveur Web local.
5. Le rôle de la section <httpRuntime> : configurer les paramètres d'exécution HTTP asp.NET. Cette section peut être déclarée au niveau de l'ordinateur, du site, de l'application et du sous-répertoire.
Exemple : Contrôlez la taille maximale des fichiers téléchargés par l'utilisateur à 4 Mo, la durée maximale à 60 secondes et le nombre maximal de requêtes à 100.
<httpRuntime maxRequestLength="4096" exécutéTimeout="60" appRequestQueueLimit="100"/>
6. <pages>
Rôle : identifie les paramètres de configuration spécifiques à la page (par exemple, s'il faut activer l'état de session, afficher l'état, détecter les entrées de l'utilisateur, etc.). Les <pages> peuvent être déclarées au niveau de l'ordinateur, du site, de l'application et du sous-répertoire.
Exemple : ne détectez pas s'il existe des données potentiellement dangereuses dans le contenu saisi par l'utilisateur dans le navigateur (Remarque : cet élément est détecté par défaut. Si vous utilisez la non-détection, vous devez encoder ou vérifier la saisie de l'utilisateur). client L'état d'affichage chiffré est vérifié lorsque la page est publiée pour vérifier que l'état d'affichage n'a pas été falsifié du côté client. (Remarque : cet élément n'est pas vérifié par défaut)
<pages buffer="true" activateViewStateMac="true" validateRequest="false"/>
7. <état de session>
Fonction : configurer les paramètres d'état de session pour l'application actuelle (par exemple, définir s'il faut activer l'état de session et où enregistrer l'état de session).
Exemple:
<sessionState mode="InProc" cookieless="true" timeout="20"/>
</étatdesession>
Note:
mode="InProc" signifie : stocker l'état de la session localement (vous pouvez également choisir de le stocker sur un serveur distant ou un serveur SAL ou désactiver l'état de la session)
cookieless="true" signifie : activer l'état de session si le navigateur de l'utilisateur ne prend pas en charge les cookies (la valeur par défaut est False)
timeout="20" signifie : le nombre de minutes pendant lesquelles la session peut être inactive
8. <trace>
Fonction : Configurez le service de suivi asp.NET, principalement utilisé pour les tests de programmes afin de déterminer où les erreurs se produisent.
Exemple : Voici la configuration par défaut dans Web.config :
<trace activé="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
Note:
activé="false" signifie ne pas activer le suivi ;
requestLimit="10" précise le nombre de requêtes de suivi stockées sur le serveur
pageOutput="false" signifie que la sortie de trace n'est accessible que via l'utilitaire de trace ;
traceMode="SortByTime" indique que les informations de trace sont affichées dans l'ordre dans lequel les traces sont traitées.
localOnly="true" signifie que la visionneuse de trace (trace.axd) est utilisée uniquement pour le serveur Web hôte. Le processus de la section de configuration du fichier Web.config personnalisé est divisé en deux étapes.
1. Déclarez le nom de la section de configuration et le nom de la classe .NET Framework qui gère les données de configuration dans la section entre les balises <configSections> et </configSections> en haut du fichier de configuration.
2. Définissez les paramètres de configuration réels pour la section déclarée après la zone <configSections>.
Exemple : Créer une section pour stocker les chaînes de connexion à la base de données
<configuration>
<configSections>
<section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, Système, Version=1.0.3300.0, Culture=neutre, PublicKeyToken=b77a5c561934e089"/>
</configSections>
<paramètres de l'application>
<add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/>
</appSettings>
<système.web>
...
</system.web>
</configuration>
Accès au fichier Web.config Vous pouvez accéder au fichier Web.config à l'aide de la collection de chaînes statiques ConfigurationSettings.AppSettings. Exemple : Obtenez la chaîne de connexion établie dans l'exemple ci-dessus. Par exemple:
chaîne statique protégée Isdebug = ConfigurationSettings.AppSettings["debug"]
2. Explication détaillée de la configuration de session dans web.config Après avoir ouvert le fichier de configuration Web.config d'une application, nous retrouverons le paragraphe suivant :
<état de session
mode="EnProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="source de données=127.0.0.1;Trusted_Connection=oui"
sans cookie = "faux"
délai d'attente = "20"
/>
Cette section configure la manière dont l'application stocke les informations de session. Nos différentes opérations ci-dessous se concentrent principalement sur cette configuration. Voyons d'abord la signification du contenu contenu dans cette configuration. La syntaxe du nœud sessionState est la suivante :
< sessionState mode="Désactivé|InProc|StateServer|SQLServer"
sans cookie = "vrai | faux"
timeout = "nombre de minutes"
stateConnectionString="tcpip=serveur:port"
sqlConnectionString="chaîne de connexion SQL"
stateNetworkTimeout="nombre de secondes"
/>
Les attributs obligatoires sont : attribut option description
le mode définit où stocker les informations de session
Ø Off est réglé pour ne pas utiliser la fonction de session.
Ø InProc est configuré pour stocker la session dans le processus, qui est la méthode de stockage dans asp. C'est la valeur par défaut.
Ø StateServer est configuré pour stocker la session dans un service d'état indépendant.
Ø Les paramètres SQLServer stockent la session sur le serveur SQL.
Les attributs facultatifs sont : attribut option description
Ø ensembles sans cookie où sont stockées les informations de session du client,
Ø ture utilise le mode sans cookie,
Ø false Utiliser le mode Cookie, c'est la valeur par défaut,
Ø timeout définit le nombre de minutes après lequel le serveur abandonne automatiquement les informations de session. La valeur par défaut est de 20 minutes.
stateConnectionString définit le nom du serveur et le numéro de port utilisés lors du stockage des informations de session dans le service d'état, par exemple : "tcpip=127.0.0.1:42424". Cet attribut est obligatoire lorsque la valeur de mode est StateServer.
sqlConnectionString définit la chaîne de connexion lors de la connexion au serveur SQL. Par exemple "data source= localhost;Integrated Security=SSPI;Initial Catalog=northwind". Cet attribut est obligatoire lorsque la valeur de mode est SQLServer.
stateNetworkTimeout définit le nombre de secondes d'inactivité après lequel la connexion TCP/IP entre le serveur Web et le serveur stockant les informations d'état est déconnectée lors de l'utilisation du mode StateServer pour stocker l'état de la session. La valeur par défaut est de 10 secondes.
Le stockage de l'état de la session client dans asp.NET est illustré dans notre introduction au modèle de session ci-dessus. Vous pouvez constater que l'état de la session doit être stocké à deux endroits, à savoir le client et le serveur. Le client est uniquement responsable de la sauvegarde du SessionID du site Web correspondant, tandis que les autres informations de session sont enregistrées côté serveur. En asp, le SessionID du client est en fait stocké sous la forme d'un cookie. Si l'utilisateur choisit de désactiver les cookies dans les paramètres du navigateur, il ne pourra pas profiter du confort de la session et pourra même ne pas pouvoir accéder à certains sites Web. Afin de résoudre les problèmes ci-dessus, la méthode de stockage des informations de session du client dans asp.NET est divisée en deux types : Cookie et Cookieless.
Dans asp.NET, par défaut, les cookies sont toujours utilisés pour stocker les informations de session sur le client. Si nous souhaitons utiliser Cookieless pour stocker les informations de session sur le client, la méthode est la suivante :
Recherchez le répertoire racine de l'application Web actuelle, ouvrez le fichier Web.Config et recherchez le paragraphe suivant :
<état de session
mode="EnProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="source de données=127.0.0.1;Trusted_Connection=oui"
sans cookie = "faux"
délai d'attente = "20"
/>
Le cookieless="false" dans ce paragraphe est remplacé par : cookieless="true". De cette manière, les informations de session du client ne sont plus stockées à l'aide de cookies, mais sont stockées via l'URL. Fermez l'IE actuel, ouvrez un nouvel IE et revisitez l'application Web tout à l'heure. Vous verrez quelque chose de similaire à ce qui suit :
Parmi eux, ce qui est marqué en gras dans http://localhost/MyTestApplication/(ulqsek45heu3ic2a5zgdl245 )/default.aspx est l'ID de session du client. Notez que ces informations sont automatiquement ajoutées par IIS et n'affecteront pas les connexions normales précédentes.
Préparations pour stocker l'état de la session côté serveur dans asp.NET :
Afin de mieux expérimenter le phénomène expérimental, vous pouvez créer une page appelée SessionState.aspx, puis ajouter les codes suivants à <body></body>.
<scriptrunat="serveur">
Sub Session_Add (expéditeur en tant qu'objet, et en tant qu'EventArgs)
session("MaSession") = texte1.Valeur
span1.InnerHtml = "Données de session mises à jour ! < P>Votre session contient : < font color=red>" & session("MySession") & "< /font>".
Fin du sous-marin
Sous CheckSession (expéditeur en tant qu'objet, eAs EventArgs)
Si (Session("MaSession")N'est rien) Alors
span1.InnerHtml = "RIEN, DONNÉES de session PERDUES !"
Autre
span1.InnerHtml = "Votre session contient : < font color= red>" & session("MySession").ToString() & "< /font>"
Fin si
Fin du sous-marin
</script>
< formrunat="serveur"id="Form2">
< inputid="text1"type="text"runat="server"name="text1">
< inputtype="submit"runat="server"OnServerClick="Session_Add"
value="Ajouter à l'état de la session " id="Submit1"name="Submit1">
< inputtype="submit"runat="server"OnServerClick="CheckSession"
value=" Afficher l'état de la session " id="Submit2"name="Submit2">
< /form>
< hrsize="1">
< fontsize="6">< spanid="span1"runat="server" />< /font>
La page SessionState.aspx peut être utilisée pour tester si les informations de session sont perdues sur le serveur actuel.
Stockage des informations de session serveur dans le processus Revenons au paragraphe précédent du fichier Web.config :
<état de session
mode="EnProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="source de données=127.0.0.1;Trusted_Connection=oui"
sans cookie = "faux"
délai d'attente = "20"
/>
Lorsque la valeur de mode est InProc, cela indique que le serveur utilise ce mode.
Cette méthode est la même que le mode précédent dans asp, c'est-à-dire que le serveur stocke les informations de session dans le processus IIS. Lorsque IIS est arrêté et redémarré, ces informations seront perdues. Mais ce mode a aussi son plus grand avantage, à savoir les performances les plus élevées. Étant donné que toutes les informations de session sont stockées dans le processus IIS, IIS peut accéder rapidement à ces informations. Les performances de ce mode sont plus rapides que le stockage des informations de session hors processus ou le stockage de nombreuses informations de session dans SQL Server. Ce mode est également le mode par défaut d'asp.NET.
D'accord, faisons maintenant une expérience. Ouvrez la page SessionState.aspx tout à l'heure et saisissez quelques caractères pour les stocker dans la session. Ensuite, redémarrons IIS. Notez qu'il ne s'agit pas d'arrêter et de redémarrer le site actuel, mais de cliquer avec le bouton droit sur le nœud portant le nom de la machine locale dans IIS et de sélectionner Redémarrer IIS. (Je pense que lorsque j'utilisais NT4, j'ai dû redémarrer l'ordinateur pour redémarrer IIS. Microsoft est vraiment @#$%^&) Revenez à la page SessionState.aspx, vérifiez les informations de session tout à l'heure et constatez que les informations ont été perdu.
Stockage des informations de session du serveur en dehors du processus Tout d'abord, ouvrons les outils de gestion -> Services, recherchons le service nommé : asp.NET State Service et démarrons-le. En fait, ce service démarre un processus pour enregistrer les informations de session. Après avoir démarré ce service, vous pouvez voir un processus nommé aspnet_state.exe dans le Gestionnaire des tâches Windows-> Processus. C'est le processus dans lequel nous enregistrons les informations de session.
Ensuite, revenez au paragraphe ci-dessus dans le fichier Web.config et modifiez la valeur de mode en StateServer. Après avoir enregistré le fichier, rouvrez un IE, ouvrez la page SessionState.aspx et enregistrez certaines informations dans la session. À ce stade, redémarrons IIS et revenons à la page SessionState.aspx pour vérifier les informations de session tout à l'heure et constater qu'elles ne sont pas perdues.
En fait, cette façon de stocker les informations de session en dehors du processus signifie non seulement que les informations peuvent être stockées en dehors du processus de la machine locale, mais également que les informations de session peuvent être stockées dans les processus d'autres serveurs. À ce stade, vous devez non seulement modifier la valeur de mode en StateServer, mais vous devez également configurer les paramètres correspondants dans stateConnectionString. Par exemple, votre calcul est 192.168.0.1. Si vous souhaitez stocker la session dans le processus de l'ordinateur avec l'adresse IP 192.168.0.2, vous devez la définir comme ceci : stateConnectionString="tcpip=192.168.0.2:42424". Bien sûr, n'oubliez pas d'installer le .NET Framework sur l'ordinateur 192.168.0.2 et de démarrer le service asp.NET State Services.
Stockage des informations de session du serveur dans le serveur SQL Commençons par faire quelques travaux préparatoires. Démarrez le serveur SQL et les services proxy du serveur SQL. Exécutez un fichier de script appelé InstallSqlState.sql sur le serveur SQL. Ce fichier de script créera une base de données dans SQL Server spécifiquement pour stocker les informations de session, ainsi qu'un travail d'agent SQL Server qui gère la base de données d'informations de session. Nous pouvons trouver ce fichier dans le chemin suivant :
[lecteur système]winntMicrosoft.NETFramework[version]
Ensuite, ouvrez l'analyseur de requêtes, connectez-vous au serveur SQL, ouvrez le fichier tout à l'heure et exécutez-le. Attendez un moment et la base de données et le travail seront créés. À ce stade, vous pouvez ouvrir Enterprise Manager et constater qu'une nouvelle base de données appelée ASPState a été ajoutée. Mais il n'y a que quelques procédures stockées dans cette base de données et il n'y a pas de table utilisateur. En fait, les informations de session sont stockées dans la table ASPStateTempSessions de la base de données tempdb, et une autre table ASPStateTempApplications stocke les informations sur l'objet d'application dans asp. Ces deux tables ont également été créées par le script tout à l'heure. De plus, vérifiez Management->SQL Server Agent->Jobs et constatez qu'il existe également un travail supplémentaire appelé ASPState_Job_DeleteExpiredSessions. Ce travail supprime en fait les informations de session expirées de la table ASPStateTempSessions toutes les minutes.
Ensuite, nous revenons au fichier Web.config et modifions la valeur de mode en SQLServer. Notez que vous devez également modifier la valeur de sqlConnectionString en même temps. Le format est :
sqlConnectionString="source de données=localhost ; Sécurité intégrée=SSPI ;"
La source de données fait référence à l'adresse IP du serveur SQL Server. Si le serveur SQL et IIS sont la même machine, écrivez simplement 127.0.0.1. Integrated Security=SSPI signifie utiliser l'authentification intégrée de Windows. De cette façon, l'accès à la base de données se fera en tant que asp.NET. Grâce à cette configuration, vous pouvez obtenir une meilleure sécurité que la méthode d'authentification du serveur SQL en utilisant userid=sa;password=password sex. . Bien entendu, si le serveur SQL s'exécute sur un autre ordinateur, vous devrez peut-être maintenir la cohérence de l'authentification des deux côtés via le domaine Active Directory.
Encore une fois, faisons une expérience. Ajoutez des informations de session à SessionState.aspx, puis constatez que les informations de session existent déjà dans le serveur SQL Même si vous redémarrez l'ordinateur, les informations de session ne seront pas perdues. Vous avez maintenant complètement vu à quoi ressemblent les informations de session et elles sont stockées dans SQL Server. Ce que vous pouvez faire dépend de vos performances.
Résumé 3. Paramètres généraux de l'authentification par formulaire asp.net
Paramètres généraux pour l'authentification par formulaire asp.net :
1 : Dans web.config, ajoutez l'authentification par formulaire ;
<mode d'authentification="Formulaires">
<forms name="auth" loginUrl="index.aspx" timeout="30"></forms>
</authentification>
<autorisation>
<refuser les utilisateurs="?"
</autorisation>
2 : S'il existe une page d'inscription, les utilisateurs anonymes doivent être autorisés à appeler la page d'inscription pour s'inscrire ;
Le code suivant doit être compris entre <configuration><system.web> et ne doit pas être inclus entre <system.web>..</system.web> ;
----------------Indique que les utilisateurs anonymes sont autorisés à accéder à la page userReg.aspx.
<chemin d'emplacement="userReg.aspx">
<système.web>
<autorisation>
<autoriser les utilisateurs="?" />
</autorisation>
</system.web>
</emplacement>
3. Après une connexion réussie, un ticket de vérification d'identité doit être créé pour indiquer que l'utilisateur légal authentifié a réussi ;
si (connexion réussie)
System.Web.Security.FormsAuthentication.SetAuthCookie(nom d'utilisateur, false);
4. Accédez au fichier Web.config Vous pouvez accéder au fichier Web.config à l'aide de la collection de chaînes statiques ConfigurationSettings.AppSettings. Exemple : obtenez la chaîne de connexion établie dans l'exemple ci-dessus. Par exemple:
chaîne statique protégée Isdebug = ConfigurationSettings.AppSettings["scon"]
Optimisation des performances asp.Net.
(1).Sélectionnez la méthode de stockage de l'état de la session
Configurer dans le fichier Webconfig :
<modeStatesession="???" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="source de données=127.0.0.1;Trusted_Connection=oui"
cookieless="false" timeout="20"/>
ASP.NET propose trois manières de stocker les informations sur l'état de la session :
1. Stocké dans le processus : mode attribut = InProc
Caractéristiques : Il offre les meilleures performances et la vitesse la plus rapide, mais ne peut pas être partagé sur plusieurs serveurs.
2. Stocké dans le serveur d'état : mode attribut = "StateServer"
Fonctionnalités : utilisez cette méthode lorsque les informations de session utilisateur doivent être conservées sur les serveurs.
Mais les informations sont stockées sur le serveur d'état, et en cas de panne du serveur d'état, les informations seront perdues.
3. Stocké sur le serveur SQL : mode d'attribut="SqlServer"
Caractéristiques : La charge de travail deviendra plus importante, mais les informations ne seront pas perdues.
Encore une chose :
I. Étant donné que certaines pages ne nécessitent pas d'état de session, l'état de session peut être désactivé :
Le code est le suivant : <%@ Page EnableSessionState="false" %>
II. Si la page doit accéder aux variables de session mais n'est pas autorisée à les modifier, vous pouvez définir le statut de session de la page en lecture seule :
Le code est le suivant : <%@ Page EnableSessionState="false" %>
Lorsque vous l'utilisez, vous pouvez choisir une certaine méthode en fonction de la situation spécifique
(2).Utilisez Page.IsPostBack
Page.IsPostBack indique s'il est renvoyé par le client. Lors de la première exécution, il n'est pas renvoyé par le client. Sa valeur.
Est faux, lorsqu'un événement sur la page est déclenché ou que la page est actualisée, la valeur de Page.IsPostBack devient vraie car il s'agit d'une publication ;
Généralement utilisé dans : Méthode Page_Load :
private void Page_Load (Expéditeur d'objet, EventArgs e)
{
si(!Page.IsPostBack)
{
....; //Code pour initialiser la page. Ces codes sont exécutés lorsque la page est initialisée pour la première fois, et lors de sa deuxième publication,
//Ne sera plus exécuté. Améliorer l'efficacité.
}
}
IsPostBack doit souvent être utilisé car certains contrôles doivent conserver leur état après l'initialisation.
Par exemple : DropDownList, s'il est initialisé à chaque fois, quelle que soit l'option sélectionnée par l'utilisateur, il sera initialisé à la valeur par défaut.
(3). Évitez d'utiliser des contrôles de serveur.
1. Pour les informations générales d'affichage statique, essayez de ne pas utiliser de contrôles côté serveur pour les afficher, car les contrôles côté serveur doivent être renvoyés sur le serveur pour être exécutés.
Cela réduira l’efficacité de l’exécution du programme. Généralement, il peut être affiché avec <DIV>.
Si des contrôles côté serveur sont utilisés, la suppression de : runat="server" améliorera également l'efficacité.
2. Désactivez l'affichage de l'état des contrôles côté serveur. Certains contrôles n'ont pas besoin de conserver leur état. Vous pouvez définir leurs propriétés : EnableViewState=false;
Si le contrôle de page entier n'a pas besoin de conserver une vue d'état, vous pouvez définir la vue d'état de la page entière sur false :
Le code est le suivant : <%@ Page EnableViewState="false"%>
3. Configurez dans le fichier Web.Config :
Les sessions asp.NET peuvent être configurées dans l'élément Sessionsstate dans Web.config ou Machine.config.
Voici un exemple des paramètres dans Web.config :
<Sessionsstate timeout="10" cookieless="false" mode="Inproc" />
(4). Évitez d'utiliser DataGrid.
Tout le monde sait que DataGrid est puissant. Cependant, bien qu’il soit puissant, il augmente également les performances. Utilisez généralement d'autres contrôles : DataList
Ou le contrôle Répéteur peut y parvenir, essayez de ne pas utiliser DataGrid.
(5).Opérations sur les chaînes
1. Évitez les opérations de mise en box. Les opérations de conditionnement sont moins efficaces.
Par exemple, exécutez deux extraits de code :
chaîne test="";
pour(pour int i=0;i<10000;i++)
{
test = test + je;
}
et
chaîne test="";
pour(pour int i=0;i<10000;i++)
{
test = test + i.ToString();
}
L'extrait de code ci-dessous est évidemment plus efficace. Parce que i est un entier, le système doit d'abord mettre en boîte et convertir i en type chaîne avant de se connecter.
Les lecteurs peuvent le copier sur leurs propres machines et le tester.
2. Utilisez la classe StringBulider
Lors de la concaténation de chaînes : string str = str1 + str2 + .... ;
Généralement, pour plus de trois connexions, il est préférable d'utiliser StringBuilder au lieu de la classe stringBuilder pour éviter de recréer des objets chaîne.
perte de performances.
Généralement utilisé lors de l'assemblage d'instructions SQL : StringBulider.
Les lecteurs peuvent le tester sur leurs propres machines.
3. Utilisez le moins possible :
essayer
{}
attraper
{}
enfin
{}
Déclaration. L'efficacité d'exécution de cette déclaration est relativement faible.
(6) Optimisation de l'utilisation d'ADO.Net
1. Les connexions à la base de données sont ouvertes et fermées. Ouvrez lorsqu'une connexion est nécessaire et fermez la connexion immédiatement après avoir accédé à la base de données.
Par exemple, regardons deux extraits de code :
JE.
DataSetds = 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);
MaConnexion.Open(); //Ouvrir la connexion
for(int i=0;i<1000;i++) //la boucle for simule les opérations de logique métier avant d'obtenir les données
{
Thread.Sleep(1000);
}
monAdaptateur.Fill(ds);
for(int i=0;i<1000;i++) //la boucle for simule les opérations de logique métier après l'obtention des données
{
Thread.Sleep(1000);
}
MyConnection.Close(); //Ferme la connexion
II.
DataSetds = 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++) //la boucle for simule les opérations de logique métier avant d'obtenir les données
{
Thread.Sleep(1000);
}
MaConnexion.Open(); //Ouvrir la connexion
monAdaptateur.Fill(ds);
MyConnection.Close(); //Ferme la connexion
for(int i=0;i<1000;i++) ////La boucle for simule l'opération de logique métier après l'obtention des données
{
Thread.Sleep(1000);
}
Le code d'affichage II est bien meilleur que le code I. Le code I occupe la connexion tôt. S'il y a de nombreux utilisateurs, le pool de connexions est susceptible d'être plein. Dans les cas graves, un accident peut survenir.
2. Requête de base de données
I. Générez directement des instructions SQL. SQL Server doit le compiler à chaque fois et il n'y aura pas de grande amélioration des performances. De plus, ce n’est pas assez sûr. Facilement attaqué.
II. Utilisez la commande sql avec des paramètres. De cette façon, le serveur SQL ne le compile qu'une seule fois et les commandes compilées peuvent être réutilisées pour différents paramètres. Performances améliorées.
III. Utilisez les procédures stockées du serveur SQL. Compilez une fois. Il est indépendant et facile à modifier et à maintenir. Il peut remplir la fonction d'envoi d'instructions plusieurs fois à la fois.
couler. Les procédures stockées ne sont pas nécessairement plus efficaces que les instructions. Si la logique métier est très complexe, les instructions sont parfois plus efficaces que les procédures stockées.
(6). Optimisation du cache
Il existe deux types de cache : le cache de pages et le cache API.
1. Utilisez la mise en cache des pages et la mise en cache des fragments
<%@ OutputCache Duration="5" VaryByParam="Aucun"%>
<%@ OutputCache Durée=60 VaryByParam=”TextBox1,TextBox2” %>
Remarque : La durée permet de définir le délai d'expiration du cache ;
VarByParam indique si le paramètre change en fonction des paramètres. Lorsque Aucun, tous les paramètres utilisent le même cache.
Lors de la définition de TextBox1, mettez-les en cache séparément en fonction des différentes valeurs de TextBox1 lorsqu'il y a plusieurs paramètres, mettez-les en cache en combinaison ;
2.Cache API. à utiliser dans les applications
I. Un exemple d'utilisation du cache :
http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx
II. Faites attention à la différence entre Page.Cache et HttpContext.Current.Cache lors de l'utilisation :
Ils font référence au même objet. Dans Page, utilisez Page.Cache. Si vous l'utilisez dans global.asax ou dans votre propre classe : HttpContext.Current.Cache. Dans certains événements, car il n'y a pas de HttpContext, utilisez HttpRuntime.Cache.
