Limitación del tamaño de la sesión ASP.NET

¿Hay algún tipo de limitación de tamaño de la sesión o valor aconsejable para no superar?

En mi aplicación web creo algunas tablas de datos para almacenar selecciones de usuarios que se almacenan en sesión hasta que el usuario aprueba las selecciones, así que agrego esos valores a la base de datos.

El problema es que no sé si la sesión es lo suficientemente confiable como para mantener pocos objetos dentro o no.

¡Gracias!

más información

El tamaño de la sesión es de aproximadamente 10-20 KB máximo.

Sí, es lo suficientemente confiable . Simplemente no es muy escalable , así que planee con anticipación. Esto se detendrá por completo cuando lo ejecute en más de 1 servidor.
Y hay una especie de límite: Número de usuarios simultáneos * Tamaño de sesión

Depende, por supuesto, del tamaño de las tablas, el almacenamiento de algunos kB suele ser aceptable (aunque los sitios con mucho tráfico intentarán mantenerlo más pequeño).

Si sus usuarios pueden compartir tablas, puede colocar esos datos en el objeto Aplicación, un gran ahorro.

Y un objeto de sesión está limitado a la configuración TimeOut, el valor predeterminado es 20 min. Una manera de optimizar el consumo de memoria es reducir eso, pero eso es una compensación con la conveniencia del usuario.

Aquí hay algunas notas sobre el estado de la sesión:

  • InProc ( mode="InProc" ) el estado de la sesión está limitado a la cantidad de memoria disponible para el proceso de trabajo. Solo se almacenan las referencias de objeto, no los objetos mismos.

La gestión de estado fuera de proceso serializa los objetos antes de persistirlos:

  • La gestión de estado fuera de proceso que utiliza el servidor de estado de sesión ( mode="StateServer" ) está limitada a la cantidad de memoria disponible para el servicio de estado.

  • La gestión del estado fuera de proceso que utiliza SQL Server ( mode="SQLServer" ) está limitada solo por el tamaño máximo del tipo de datos de image SQL o el tamaño máximo permitido de la base de datos.

Obviamente, todavía debe haber suficiente memoria disponible para el proceso de trabajo para poder devolver un objeto fuera de sesión a la memoria y volver a hidratarlo mientras dure la solicitud http.

Como mencioné anteriormente, la administración estatal fuera de proceso serializa objetos antes de persistirlos.

Esto significa que los objetos deben ser serializables, lo que excluye , por ejemplo, XmlDocument o cualquier cosa que herede de MarshalByRef .

Intentar serializar objetos de este tipo dará como resultado la siguiente excepción:

No se puede serializar el estado de la sesión. En el modo ‘StateServer’ y ‘SQLServer’, ASP.NET serializará los objetos de estado de sesión y, como resultado, no se permiten objetos no serializables ni objetos MarshalByRef. La misma restricción se aplica si la serialización similar es realizada por el almacén de estado de sesión personalizado en el modo ‘Personalizado’.

Supongo que está guardando la sesión en el modo “inProc”. En este modo, la sesión de las aplicaciones ASP.NET, el caché, etc. se almacenan en la RAM del servidor web (a través del proceso aspnet_wp.exe). Y .NET no puede usar todo. Hay una configuración en machine.config que indica el límite de umbral (por defecto 60%). Una vez que se alcanza este umbral, IIS reciclará el proceso de trabajo y se perderá toda la información de la sesión.

Tenga en cuenta que, si su servidor aloja más de una aplicación asp.net, todas las aplicaciones compartirán el 60% de la memoria. Entonces, si el uso acumulativo de memoria alcanza el umbral, el proceso de trabajo aún se recicla.

Alternativamente a esto, además de optimizar su aplicación para usar la sesión con moderación, es configurar la aplicación para que use la sesión en modo fuera de proceso (usando un servidor de estado o un servidor sqlserver para almacenar información de sesión).

El modo fuera de proceso puede reducir el rendimiento de su sistema.

Consulte este artículo para obtener más información sobre Session State Management.

Siempre debe suponer que la sesión es un almacenamiento muy valioso y muy limitado. El consumo debe ser lo mínimo posible, ya que nunca se sabe cuántos usuarios admitirá la aplicación.

DataTable puede ser demasiado grande para almacenar en sesiones, a menos que se pueda mantener lo suficientemente pequeño.