Pros y contras de usar ASP.NET Session State Server (en lugar de InProc)?

Question

Antes de comenzar a usar el servidor de estado de sesión para que el estado de la sesión sea más sólido en mis aplicaciones en comparación con el estado de InProc, me gustaría encontrar una lista de pros y contras para la evaluación.

Actualización 1: ¿También sobre la supervivencia de reciclado de grupos de aplicaciones?

Actualización 2: ¿Qué hay de la longevidad de las sesiones y sus finales?

Answer 1

Aquí está el análisis canónico de los pros y los contras de sus tres opciones, desde ASP.NET Session State el artículo de Rob Howard:

• En proceso de. En proceso funcionará mejor porque la memoria de estado de la sesión se mantiene dentro del proceso ASP.NET. Para aplicaciones web alojadas en un único servidor, aplicaciones en las que se garantiza que el usuario será redirigido al servidor correcto, o cuando los datos del estado de la sesión no son críticos (en el sentido de que pueden reconstruirse o rellenarse) , este es el modo para elegir.

• Fuera de proceso. Este modo se utiliza mejor cuando el rendimiento es importante, pero no se puede garantizar a qué servidor solicitará un usuario una aplicación. Con el modo fuera de proceso, obtiene el rendimiento de la lectura de la memoria y la confiabilidad de un proceso separado que administra el estado de todos los servidores.

• SQL Server. Este modo se utiliza mejor cuando la confiabilidad de los datos es fundamental para la estabilidad de la aplicación, ya que la base de datos se puede agrupar para escenarios de falla. El rendimiento no es tan rápido como fuera de proceso, pero la compensación es el mayor nivel de fiabilidad.

Las opciones fuera del proceso (también conocido como "StateServer") y SQL-Server ambas sobrevivir reinicia la aplicación web (incluyendo grupo de aplicaciones en bicicleta) y ambos hacen los datos de sesión disponibles para múltiples servidores de un clúster/granja.

Finalmente, puede ser evidente, pero la configuración básica en proceso es la más fácil de configurar, que es un "pro" significativo en muchos entornos.

Tim Sneath ASP.NET Session State: Architectural and Performance Considerations agrega algo de información adicional, y MSDN topic on Session State Modes es una fuente confiable y actualizada.

Answer 2

Ventajas:
1. Puede acceder al mismo estado de sesión en todas las máquinas.
2. El mismo estado de sesión está disponible después de volver a cargar app_pool.

Desventajas:
1. Más lento que en el modo de proceso.
2. Todos los objetos en el estado de la sesión deben ser serializables.

Answer 3

Otra desventaja es que probablemente tendrá un único punto de falla si realiza 1 servidor de estado remoto en una granja de servidores. Incluso si no es una granja, vale la pena ejecutarla localmente solo para sobrevivir app_pool IMO. Nos quedamos atrapados en la parte serializable, así que mira eso.

Además, esté atento a Windows Server AppFabric para su lanzamiento, ya que tendrá una sustitución del servidor de estado replicado/distribuido. Supuestamente RTM en 1H2010.

Answer 4

Yo diría que una de las grandes desventajas de usar In_Proc es que el estado de la sesión se puede perder si se recicla el grupo de aplicaciones o el dominio. Esto puede suceder en cualquier momento, por ejemplo, si el servidor tiene poca memoria, etc. Personalmente nunca confío en In_Proc sesión para cualquier cosa que no quiera perder. Pasé horas depurando sitios con problemas esporádicos solo para descubrir que se debía a que el estado de la sesión se estaba perdiendo debido a que el servidor tenía pocos recursos de reciclaje (y, por supuesto, cuanto más almacena en sesión, menores son los recursos del servidor que agotar.Recuerde, si puede salir mal, entonces probablemente va a salir mal en algún momento!

Es por eso que ahora normalmente uso State Server para cualquier cosa menos datos de sesión triviales. La única desventaja real que he encontrado es que necesita para marcar las clases como serializable, pero esto suele ser trivial. también es un poco más lento, también, pero eso es despreciable en la mayoría de los casos.

Hay a good article about this en el blog de MSDN IIS.

Answer 5

State Server es una gran opción (!) (!) para comenzar. ¿Por qué? Porque significa que su aplicación ahora es compatible con cualquier modo de almacenamiento fuera de proceso.

Si actualmente desarrolla su sitio con InProc y desea cambiar a StateServer o SqlServer en otro momento, puede tener problemas con la serialización. No siempre, pero sucede.

Algunos ejemplos incluyen (algunos ya mencionado):

• Operaciones empiezan programación de aplicación IIS regulares recicla sin su conocimiento
• memoria se está agotando en una base regular
• Usted va a trabajar con una equilibrador de carga en producción y no puede garantizar que el mismo sitio web reciba la misma solicitud.

Por lo tanto, es mejor solucionar esto más temprano que tarde. Es solo un cambio de configuración y un inicio de servicio; ¡Auge!

Lo que también significa que si decide seguir una ruta de almacenamiento de sesión completamente diferente, como utilizar Redis (Distributed Key/Value Store) o RavenDB (Document Database), ya está ordenado.

Realmente es una buena inversión de 1 minuto de trabajo. Ahora está listo para granjas de servidores web, equilibradores de carga y cualquier otro sistema de gestión de sesiones con el que decida prototipar.

Answer 6

desventajas de Sesiones en ASP.NET

• Toda variable se almacena como objeto. Eso significa que necesita convertir Object a cierto tipo cuando lee la variable de sesión.
  

• Además de esto, si la sesión está vacía, Object será nulo. Antes de leer la variable de sesión, debe verificarla como nula.Incluso si la variable se inicializa antes, podría ser nula porque la sesión ha expirado. Un intento de usar valor de sesión nulo podría devolver una excepción. Si el valor de la variable de sesión es nulo, la práctica común es usar algún valor predeterminado en lugar de nulo sin sentido. Si el valor no es nulo, debe convertirlo al tipo apropiado porque todas las variables de sesión son del tipo de objeto. Cuando hagas todo esto, deberías prestar atención para evitar una codificación difícil. Obtenga más información acerca de cómo leer y escribir variables de sesión en una forma escalable y mantenible que puede leer en el tutorial Cómo escribir, leer y eliminar lecciones de estado de sesión.
  

• El nombre de la variable es el tipo de cadena. Si codifica el nombre de la variable, hay una opción para hacer que el tipo se confunda en alguna parte. El problema es que, si intenta leer la variable de sesión que no existe, ASP.NET no devolverá ninguna excepción o advertencia. Simplemente creará una nueva variable con un nombre incorrecto que tiene un valor nulo. Este tipo de errores podría ser difícil de encontrar.
  

• Los datos de sesión no se deben utilizar para almacenar datos confidenciales. Existe la posibilidad de que el usuario malintencionado obtenga el ID de sesión del visitante habitual. Si el estado de la sesión se usa para almacenar información como: "permitir el acceso al área de administración o no" o algo así, el atacante podría ver los datos confidenciales del sitio, datos privados de otros, editar la base de datos, eliminar contenido, etc.
  

• If InProc se usa el modo, las sesiones agotan fácilmente todos los recursos del servidor y, por lo tanto, disminuyen el rendimiento del sitio web.

StateServer

SQL Server es más fiable de todos modos. Los datos de sesión están intactos si ASP.NET se reinicia, pero también si SQL Server se reinicia.

SQL Server es también la opción más escalable.

SQL Server menudo está disponible en escenario de alojamiento compartido

modo personalizado

Usted tiene el control completo sobre las sesiones. Es posible crear incluso una identificación de sesión personalizada.

Puede admitir diferentes fuentes de datos. Eso podría ser útil para almacenar datos de sesión en otra base de datos, como Oracle, MySQL, MS Access, etc.

para cualquier otro detalle que pueda click here to view ASP.NET Session state advantages. Espero que mi respuesta te haya ayudado. :)