Cualquiera que haya escrito un ASP un poco más grande sabe que la sesión es realmente útil. ¿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 (como el sistema de compras registra los productos en la cesta de compras del usuario), esta información son las necesidades privadas de cada usuario, y generalmente el desarrollador utiliza It.
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 cookies. Este es el principio operativo de la sesión. reconfigurar la memoria, etc. Acción inicial. Ahora puede pensar: "Tengo que usar esta función, así que tengo que sacrificar un poco". Curso hay alternativas.
La aplicación también es buena para grabar y procesar datos temporales. La aplicación no es como la sesión, que no pasa los datos al usuario y espere la próxima vez para leerlo en línea.
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 una sesión de simulación. Hay dos formas de hacerlo ahora:
1. Inicializar y asignar el espacio de memoria del usuario por adelantado cuando el servidor se activa. . Sin embargo, hay una limitación. Pequeños programas como salas de chat.
2. Este método debe considerarse más apropiado para grandes aplicaciones. 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.
■ Primer plan
Primero comenzamos la implementación de la primera solución.
La inicialización se ha completado, pero ¿cómo usarla? Solo necesitamos cambiar la información almacenada en 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:
| 'Buscando espacio no utilizado Para i = 1 a la aplicación (ClientMax) Si la aplicación (user_status_ & i) = 0 entonces 'Número temporal del usuario Sesión (índice) = i 'cierre Aplicación Application.lock 'Establecido en el estado usado Aplicación (user_status_ & i) = 1 'Poner en datos variables Aplicación (user_account_ & i) = cuenta Aplicación (user_logtime_ & i) = ahora () 'Desbloqueado Aplicación Salir Final si Próximo |
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 por completo la sesión. En este momento, tenemos que confiar en la sesión. . Tienes una llave, y la clave es que hay números, y el número en la llave permite que el entrenador te lleve a tu 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 registrar. 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á. 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 las salas de chat que limitan el número de personas y otras aplicaciones pequeñas.
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 se activa el servidor, le ayudará a reducir 10,000 áreas para prepararse para 10,000 usuarios. Solo representa más de 320,000 K (320 MB). Pocos, creo que 512 MB de su propia será suficiente. 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.
| 'Bloquear ApplicationApplication.Lock' Ponga datos variables Aplicación (user_account_ & session.sessionID) = cuenta Aplicación (user_logtime_ & session.sessionID) = ahora () 'Desbloquear desbloqueo Aplicación.unlock |
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!