for - Maestros ASP.NET: ¿Cuáles son las ventajas/desventajas de usar variables de sesión?
iis aspx web config (8)
Ya hice una búsqueda sobre este tema y encontré la misma información una y otra vez: una revisión de los tres tipos diferentes de sesiones. (InProc, Sql, StateServer) Sin embargo, mi pregunta es de naturaleza diferente.
Específicamente, ¿cuáles son las ventajas / desventajas de usar la sesión incorporada de .NET en primer lugar?
Esta es la razón por la que estoy preguntando: Un desarrollador compañero de .NET me ha dicho que NUNCA use la sesión de Microsoft integrada. De ningún modo. Ni siquiera crear un proveedor de estado de sesión personalizado. Su razonamiento para esto es el siguiente: si tiene activada la sesión en IIS, todas sus solicitudes se realizan de forma síncrona. Él dice que la sesión habilitante degrada el rendimiento de un servidor web.
Su solución a esto es crear una sesión usted mismo, una clase que almacena todos los valores que necesita y se serializa dentro y fuera de la base de datos. Él le aconseja que almacene el ID único para hacer referencia a esto en una cookie o una variable querystring. En nuestro entorno, usar un DB para almacenar las sesiones es un requisito porque todas las páginas que hacemos están en granjas web, y usamos Oracle, así que estoy de acuerdo con esa parte.
¿El uso de la Sesión incorporada degrada el rendimiento más que una Sesión casera? ¿Hay alguna preocupación de seguridad con esto?
Entonces, para resumir, ¿cuáles son las ventajas / desventajas?
¡Gracias a todos los que responden!
¿Hay alguna preocupación de seguridad con esto?
Si sacas los tuyos, tendrás que manejar los ataques de Fijación de sesión y Secuestro, mientras que usando la sesión integrada creo que se manejan por ti (pero podría estar equivocado).
Corrígeme si estoy equivocado:
La principal ventaja de almacenar el estado de la sesión en un DB, por ejemplo, SQL Server, es que no está consumiendo recursos de memoria, sino que lo almacena en un disco en formato db.
La desventaja es que tomas un golpe de IO para recuperar esta información de la base de datos cada vez que la necesitas (¿o tal vez SQL Sever incluso hace un caché mágico de los datos para ti basado en las consultas ejecutadas recientemente?)
En cualquier caso, este es el precio que un IO para recuperar la información de la sesión desde un db por viaje al servidor web parece una estrategia más segura para los sitios que se encuentran con mucho tráfico.
Debe ser prudente en el uso de la sesión, ya que varias solicitudes al mismo objeto de sesión generalmente se pondrán en cola: consulte "Solicitudes concurrentes y estado de la sesión" .
Tenga en cuenta que puede configurar EnableSessionState en ReadOnly para permitir el acceso de lectura concurrente al estado de la sesión.
Esta puesta en cola es algo bueno, ya que significa que los desarrolladores pueden usar Session sin preocuparse por la sincronización.
No estaría de acuerdo con la recomendación de su colega de "nunca" usar Session y ciertamente no consideraría hacer mi propia.
En primer lugar, su colega está implementando su propio sistema de gestión de sesiones respaldado por BD, no veo qué ventaja tiene esto sobre el uso del estado de sesión integrado almacenado en una base de datos (MS SQL es el predeterminado, no hay ninguna razón para no usar Oracle).
¿Su solución es mejor que la integrada en una? Improbable. Para empezar, es mucho más trabajo para usted. Aquí hay una ilustración simple de por qué. Supongamos que utiliza cookies para almacenar su ID, ¿cómo se las arregla con un usuario que desactiva las cookies? Si está utilizando el estado de sesión de ASP.Net, no hay problema, ya que recurrirá a la cadena de consulta. Con la idea de tus colegas, tienes que hacer tu propia.
Hay una pregunta muy válida sobre si se debe o no tener estado de sesión. Si puede diseñar su aplicación para que no necesite ningún estado de sesión, le resultará mucho más sencillo escalar y probar. Obviamente, puede tener un estado de aplicación que necesite vivir más allá de una sesión (caso simple, nombres de usuario y contraseñas), pero debe almacenar estos datos independientemente de si tiene estado de sesión.
La implementación de MS de Session State no es malvada en sí misma ... así es como lo usan algunos desarrolladores. Como se mencionó anteriormente, usar el proveedor de estado de sesión integrado significa que no tiene que reinventar los problemas de seguridad, antigüedad y concurrencia. Simplemente no empieces a atascar mucha basura en la sesión porque eres demasiado flojo para descubrir una mejor manera de administrar las transiciones de estado y página. La sesión no se escala realmente bien ... si cada usuario de su sitio incluye un montón de objetos en la sesión, y esos objetos ocupan un poquito de la memoria finita disponible para su aplicación, se encontrará con problemas antes que más tarde a medida que su aplicación crece en popularidad. Use la sesión de la manera para la cual fue diseñada: un token para representar que un usuario todavía está "usando" su sitio. Cuando empiezas a aventurarte más allá de eso, ya sea por ignorancia o por pereza, es probable que te quemes.
Mi experiencia ha sido que la sesión es un buen medio para administrar el estado cuando lo usa de manera apropiada. Sin embargo, muchas veces se usa mal, lo que provoca que muchos desarrolladores opinen que "nunca usar la sesión".
Yo y muchos otros desarrolladores nos hemos topado con importantes problemas de rendimiento cuando usamos la sesión por error para almacenar grandes cantidades de datos de una base de datos, a fin de "guardar un viaje". Esto es malo. Almacenar 2000 registros de usuario por sesión hará que el servidor web se ponga de rodillas cuando más de un par de usuarios usan la aplicación. La sesión no debe usarse como un caché de base de datos.
Sin embargo, almacenar un número entero por sesión es perfectamente aceptable. Pequeñas cantidades de datos que representan cómo el usuario actual está usando su aplicación (piense en el carrito de compras) es un buen uso del estado de la sesión.
Para mí, todo se trata de administrar el estado. Si se hace correctamente, la sesión puede ser una de las muchas formas de administrar el estado. Sin embargo, al principio debería decidirse cómo administrar el estado. La mayoría de las veces, nos encontramos con problemas cuando alguien decide simplemente "lanzar algo en la sesión".
Encontré this artículo realmente útil cuando uso modos fuera de proceso, y contiene algunos consejos que nunca habría pensado por mi cuenta. Por ejemplo, en lugar de marcar una clase como serializable, almacenar sus miembros de tipo de datos primitivos en variables de sesión separadas, y luego volver a crear el objeto puede mejorar el rendimiento.
Primero, un navegador solo hará dos solicitudes, a un nombre de host dado, en un momento dado. En su mayoría, estas solicitudes son para contenido estático (archivos JS, CSS, etc.). Por lo tanto, la serialización de las solicitudes de contenido dinámico no es casi el tema que uno podría pensar. Además, creo que esto puede confundirse con Classic ASP, donde las páginas que usan Session definitivamente están serializadas, no creo que este sea el caso con ASP.Net.
Con el estado de sesión ASP.Net (modo SQL, servidor de estado o personalizado), tiene una implementación que es estándar y coherente en toda la aplicación. Si no necesita compartir información de sesión, esta es su mejor opción. Si necesita compartir información con otros entornos de aplicaciones (php, swing / java, asp clásico, etc.) puede valer la pena considerarlo.
Otra ventaja / desventaja es que ha habido una gran cantidad de desarrolladores centrados en la metodología incorporada para las sesiones en lo que respecta al rendimiento y el diseño sobre la propia, incluso con un proveedor diferente.
la sesión de fabricación casera que ha descrito no está haciendo nada diferente al estado "SQL" de las sesiones de .Net y en mi experiencia, no creo que la sesión degrade su rendimiento de todos modos. construir su propio administrador de sesión requerirá realizar varias otras tareas de plomería: seguridad, limpieza, etc.
la ventaja de las sesiones integradas es su facilidad de uso con toda esta plomería ya procesada. con el modo "SQL" puede mantener los datos de la sesión en la base de datos, lo que le permite ejecutar su aplicación en granjas de servidores web sin ningún problema.
diseñamos una aplicación de comercio electrónico b2b para la compañía fortuna 57 que procesa más de 100 mil transacciones por día y usó sesiones [modo SQL] bastante extensamente sin ningún problema en absoluto.