¿Cuántos datos de la sesión son demasiado?

Question

Nos encontramos con problemas de uso de memoria inusualmente altos. Y observé que en muchos lugares de nuestro código estamos sacando cientos de registros de DB, empaquetándolos en objetos de datos personalizados, agregándolos a un arraylist y almacenándolos en sesión. Deseo saber cuál es el límite superior recomendado para almacenar datos en sesión. Solo una buena práctica, una mala práctica.

Estoy usando JRockit 1.5 y 1.6GB de RAM. Hice perfiles con Jprobe y descubrí que algunas partes de la aplicación tienen una memoria muy grande. La mayoría de estos datos están en sesión para ser usados ​​más tarde.

Answer 1

Eso depende completamente de cuántas sesiones están normalmente presentes (que a su vez depende de cuántos usuarios tiene, cuánto tiempo permanecen en el sitio y el tiempo de espera de la sesión) y la cantidad de RAM que tiene su servidor.

Pero antes que nada: ¿ha usado realmente un generador de perfiles de memoria para decirle que su "uso de memoria alta" es causado por datos de sesión, o simplemente está adivinando?

Si el único problema que tiene es "uso elevado de memoria" en una máquina de producción (es decir, puede manejar la carga de producción pero no funciona tan bien como le gustaría), la solución más fácil es obtener más RAM para el servidor, mucho más rápido y más barato que rediseñar la aplicación.

Pero el almacenamiento en caché de conjuntos de resultados completos en la sesión también es malo por una razón diferente: ¿qué ocurre si los datos cambian en la base de datos y el usuario espera ver ese cambio? Si va a almacenar en caché, use one of the existing systems que hace esto en el nivel de solicitud de DB: le permitirán almacenar en caché los resultados entre los usuarios y tienen facilidades para la invalidación de caché.

Answer 2

Si almacena datos en sesión para mejorar el rendimiento, considere utilizar el almacenamiento en caché real ya que la caché es para toda la aplicación, mientras que la sesión es por usuario, lo que resulta en una duplicación innecesaria de objetos similares.

Si, sin embargo, los está almacenando para que el usuario edite estos objetos (lo cual dudo, ya que cientos de objetos son demasiados), intente minimizar la cantidad de datos almacenados o investigue el control de concurrencia optimista.

Answer 3

Diría que esto depende en gran medida de la cantidad de sesiones activas que esperas. Si está escribiendo una aplicación de intranet con < 20 usuarios, ciertamente no es un problema poner unos MB en la sesión. Sin embargo, si está esperando 5000 sesiones en vivo, por ejemplo, cada MB de datos almacenados por sesión representa 5 GB de RAM.

Sin embargo, generalmente recomiendo no almacenar ningún dato de DB en sesión. Solo busque de DB para cada solicitud. Si el rendimiento es un problema, use un caché de toda la aplicación (por ejemplo, el caché de segundo nivel de Hibernate).

Answer 4

¿Qué tipo de datos es? ¿Es realmente necesario por sesión o podría almacenarse en caché a nivel de aplicación? ¿Realmente necesitas todas las columnas o solo un subconjunto? ¿Con qué frecuencia se está accediendo? ¿En qué páginas debe estar disponible? Y así.

Puede tener mucho más sentido recuperar los registros del DB cuando realmente lo necesite. Almacenar cientos de registros en sesión nunca es una buena estrategia.

Answer 5

Yo diría que intentan almacenar la cantidad mínima de datos que será suficiente para recrear el entorno necesario en una solicitud posterior. Si está almacenando en la memoria para evitar una base de datos de ida y vuelta, entonces una verdadera solución de almacenamiento en caché como Memcache podría ser útil.

Si está almacenando estas sesiones en la memoria en lugar de una base de datos, se guarda el viaje de ida y vuelta y las solicitudes se atenderán más rápido siempre que la carga de memoria sea baja y no haya paginación. Una vez que el número de clientes sube y comienza la búsqueda, la mayoría de los clientes verán una gran degradación en los tiempos de respuesta. Ambas variables e inversamente relacionadas.

Es mejor para medir la latencia de su servidor de base de datos, que generalmente es lo suficientemente bajo en la mayoría de los casos para ser considerado como un medio viable de almacenamiento en lugar de en la memoria.

Answer 6

Intente dividir los datos que está almacenando actualmente en la sesión en datos estáticos y específicos del usuario. Luego implemente el almacenamiento en caché para todas las partes estáticas. Esto le dará una gran cantidad de reutilización para toda la aplicación y aún le permitirá almacenar en caché los datos específicos en los que está trabajando un usuario.

Answer 7

También podría crear una base de datos mini sqlite por usuario y conectarse, y almacenar los datos a los que el usuario accede, luego simplemente recuperar los registros, mientras el usuario lo solicita y después de que el usuario se desconecte simplemente elimine la base de datos sqlite.