Habilidades de sesión en ASP

Recomendado: ASP implementa el envío automático de correos electrónicos si no existen páginas web
Cuando hacemos un sitio web, generalmente tenemos algunos errores en las acciones o defectos de los visitantes en nuestro sitio web, lo que hace que se visite una página inexistente. En este momento, aparecerá un mensaje de error 404. Si es un visitante entusiasta, puede enviarle un correo electrónico para recordarle. En ese momento, la mayoría de la gente

Cualquiera que haya escrito un ASP un poco más grande sabe que la sesión es realmente útil. Se puede usar para registrar variables de datos propiedad del usuario, que es segura y conveniente. ¿Pero realmente sabes cómo funciona la sesión? Quizás después de que entiendas, nunca te atreves a usar este objeto de amor y odio nuevamente. Aunque el método de cambiar a alternativas es un poco problemático, después de consideraciones a largo plazo, tengo que hacerlo.

Primero, hablemos sobre los beneficios de la sesión, que se pueden usar para registrar variables de datos de propiedad privada del cliente y no desaparecerá dentro del rango de tiempo. Esta es realmente una función importante, especialmente aquellos que deben ser utilizados por los sistemas con los miembros. Por ejemplo, la cuenta de inicio de sesión del miembro, el tiempo, el estado y muchos datos en tiempo real registrados en este registro, como el sistema de compras registra los productos en la canasta de compras del usuario. Esta información es necesaria en privado por cada usuario, y el desarrollador generalmente usa registros de sesión para procesarla.

Sin embargo, la sesión en ASP se compone de cookies, y el servidor transmite toda la información registrada en la sesión al navegador del usuario en forma de cookies. Por lo general, los navegadores guardarán estas galletas. Siempre que el usuario haga clic en el enlace y lo conecte nuevamente al servidor, el navegador volverá a pasar estas cookies al servidor para su procesamiento. Este es el principio operativo de la sesión. Cuando la cantidad de datos es mayor, debe transmitirse y recolectarse. No solo consume el ancho de banda de la línea, sino que también reduce su rendimiento, ya que el servidor debe gastar más recursos en acciones iniciales, como el procesamiento en línea y la memoria de reconfiguración. Ahora puede pensar: "Tengo que usar esta función, así que tengo que sacrificar un poco". Sin embargo, este artículo habla sobre la sesión. Por un lado, es enseñar a todos a usar menos; Por otro lado, hay alternativas, por supuesto. Entonces, el que sube al escenario es el objeto de aplicación que pertenece a Global.asa.

La aplicación también es buena para registrar y procesar datos temporales. Sus habilidades y uso en todos los aspectos son las mismas que la sesión, pero en comparación, los datos que registra es público, es decir, un espacio variable que cualquier usuario puede compartir. La aplicación no es como la sesión, que no pasa los datos al usuario y espera la próxima vez para leerlos en línea. Se registra directamente en la memoria del servidor, y el rendimiento es mucho más rápido que la sesión.

Dado que los objetos de aplicación son públicos, lo primero que debe hacerse es planificar un área común para cada usuario, de modo que cada usuario tenga su propia área para registrar datos para lograr el propósito de la sesión de simulación. Hay dos formas de hacerlo ahora:

1. Inicialice y asigne el espacio de memoria del usuario por adelantado cuando el servidor se activa. Por lo general, aunque este enfoque ocupa muchos recursos tan pronto como el servidor se enciende, también ahorra el problema de tener que asignar cada vez que el usuario está en línea. Sin embargo, hay una limitación. El uso de este método debe limitar el número máximo de personas. Dado que se inicializa tan pronto como se activa, solo podemos estimar el establecimiento de una cierta cantidad de espacio de memoria, por lo que este método generalmente se usa en pequeños programas como salas de chat.

2. Este método debe considerarse más apropiado para grandes aplicaciones. Adopta un método de asignación dinámica. Solo cuando el usuario se conecte al servidor por primera vez, el recurso se asignará a este usuario. El propósito de estas dos soluciones de sesión simuladas es reducir el consumo de recursos de la sesión, pero después de todo, todavía es insustituible. Todavía necesitamos usar una pequeña sesión, lo que al menos puede reducir mucha carga en el servidor.

■ Primer plan

Primero comenzamos la implementación de la primera solución. Dado que es inicializar la aplicación cuando se activan, por supuesto, debemos comenzar desde Global.asa:

La inicialización se ha completado, pero ¿cómo usarla? Solo necesitamos cambiar la información almacenada utilizando la sesión, como la cuenta y el tiempo de inicio de sesión, en el objeto de aplicación que hemos creado, donde el usuario inicia sesión:

Para obtener los datos variables relevantes del usuario, es como los siguientes:

Response.Write (aplicación (user_account_ & session (índice))

¿Puede encontrar que no quiere decir no usar la sesión? Entonces, ¿por qué existe la sesión en el código original anterior? Como se mencionó anteriormente, esta alternativa no puede reemplazar completamente la sesión. El navegador no siempre está en línea con el servidor. Se desconectará después de leer la página. Entonces, ¿cómo sabemos si la misma persona está en línea la próxima vez? En este momento, tenemos que confiar en la sesión. Le damos al usuario un conjunto de números en tiempo real. Este número es el número del usuario en el espacio variable en la aplicación. Puedes imaginar que hay muchas cajas fuertes en el banco. Tiene una clave, y la clave tiene un número. El número en la clave permite al operador llevarlo a su propia caja fuerte. Este método tiene algunas mejoras, pero es suficiente para aplicaciones pequeñas.

■ Segundo plan

Con respecto a la solución anterior, también puede pensar que nuestro número personalizado utiliza la sesión para grabar. Hablando de numeración, el objeto de sesión proporciona un método "SessionID". Así es, no importa si queremos usarlo o no, el servidor ayudará automáticamente a cada usuario a asignar un número, y este número no se repetirá. En cuanto a este número, se obtiene con Session.SessionID. Esta numeración es una acción que definitivamente hará la sesión, por lo que podemos usarla para reemplazar el programa de numeración que escribimos nosotros mismos, lo que guarda otro esfuerzo e incluso tiene una mayor expansión. Pero básicamente, la primera solución anterior sigue siendo útil, como salas de chat que limitan el número de personas y otras aplicaciones pequeñas. La siguiente segunda alternativa es para sistemas más grandes.

Si un sitio web con cientos, miles o incluso decenas de miles de personas en un sitio web cada segundo, definitivamente no funcionará si usa la solución anterior. Supongamos que establece el límite superior de 10,000 personas, una vez que el servidor esté activado, lo ayudará a reducir 10,000 áreas para prepararse para 10,000 usuarios. Si hay 5 variables en una región, una variable representa 32 bytes (byte), y 10,000 representan más de 320,000 K (320MB), y una vez que el servidor se activa, se verá tanta basura en la memoria, y su rendimiento se reducirá inevitablemente mucho antes de que vaya al campo de batalla. Y a pesar de que estos números son muy pocos, creo que 512 MB de su propio será suficiente, se supone que el número anterior es un número mínimo, y se desconoce cuántos recursos usará el servidor al configurar la memoria, por lo que solo será más y no más bajo. Por lo tanto, la solución es configurar dinámicamente el espacio variable del usuario y cortar un área cuando un usuario está en línea con el servidor, por lo que no es necesario configurar una gran memoria por adelantado.

La segunda solución es relativamente simple de hacer. Deseche todas las cosas en la primera solución. No necesitamos mudarnos a Global.asa, solo necesitamos cambiar el inicio de sesión del usuario y otros lugares útiles:

Para obtener los datos variables relevantes del usuario, es como los siguientes:

Response.Write (Application (User_account_ & Session.SessionID))

En el pasado, leí muchos libros que decían que la sesión era muy difícil para comer recursos, así que trate de no usarlos, pero aún tengo que usarlos cuando tienen que hacerlo, y los libros no enseñaron una solución más apropiada. Ahora, cuando comprenda cómo reemplazar la sesión, ¡use bien! ¡Quizás los problemas de eficiencia que siempre se preocupan se pueden mejorar mucho!

Compartir: escriba un programa emergente más fácil de usar con ASP
Ejemplo de ASP: use ASP para escribir un programa emergente más fácil de usar para ayudarnos a crear un método de investigación que no sean desanimado. El uso de ventanas emergentes para mostrar cuestionarios se considera la forma más conveniente y rápida de recopilar información del usuario. Después del primer cuestionario se produce