Explicación detallada de Web.config + optimización de asp.net
Autor：Eve Cole
Fecha de actualización：2009-07-01 16:44:14
1. Comprender el archivo Web.config
El archivo Web.config es un archivo de texto xml que se utiliza para almacenar la información de configuración de la aplicación web asp.NET (como el método de autenticación más utilizado para configurar la aplicación web asp.NET). paso de la aplicación en el directorio. Cuando crea una nueva aplicación web a través de .NET, se crea automáticamente un archivo Web.config predeterminado en el directorio raíz de forma predeterminada, incluidos los ajustes de configuración predeterminados, y todos los subdirectorios heredan sus ajustes de configuración. Si desea modificar los ajustes de configuración de un subdirectorio, puede crear un nuevo archivo Web.config en el subdirectorio. Puede proporcionar información de configuración además de la información de configuración heredada del directorio principal y también puede anular o modificar la configuración definida en el directorio principal.
(1).Web.Config se almacena en la especificación del archivo xml y el archivo de configuración se divide en los siguientes formatos
1. Características de declaración del controlador de la sección de configuración: ubicada en la parte superior del archivo de configuración y contenida en la etiqueta <configSections>.
2. Funciones de configuración de aplicaciones específicas: Ubicadas en <appSetting>. Puede definir información como la configuración constante global para la aplicación.
3. Funciones de configuración de la sección de configuración: ubicada en la sección <system.Web>, controla el comportamiento del tiempo de ejecución de asp.net.
4. Características de los grupos de secciones de configuración: utilizando la etiqueta <sectionGroup>, puede personalizar la agrupación y colocarla dentro de <configSections> o dentro de otras etiquetas <sectionGroup>.
(2). Cada sección de la sección de configuración.
1. Elemento raíz de la sección <configuración>, otras secciones están dentro de él.
2. Sección <appSetting> Esta sección se utiliza para definir la configuración de la aplicación. Para algunas configuraciones inciertas, los usuarios también pueden configurar su propio uso de acuerdo con su situación real:
I.<configuración de aplicación>
<add key="Conntction" value="servidor=192.168.85.66;userid=sa;contraseña=;database=Info;"/>
<configuración de la aplicación>
Se define una constante de cadena de conexión y la cadena de conexión se puede modificar en aplicaciones reales sin modificar el código del programa.
II.<configuración de la aplicación>
<add key="ErrPage" value="Error.aspx"/>><appSettings> define una página de redireccionamiento de errores.
3. Formato de sección <compilación>:
<compilación
idioma predeterminado="c#"
depuración = "verdadero"
/>
I.Idioma predeterminado: Defina el idioma del código de fondo, puede elegir dos idiomas: c# y vb.net.
IIdebug: Cuando es verdadero, se inicia la depuración de aspx; cuando es falso, no se inicia la depuración de aspx, mejorando así el rendimiento de la aplicación cuando se está ejecutando. Generalmente, los programadores lo configuran como verdadero cuando desarrollan y como falso cuando lo entregan a los clientes.
4. Formato de sección <customErrors>:
<errores personalizados
modo="SoloRemoto"
defaultRedirect="error.aspx"
<error statusCode="440" redirigir="err440page.aspx"/>
<error statusCode="500" redirigir="err500Page.aspx"/>
/>
I.mode: Tiene 3 estados: Encendido, Apagado y Solo Remoto. Activado significa que siempre se muestra información personalizada; Desactivado significa que siempre se muestra información detallada sobre el error de asp.net; RemoteOnly significa que la información personalizada solo se muestra para los usuarios que no están ejecutando en el servidor web local.
II.defaultRedirect: dirección URL utilizada para redirigir cuando ocurre un error Opcional.
III.statusCode: indica el código de estado de error, que indica un estado de error específico.
IV. Redirección: Error en la URL redirigida.
5. Formato de la sección <globalización>:
<globalización
requestEncoding="utf-8"
respuestaEncoding="utf-8"
fileEncoding="utf-8"
/>
I.requestEncoding: se utiliza para verificar la codificación de cada solicitud entrante.
II.responseEncoding: se utiliza para verificar la codificación del contenido de la respuesta enviada.
III.fileEncoding: se utiliza para verificar la codificación predeterminada para aspx, asax y otros análisis de archivos.
6. Formato de sección <sessionState>:
<estadodesesión
modo="EnProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="fuente de datos=127.0.0.1;Trusted_Connection=yes"
sin cookies = "falso"
tiempo de espera = "20"
/>
I.mode: Dividido en estados off, Inproc, StateServer, SqlServer
mode = InProc se almacena en el proceso Características: tiene el mejor rendimiento y la velocidad más rápida, pero no se puede compartir entre varios servidores mode = "StateServer" se almacena en el servidor estatal. Características: cuando es necesario mantener la información de la sesión del usuario. servidores, utilice este método. Sin embargo, la información se almacena en el servidor estatal. Una vez que el servidor estatal falla, la información se perderá. Mode="SqlServer" se almacena en el servidor SQL. Características: La carga de trabajo aumentará, pero la información no se perderá.
II. stateConnectionString: especifique el nombre del servidor donde la aplicación asp.net almacena el estado de la sesión remota. El valor predeterminado es la máquina local.
III.sqlConnectionString: cuando utilice una base de datos de estado de sesión, establezca la cadena de conexión aquí
IV. Sin cookies: cuando se establece en verdadero, significa que el estado de la sesión de cookies no se utiliza para identificar al cliente; de lo contrario, ocurre lo contrario.
V. TimeOut: se utiliza para definir el tiempo para el almacenamiento del estado de la sesión. Si se excede el límite de tiempo, la sesión finalizará automáticamente.
7. Formato de la sección <autenticación>:
<modo de autenticación="Formularios">
<formularios nombre=".ASPXUSERDEMO" loginUrl="Login.aspx" proteccion="Todos" tiempo de espera="30"/>
</autenticación>
<autorización>
<denegar usuarios="?"/>
</autorización>
I.Windows: utilice el método de autenticación IIS
II.Formularios: uso de validación basada en formularios
III.Passport: utilizar el modo de verificación de cookies de Passport
IV.Ninguno: no utiliza ningún método de verificación. El significado de los atributos del nodo Formularios incrustados en él:
I.Name: especifica el nombre de la cookie HTTP utilizada para completar la autenticación.
II.LoginUrl: la URL de la página que se redirige si la verificación falla o se agota el tiempo de espera, generalmente la página de inicio de sesión, lo que permite al usuario iniciar sesión nuevamente.
III.Protección: Especificar el método de protección de los datos de las cookies.
Se puede configurar en: Todos Ninguno Validación de cifrado Cuatro métodos de protección
a. Todo significa cifrar datos y realizar verificación de validez de dos maneras.
b. Ninguno significa que las cookies no están protegidas.
c. Cifrado significa cifrar el contenido de las cookies.
d. Validación significa verificar la validez del contenido de las cookies.
IV. Tiempo de espera: especifique el tiempo de vencimiento de las cookies. Inicie sesión nuevamente después del tiempo de espera.
Las modificaciones al archivo Web.config en tiempo de ejecución pueden surtir efecto sin reiniciar el servicio (Nota: excepción para la sección <processModel>). Por supuesto, el archivo Web.config es extensible. Puede personalizar nuevos parámetros de configuración y escribir controladores de secciones de configuración para manejarlos.
El archivo de configuración web.config (configuraciones de configuración predeterminadas), todo el código siguiente debe ubicarse en
<configuración>
<sistema.web>
y
</sistema.web>
</configuración>
Para fines de aprendizaje, los siguientes ejemplos omiten esta etiqueta xml.
1. La función de la sección <autenticación>: configurar el soporte de autenticación asp.NET (cuatro tipos: Windows, Forms, PassPort y Ninguno). Este elemento solo se puede declarar a nivel de computadora, sitio o aplicación. El elemento <authentication> debe usarse con la sección <authorization>.
Ejemplo:
El siguiente ejemplo es un sitio de configuración de autenticación basado en formularios. Cuando un usuario que no ha iniciado sesión accede a una página web que requiere autenticación, la página web salta automáticamente a la página web de inicio de sesión.
<modo de autenticación="Formularios" >
<formularios loginUrl="logon.aspx" nombre=".FormsAuthCookie"/>
</autenticación>
El elemento loginUrl representa el nombre de la página web de inicio de sesión y el nombre representa el nombre de la cookie.
2. La función de la sección <autorización>: controla el acceso del cliente a los recursos URL (como permitir el acceso a usuarios anónimos). Este elemento se puede declarar en cualquier nivel (computadora, sitio, aplicación, subdirectorio o página). Requerido junto con la sección <authentication>.
Ejemplo: El siguiente ejemplo deshabilita el acceso a usuarios anónimos.
<autorización>
<denegar usuarios="?"/>
</autorización>
Nota: Puede usar user.identity.name para obtener el nombre de usuario autenticado actual; puede usar el método web.Security.FormsAuthentication.RedirectFromLoginPage para redirigir al usuario autenticado a la página que el usuario acaba de solicitar.
3. La función de la sección <compilación>: configurar todas las configuraciones de compilación utilizadas por asp.NET. El atributo de depuración predeterminado es "Verdadero". Debe establecerse en Falso después de compilar y entregar el programa para su uso (los detalles se describen en el archivo Web.config y el ejemplo se omite aquí).
4.<errores personalizados>
Función: proporcionar información sobre mensajes de error personalizados para aplicaciones asp.NET. No se aplica a errores que ocurren en servicios web xml.
Ejemplo: cuando se produce un error, salte a una página de error personalizada.
<customErrors defaultRedirect="ErrorPage.aspx" mode="RemoteOnly">
</customErrors>
El elemento defaultRedirect representa el nombre de la página web de error personalizada. El elemento de modo indica: mostrar información personalizada (amigable) a los usuarios que no se ejecutan en el servidor web local.
5. La función de la sección <httpRuntime>: configurar los ajustes del tiempo de ejecución HTTP de asp.NET. Esta sección se puede declarar en los niveles de computadora, sitio, aplicación y subdirectorio.
Ejemplo: controlar el tamaño máximo de los archivos cargados por el usuario a 4 M, el tiempo máximo a 60 segundos y el número máximo de solicitudes a 100
<httpRuntime maxRequestLength="4096"executionTimeout="60" appRequestQueueLimit="100"/>
6. <páginas>
Rol: Identifica los ajustes de configuración específicos de la página (como si se habilita el estado de la sesión, el estado de la vista, si se detecta la entrada del usuario, etc.). Las <páginas> se pueden declarar en los niveles de computadora, sitio, aplicación y subdirectorio.
Ejemplo: No detectar si hay datos potencialmente peligrosos en el contenido ingresado por el usuario en el navegador (Nota: este elemento se detecta de forma predeterminada. Si utiliza la no detección, debe codificar o verificar la entrada del usuario desde el). cliente El estado de la vista cifrada se verifica cuando la página se vuelve a publicar para verificar que el estado de la vista no haya sido alterado en el lado del cliente. (Nota: este artículo no está verificado de forma predeterminada)
<pages buffer="true" enableViewStateMac="true" validarRequest="false"/>
7. <estado de sesión>
Función: Configurar los ajustes del estado de la sesión para la aplicación actual (como establecer si se habilita el estado de la sesión y dónde guardar el estado de la sesión).
Ejemplo:
<sessionState modo="InProc" cookieless="true" timeout="20"/>
</estadodesesión>
Nota:
mode="InProc" significa: almacenar el estado de la sesión localmente (también puede optar por almacenarlo en un servidor remoto o servidor SAL o desactivar el estado de la sesión)
cookieless="true" significa: habilitar el estado de la sesión si el navegador del usuario no admite cookies (el valor predeterminado es False)
timeout="20" significa: la cantidad de minutos que la sesión puede estar inactiva
8. <rastro>
Función: Configurar el servicio de seguimiento asp.NET, utilizado principalmente para pruebas de programas para determinar dónde ocurren los errores.
Ejemplo: La siguiente es la configuración predeterminada en Web.config:
<trace enable="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
Nota:
enable="false" significa no habilitar el seguimiento;
requestLimit="10" especifica el número de solicitudes de seguimiento almacenadas en el servidor
pageOutput="false" significa que solo se puede acceder a la salida de seguimiento a través de la utilidad de seguimiento;
traceMode="SortByTime" indica que la información de seguimiento se muestra en el orden en que se procesan los seguimientos.
localOnly="true" significa que el visor de seguimiento (trace.axd) solo se utiliza para el servidor web host. El proceso de la sección de configuración del archivo Web.config personalizado se divide en dos pasos.
1. Declare el nombre de la sección de configuración y el nombre de la clase .NET Framework que maneja los datos de configuración en la sección entre las etiquetas <configSections> y </configSections> en la parte superior del archivo de configuración.
2. Realice los ajustes de configuración reales para la sección declarada después del área <configSections>.
Ejemplo: crear una sección para almacenar cadenas de conexión de base de datos
<configuración>
<secciones de configuración>
<section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</configSections>
<configuración de la aplicación>
<agregar clave="scon" valor="servidor=a;database=northwind;uid=sa;pwd=123"/>
</aplicaciónConfiguración>
<sistema.web>
...
</sistema.web>
</configuración>
Acceso al archivo Web.config Puede acceder al archivo Web.config utilizando la colección de cadenas estáticas ConfigurationSettings.AppSettings. Ejemplo: obtenga la cadena de conexión establecida en el ejemplo anterior. Por ejemplo:
cadena estática protegida Isdebug = ConfigurationSettings.AppSettings["debug"]
2. Explicación detallada de la configuración de la sesión en web.config Luego de abrir el archivo de configuración Web.config de una aplicación, nos encontraremos con el siguiente párrafo:
< estado de sesión
modo="EnProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="fuente de datos=127.0.0.1;Trusted_Connection=yes"
sin cookies = "falso"
tiempo de espera = "20"
/>
Esta sección configura cómo la aplicación almacena la información de la sesión. Nuestras diversas operaciones a continuación se centran principalmente en esta configuración. Primero echemos un vistazo al significado del contenido de esta configuración. La sintaxis del nodo sessionState es la siguiente:
< modo sessionState="Desactivado|InProc|StateServer|SQLServer"
sin cookies="verdadero|falso"
tiempo de espera = "número de minutos"
stateConnectionString="tcpip=servidor:puerto"
sqlConnectionString="cadena de conexión SQL"
stateNetworkTimeout="número de segundos"
/>
Los atributos requeridos son: atributo opción descripción
El modo establece dónde almacenar la información de la sesión.
Ø Off está configurado para no utilizar la función de sesión.
Ø InProc está configurado para almacenar la sesión en el proceso, que es el método de almacenamiento en asp. Este es el valor predeterminado.
Ø StateServer está configurado para almacenar la sesión en un servicio estatal independiente.
Ø La configuración de SQLServer almacena la sesión en el servidor SQL.
Los atributos opcionales son: descripción de la opción del atributo
Ø conjuntos sin cookies donde se almacena la información de la sesión del cliente,
Ø ture utiliza el modo sin cookies,
Ø falso Usar modo Cookie, este es el valor predeterminado,
Ø el tiempo de espera establece el número de minutos después de los cuales el servidor proporciona automáticamente información de la sesión. El valor predeterminado es 20 minutos.
stateConnectionString establece el nombre del servidor y el número de puerto utilizado al almacenar información de la sesión en el servicio estatal, por ejemplo: "tcpip=127.0.0.1:42424". Este atributo es obligatorio cuando el valor de modo es StateServer.
sqlConnectionString establece la cadena de conexión cuando se conecta al servidor SQL. Por ejemplo "fuente de datos = localhost; Seguridad integrada = SSPI; Catálogo inicial = viento del norte". Este atributo es obligatorio cuando el valor de modo es SQLServer.
stateNetworkTimeout establece el número de segundos de inactividad después de los cuales la conexión TCP/IP entre el servidor web y el servidor que almacena la información de estado se desconecta cuando se utiliza el modo StateServer para almacenar el estado de la sesión. El valor predeterminado es 10 segundos.
El almacenamiento del estado de la sesión del cliente en asp.NET se muestra en nuestra introducción anterior al modelo de sesión. Puede encontrar que el estado de la sesión debe almacenarse en dos lugares, a saber, el cliente y el servidor. El cliente solo es responsable de guardar el ID de sesión del sitio web correspondiente, mientras que otra información de la sesión se guarda en el lado del servidor. En ASP, el ID de sesión del cliente en realidad se almacena en forma de cookie. Si el usuario opta por desactivar las cookies en la configuración del navegador, no podrá disfrutar de la comodidad de la sesión e incluso puede que no pueda acceder a determinados sitios web. Para resolver los problemas anteriores, el método de almacenamiento de información de la sesión del cliente en asp.NET se divide en dos tipos: cookie y sin cookies.
En asp.NET, de forma predeterminada, las cookies todavía se utilizan para almacenar información de la sesión en el cliente. Si queremos utilizar Cookieless para almacenar información de la sesión en el cliente, el método es el siguiente:
Busque el directorio raíz de la aplicación web actual, abra el archivo Web.Config y busque el siguiente párrafo:
< estado de sesión
modo="EnProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="fuente de datos=127.0.0.1;Trusted_Connection=yes"
sin cookies = "falso"
tiempo de espera = "20"
/>
El cookieless="false" en este párrafo se cambia a: cookieless="true". De esta manera, la información de la sesión del cliente ya no se almacena mediante cookies, sino a través de la URL. Cierre el IE actual, abra un nuevo IE y vuelva a visitar la aplicación web ahora. Verá algo similar a lo siguiente:
Entre ellos, lo que está marcado en negrita en http://localhost/MyTestApplication/(ulqsek45heu3ic2a5zgdl245 )/default.aspx es el ID de sesión del cliente. Tenga en cuenta que IIS agrega automáticamente esta información y no afectará las conexiones normales anteriores.
Preparativos para almacenar el estado de la sesión en el lado del servidor en asp.NET:
Para que pueda experimentar mejor el fenómeno experimental, puede crear una página llamada SessionState.aspx y luego agregar los siguientes códigos a <body></body>.
<scriptrunat="servidor">
Sub Session_Add (remitente como objeto, e como EventArgs)
sesión("MiSesión") = texto1.Valor
span1.InnerHtml = "¡Datos de la sesión actualizados! < P>Su sesión contiene: < font color=red>" & session("MySession() & "< /font>"
Subtítulo final
Sub CheckSession (remitente como objeto, eAs EventArgs)
Si (la sesión ("Mi sesión") no es nada) entonces
span1.InnerHtml = "¡NADA, DATOS DE SESIÓN PERDIDOS!"
Demás
span1.InnerHtml = "Su sesión contiene: < color de fuente = rojo>" & session("MySession").ToString() & "< /font>"
Terminar si
Subtítulo final
</script>
<formrunat="servidor"id="Form2">
< inputid="text1"type="text"runat="servidor"name="text1">
< inputtype="submit"runat="servidor"OnServerClick="Session_Add"
value="Agregar al estado de la sesión " id="Submit1"name="Submit1">
< inputtype="enviar"runat="servidor"OnServerClick="CheckSession"
valor="Ver estado de la sesión" id="Submit2"name="Submit2">
< /formulario>
< hrsize="1">
< fontsize="6">< spanid="span1"runat="servidor" />< /font>
La página SessionState.aspx se puede utilizar para probar si la información de la sesión se pierde en el servidor actual.
Almacenamiento de información de la sesión del servidor en el proceso Volvamos al párrafo anterior del archivo Web.config:
< estado de sesión
modo="EnProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="fuente de datos=127.0.0.1;Trusted_Connection=yes"
sin cookies = "falso"
tiempo de espera = "20"
/>
Cuando el valor del modo es InProc, indica que el servidor está usando este modo.
Este método es el mismo que el modo anterior en asp, es decir, el servidor almacena información de la sesión en el proceso IIS. Cuando IIS se cierra y se reinicia, esta información se perderá. Pero este modo también tiene su mayor ventaja, que es el mayor rendimiento. Debido a que toda la información de la sesión se almacena en el proceso de IIS, IIS puede acceder rápidamente a esta información. El rendimiento de este modo es más rápido que almacenar información de sesión fuera del proceso o almacenar mucha información de sesión en SQL Server. Este modo es también el modo predeterminado de asp.NET.
Bien, ahora hagamos un experimento. Abra la página SessionState.aspx ahora e ingrese algunos caracteres para almacenarlos en la sesión. Luego, reiniciemos IIS. Tenga en cuenta que no se trata de detener y reiniciar el sitio actual, sino de hacer clic derecho en el nodo con el nombre de la máquina local en IIS y seleccionar Reiniciar IIS. (Creo que cuando usé NT4, tuve que reiniciar la computadora para reiniciar IIS. Microsoft es realmente @#$%^&) Regrese a la página SessionState.aspx, verifique la información de la sesión en este momento y descubra que la información ha sido perdido.
Almacenamiento de información de la sesión del servidor fuera del proceso Primero, abramos las herramientas de administración -> Servicios, busquemos el servicio llamado: asp.NET State Service e iniciémoslo. De hecho, este servicio inicia un proceso para guardar la información de la sesión. Después de iniciar este servicio, puede ver un proceso llamado aspnet_state.exe desde el Administrador de tareas de Windows->Procesos. Este es el proceso donde guardamos la información de la sesión.
Luego, regrese al párrafo anterior en el archivo Web.config y cambie el valor del modo a StateServer. Después de guardar el archivo, vuelva a abrir un IE, abra la página SessionState.aspx y guarde cierta información en la sesión. En este momento, reiniciemos IIS y volvamos a la página SessionState.aspx para verificar la información de la sesión en este momento y descubrir que no se ha perdido.
De hecho, esta forma de almacenar información de sesión fuera del proceso no solo significa que la información se puede almacenar fuera del proceso de la máquina local, sino que también la información de la sesión se puede almacenar en los procesos de otros servidores. En este momento, no solo necesita cambiar el valor del modo a StateServer, sino que también necesita configurar los parámetros correspondientes en stateConnectionString. Por ejemplo, su cálculo es 192.168.0.1. Si desea almacenar la sesión en el proceso de la computadora con la dirección IP 192.168.0.2, debe configurarla así: stateConnectionString="tcpip=192.168.0.2:42424". Por supuesto, no olvide instalar .NET Framework en la computadora 192.168.0.2 e iniciar el servicio asp.NET State Services.
Almacenamiento de información de la sesión del servidor en el servidor SQL Primero, hagamos un trabajo preparatorio. Inicie el servidor SQL y los servicios de proxy del servidor SQL. Ejecute un archivo de script llamado InstallSqlState.sql en el servidor SQL. Este archivo de script creará una base de datos en SQL Server específicamente para almacenar información de la sesión y un trabajo del agente de SQL Server que mantiene la base de datos de información de la sesión. Podemos encontrar ese archivo en la siguiente ruta:
[unidad del sistema]winntMicrosoft.NETFramework[versión]
Luego abra el analizador de consultas, conéctese al servidor SQL, abra el archivo ahora y ejecútelo. Espere un momento y se crearán la base de datos y el trabajo. En este momento, puede abrir Enterprise Manager y ver que se ha agregado una nueva base de datos llamada ASPState. Pero solo hay algunos procedimientos almacenados en esta base de datos y no hay una tabla de usuarios. De hecho, la información de la sesión se almacena en la tabla ASPStateTempSessions de la base de datos tempdb, y otra tabla ASPStateTempApplications almacena la información del objeto de la aplicación en asp. Estas dos tablas también fueron creadas por el script hace un momento. Además, verifique Administración->Agente del servidor SQL->Trabajos y descubra que también hay un trabajo adicional llamado ASPState_Job_DeleteExpiredSessions. Este trabajo en realidad elimina la información de la sesión caducada de la tabla ASPStateTempSessions cada minuto.
A continuación, volvemos al archivo Web.config y modificamos el valor del modo a SQLServer. Tenga en cuenta que también debe modificar el valor de sqlConnectionString al mismo tiempo. El formato es:
sqlConnectionString="fuente de datos=localhost; Seguridad integrada=SSPI;"
La fuente de datos se refiere a la dirección IP del servidor SQL. Si el servidor SQL y IIS son la misma máquina, simplemente escriba 127.0.0.1. Seguridad integrada = SSPI significa usar la autenticación integrada de Windows. De esta manera, el acceso a la base de datos se realizará como asp.NET. A través de esta configuración, puede obtener una mejor seguridad que el método de autenticación del servidor SQL usando userid=sa;password=password sex. . Por supuesto, si el servidor SQL se ejecuta en otra computadora, es posible que deba mantener la coherencia de la autenticación en ambos lados a través del dominio de Active Directory.
De nuevo, hagamos un experimento. Agregue información de la sesión a SessionState.aspx y luego descubra que la información de la sesión ya existe en el servidor SQL. Incluso si reinicia la computadora, la información de la sesión no se perderá. Ahora ha visto completamente cómo se ve la información de la sesión y está almacenada en SQL Server. Lo que puede hacer depende de su rendimiento.
Resumen 3. Configuración general de la autenticación de formularios asp.net
Configuración general para la autenticación de formularios asp.net:
1: En web.config, agregue autenticación de formulario;
<modo de autenticación="Formularios">
<formularios nombre="auth" loginUrl="index.aspx" timeout="30"></forms>
</autenticación>
<autorización>
<denegar usuarios="?"
</autorización>
2: Si hay una página de registro, se debe permitir a los usuarios anónimos llamar a la página de registro para registrarse;
El siguiente código debe estar entre <configuration><system.web> y no debe incluirse entre <system.web>..</system.web>;
----------------Indica que los usuarios anónimos pueden acceder a la página userReg.aspx.
<ruta de ubicación="userReg.aspx">
<sistema.web>
<autorización>
<permitir usuarios="?"
</autorización>
</sistema.web>
</ubicación>
3. Después de iniciar sesión correctamente, se debe crear un ticket de verificación de identidad para indicar que el usuario legal autenticado ha pasado;
si (iniciar sesión exitosamente)
System.Web.Security.FormsAuthentication.SetAuthCookie(nombre de usuario, falso);
4. Acceda al archivo Web.config Puede acceder al archivo Web.config utilizando la colección de cadenas estáticas ConfigurationSettings.AppSettings. Obtenga la cadena de conexión establecida en el ejemplo anterior. Por ejemplo:
cadena estática protegida Isdebug = ConfigurationSettings.AppSettings["scon"]
Optimización del rendimiento de asp.Net.
(1).Seleccione el método de almacenamiento del estado de la sesión.
Configurar en el archivo Webconfig:
<modo de estado de sesión="???" estadoConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="fuente de datos=127.0.0.1;Trusted_Connection=yes"
sin cookies="false" timeout="20"/>
ASP.NET tiene tres formas de almacenar información del estado de la sesión:
1. Almacenado en el proceso: modo de atributo = InProc
Características: Tiene el mejor rendimiento y la velocidad más rápida, pero no se puede compartir entre varios servidores.
2. Almacenado en el servidor de estado: modo de atributo = "StateServer"
Características: utilice este método cuando sea necesario mantener la información de la sesión del usuario en todos los servidores.
Pero la información se almacena en el servidor estatal y, una vez que el servidor estatal falla, la información se perderá.
3. Almacenado en el servidor SQL: atributo mode="SqlServer"
Características: La carga de trabajo aumentará, pero la información no se perderá.
Una cosa más:
I. Dado que algunas páginas no requieren estado de sesión, el estado de sesión se puede desactivar:
El código es el siguiente: <%@ Page EnableSessionState="false" %>
II. Si la página necesita acceder a las variables de la sesión pero no puede modificarlas, puede configurar el estado de la sesión de la página en solo lectura:
El código es el siguiente: <%@ Page EnableSessionState="false" %>
Al usarlo, puedes elegir un método determinado según la situación específica.
(2).Usar página.IsPostBack
Page.IsPostBack indica si es devuelto por el cliente. Cuando se ejecuta por primera vez, no es devuelto por el cliente.
Es falso, cuando se activa un evento en la página o se actualiza la página, el valor de Page.IsPostBack se vuelve verdadero porque es una devolución de datos;
Generalmente utilizado en: Método Page_Load:
carga de página vacía privada (remitente del objeto, argumentos de evento e)
{
si(!Página.IsPostBack)
{
....; //Código para inicializar la página. Estos códigos se ejecutan cuando la página se inicializa por primera vez y cuando se vuelve a publicar por segunda vez.
//No se volverá a ejecutar. Mejorar la eficiencia.
}
}
A menudo es necesario utilizar IsPostBack porque algunos controles necesitan mantener su estado después de la inicialización.
Por ejemplo: DropDownList, si se inicializa cada vez, no importa qué opción seleccione el usuario, se inicializará con el valor predeterminado.
(3). Evite el uso de controles del servidor.
1. Para obtener información de visualización estática general, intente no utilizar controles del lado del servidor para mostrarla. Debido a que los controles del lado del servidor deben publicarse en el servidor para su ejecución.
Reducirá la eficiencia de la ejecución del programa. Generalmente, se puede mostrar con <DIV>.
Si se utilizan controles del lado del servidor, eliminar: runat="server" también mejorará la eficiencia.
2. Deshabilite la vista de estado de los controles del lado del servidor. Algunos controles no necesitan mantener su estado. Puede configurar sus propiedades: EnableViewState=false;
Si no es necesario que todo el control de la página mantenga una vista de estado, puede configurar la vista de estado de toda la página en falso:
El código es el siguiente: <%@ Page EnableViewState="false"%>
3. Configure en el archivo Web.Config:
Las sesiones asp.NET se pueden configurar en el elemento Sessionsstate en Web.config o Machine.config.
A continuación se muestra un ejemplo de la configuración en Web.config:
<Sessionsstate timeout="10" cookieless="false" mode="Inproc" />
(4). Evite el uso de DataGrid.
Todo el mundo sabe que DataGrid es poderoso. Sin embargo, si bien es potente, también aumenta la sobrecarga de rendimiento. Generalmente use otros controles: DataList
O el control del repetidor puede lograr esto, intente no usar DataGrid.
(5).Operaciones con cadenas
1. Evite las operaciones de embalaje. Las operaciones de embalaje son menos eficientes.
Por ejemplo, ejecute dos fragmentos de código:
prueba de cadena="";
para(para int i=0;i<10000;i++)
{
prueba = prueba + i;
}
y
prueba de cadena="";
para(para int i=0;i<10000;i++)
{
prueba = prueba + i.ToString();
}
El siguiente fragmento de código es obviamente más eficiente. Debido a que i es un número entero, el sistema primero debe encuadrarlo y convertirlo en un tipo de cadena antes de conectarse.
Los lectores pueden copiarlo en sus propias máquinas y probarlo.
2. Utilice la clase StringBulider
Al realizar la concatenación de cadenas: string str = str1 + str2 + ....;
Generalmente, para más de tres conexiones, es mejor usar StringBuilder en lugar de la clase de cadena para evitar volver a crear objetos de cadena.
pérdida de rendimiento.
Generalmente se utiliza al ensamblar declaraciones SQL: StringBulider.
Los lectores pueden probarlo en sus propias máquinas.
3. Utilice lo menos posible:
intentar
{}
atrapar
{}
finalmente
{}
Declaración La eficiencia de ejecución de esta declaración es relativamente baja.
(6) Optimización del uso de ADO.Net
1. Las conexiones de la base de datos se abren y cierran. Ábralo cuando sea necesaria una conexión y cierre la conexión inmediatamente después de acceder a la base de datos.
Por ejemplo, veamos dos fragmentos de código:
I.
Conjunto de datos ds = nuevo Conjunto de datos();
SqlConnection MyConnection = new SqlConnection("servidor=localhost; uid=sa; pwd=; base de datos=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
MyConnection.Open(); //Abre la conexión
for(int i=0;i<1000;i++) //el bucle for simula operaciones de lógica empresarial antes de obtener datos
{
Hilo.Sleep(1000);
}
miAdapter.Fill(ds);
for(int i=0;i<1000;i++) //el bucle for simula operaciones de lógica empresarial después de obtener datos
{
Hilo.Sleep(1000);
}
MyConnection.Close(); //Cerrar la conexión
II.
Conjunto de datos ds = nuevo Conjunto de datos();
SqlConnection MyConnection = new SqlConnection("servidor=localhost; uid=sa; pwd=; base de datos=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
for(int i=0;i<1000;i++) //el bucle for simula operaciones de lógica empresarial antes de obtener datos
{
Hilo.Sleep(1000);
}
MyConnection.Open(); //Abre la conexión
miAdapter.Fill(ds);
MyConnection.Close(); //Cerrar la conexión
for(int i=0;i<1000;i++) //// El bucle for simula la operación de lógica empresarial después de obtener los datos
{
Hilo.Sleep(1000);
}
El código II de visualización es mucho mejor que el código I. El código I ocupa la conexión antes. Si hay muchos usuarios, es probable que el grupo de conexiones esté lleno. En casos severos, puede ocurrir un accidente.
2. Consulta de base de datos
I. Generar declaraciones SQL directamente. SQL Server tiene que compilarlo cada vez y no habrá una gran mejora en el rendimiento. Además, no es lo suficientemente seguro. Fácilmente atacado.
II. Utilice el comando sql con parámetros. De esta manera, el servidor SQL solo lo compila una vez y los comandos compilados se pueden reutilizar para diferentes parámetros. Rendimiento mejorado.
III. Utilice procedimientos almacenados del servidor SQL. Compile una vez. Es independiente y fácil de modificar y mantener. Puede completar la función de enviar declaraciones varias veces a la vez.
fluir. Los procedimientos almacenados no son necesariamente más eficientes que las declaraciones. Si la lógica empresarial es muy compleja, a veces las declaraciones son más eficientes que los procedimientos almacenados.
(6). Optimización de caché.
Hay dos tipos de caché: caché de página y caché de API.
1. Utilice el almacenamiento en caché de páginas y el almacenamiento en caché de fragmentos.
<%@ OutputCache Duration="5" VaryByParam="Ninguno"%>
<%@ Duración de OutputCache=60 VaryByParam=”TextBox1,TextBox2” %>
Nota: La duración sirve para establecer el tiempo de caducidad de la caché;
VarByParam es si la configuración cambia según los parámetros. Cuando Ninguno, todos los parámetros usan el mismo caché.
Al configurar TextBox1, guárdelos en caché por separado de acuerdo con diferentes valores de TextBox1; cuando haya varios parámetros, guárdelos en caché combinados;
2.Caché API. para uso en aplicaciones
I. Un ejemplo de uso de caché:
http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx
II Preste atención a la diferencia entre Page.Cache y HttpContext.Current.Cache cuando use:
Se refieren al mismo objeto. En Page, use Page.Cache. Si lo usa en global.asax o en su propia clase: HttpContext.Current.Cache. En algunos eventos, debido a que no hay HttpContext, use HttpRuntime.Cache.
