Mantener los datos en sesión frente a rellenar en devolución de datos

Question

¿Qué es preferible, mantener un conjunto de datos en sesión o completar el conjunto de datos en cada devolución de datos?

Answer 1

Eso dependería de muchos factores. Por lo general, es mejor no guardar demasiados elementos en la memoria de la sesión si su sesión es en proceso o en un servidor de estado porque es menos escalable.

Si su sesión reside en la base de datos, podría ser mejor simplemente volver a consultar y volver a llenar el conjunto de datos a menos que la consulta sea costosa de ejecutar.

Answer 2

¡No uses la sesión! Si el usuario abre una segunda pestaña con una solicitud diferente, la sesión se reutilizará y los resultados no serán los esperados. Puede usar una combinación de ViewState y Session, pero igual puede medir cuánto puede manejar sin ningún tipo de almacenamiento en caché antes de recurrir al almacenamiento en caché.

Answer 3

Depende de cuánto lo haga y de dónde se almacenan los datos de la sesión en el servidor.

Mantener los conjuntos de datos en sesión sin duda afecta a uso de memoria . Todas las variables de sesión se almacenan en la memoria o en el servidor SQL si utiliza el estado de SQL Server. También puede descargar la carga a una máquina diferente usando el modo de servidor de estado.

El aspecto de serialización / deserialización. Si utiliza conjuntos de datos increíblemente grandes, podría influir de manera negativa en el rendimiento del servidor.

Por otra parte, tener viewstates muy grandes en las páginas puede ser un verdadero asesino del rendimiento . Así que mantendría los conjuntos de datos en sesión o en el caché y buscaría un " outproc " forma de almacenar los datos de esa sesión.

Answer 4

Ya que quiero la menor cantidad posible de operaciones de base de datos, mantendré los datos en sesión, pero no estoy seguro de cuál sería la mejor manera de hacerlo. ¿Cómo manejo la concurrencia y también como los datos se comparten cuando dos usuarios usan la página simultáneamente? ¿Cómo puedo asegurarme de que cada uno de ellos tenga su propio conjunto de datos en la sesión?

Answer 5

Por lo general, lo mantengo en sesión si no es demasiado grande y / o la base de datos es muy lenta. Si los datos son grandes, en general, es mejor recargar.

A veces uso el caché, cargo desde Db la primera vez y lo pongo en el caché. Durante la devolución de datos reviso el chache y si está vacío recargo. Así que el servidor gestiona el caché por sí mismo.

Answer 6

el problema con la sesión es que si está en proceso podría desaparecer, lo que no es bueno, si es un servidor de estado, entonces tienes que serializar y si es una situación simple, estás haciendo un viaje de ida y vuelta de todos modos.

si el conjunto de resultados es grande, realice la paginación personalizada de modo que solo esté devolviendo un pequeño subconjunto de los resultados totales.

entonces, si cree que más de un usuario verá este conjunto de resultados, coloque cada página en la memoria caché como las páginas de usuario asegurándose de que la memoria caché se renueve cuando los datos cambien o después de un tiempo no se acceda a ellos.

si no desea realizar muchos viajes de ida y vuelta y cree que tiene la memoria, coloque todo el conjunto de datos en el caché, pero tenga cuidado de que no se derrita el servidor web.

usar el caché significa que los usuarios no necesitan su propio conjunto de datos, en lugar de usar el conjunto global.

en cuanto a la concurrencia cuando carga la página de inserción / edición, debe rellenarla con datos nuevos y renovar la caché después de agregar / actualizar.

Answer 7

Soy un gran creyente en el desacoplamiento y rara vez, si acaso, veo la necesidad de lanzar un conjunto de datos completo a la interfaz de usuario.

En realidad, solo debe pasar objetos a la interfaz de usuario que debe usarse, por lo que, a menos que esté mostrando un diagrama grande o algún tipo de estructura de datos que necesite mostrar relaciones entre los datos, no vale la pena el costo.

Los subconjuntos de datos más pequeños, cuando corresponde, son mucho más eficientes. ¿Está su aplicación realmente utilizando todas las características dentro de un conjunto de datos en la interfaz de usuario? Si no es así, entonces la mejor manera de proceder sería pasar solo los datos que está mostrando.

Si está vinculando datos a un control y clasificación / paginación, puede implementar muchas de las interfaces que permiten al conjunto de datos admitir esto, en un fragmento de código mucho más pequeño.

En esa nota, mantendría los datos, que son en gran parte estáticos (por ejemplo, no se actualizan con tanta frecuencia) en el caché. Por lo tanto, debe ver con qué frecuencia se actualizan los datos antes de poder tomar una decisión al respecto.

Por último, lo diré de nuevo, veo la necesidad de utilizar un conjunto de datos en la interfaz de usuario muy, muy raramente ... es un objeto de datos muy pesado y los beneficios de costo de considerar sus requisitos de datos, en comparación con la facilidad de implementación , podría superar con creces la necesidad de almacenar en caché un conjunto de datos.

En mi humilde opinión, los conjuntos de datos son bastante malos de usar si está preocupado por el rendimiento o la utilización de la memoria.

Answer 8

Su respuesta no insinúa el uso de los datos. ¿Son datos de referencia? ¿El usuario lo está actualizando activamente? ¿Se supone que más de un usuario tiene acceso de actualización a la vez?

Sin información mejor que la que usted proporcionó, confíe en la sabiduría aceptada que dice que mantener grandes cantidades de datos en la sesión es una forma de garantizar que su aplicación no se escalará y requerirá recursos considerables para servir un puñado de personas.

Por lo general, existen mejores formas de administrar grandes conjuntos de datos sin tener que recargar todos los datos en la memoria.

Si no es así, si las necesidades de datos de su aplicación son verdaderamente monstruosas, considere un cliente pesado con un servicio web de back-end. Puede ser más adecuado que hacer una página web.

Answer 9

Como han señalado otras respuestas, la respuesta " depende " ;. Sin embargo, asumiré que está hablando de datos que se comparten entre los usuarios. En ese caso, debe no almacenar el conjunto de datos en la sesión del usuario, pero repoblar en la devolución de datos.

Además, debe llenar un caché cerca de la capa de acceso a datos de su aplicación para aumentar el rendimiento interactivo y reducir la carga en la base de datos. El diseño de su caché dependerá nuevamente del tipo de datos (solo lectura frente a lectura / escritura frente a lectura en su mayoría).

Este enfoque desacopla la sesión del usuario (un concepto de la capa UI) de la gestión de datos y proporciona el beneficio adicional de apoyar el uso compartido de datos almacenados en caché (en los casos en que los datos son comunes entre los usuarios).

Answer 10

Tampoco, no "mantener" ¡cualquier cosa! Muestra solo lo que un usuario necesita ver y crea un esquema de paginación eficiente para ver las filas hacia atrás o hacia adelante.

rp

Answer 11

Mantente en sesión. Tiene la opción de repoblar si lo necesita, por ejemplo, si se borra la memoria de la sesión.