Ventajas de la caché frente a la sesión

¿Cuál es la diferencia entre almacenar una tabla de datos en Session vs Cache? ¿Cuáles son las ventajas y desventajas?

Por lo tanto, si se trata de una página de búsqueda simple que devuelve el resultado en una tabla de datos y la vincula a una vista de cuadrícula. Si el usuario ‘a’ busca y el usuario ‘b’ busca, ¿es mejor almacenarlo en la sesión ya que cada usuario probablemente tenga diferentes resultados o aún puedo almacenar cada una de sus búsquedas en caché o eso no tiene sentido ya que hay solo un caché Creo que básicamente lo que trato de decir es que se sobrescribirá el Caché.

Una diferencia importante es que los elementos en la memoria caché pueden caducar (se eliminarán de la memoria caché) después de un período de tiempo específico. Los artículos puestos en una sesión permanecerán allí, hasta que la sesión termine.

ASP.NET también puede eliminar elementos de la memoria caché cuando la cantidad de memoria disponible se reduce.

Otra diferencia: el estado de la sesión puede mantenerse externo (servidor de estado, servidor SQL) y compartido entre varias instancias de su aplicación web (para el equilibrio de carga). Este no es el caso con la memoria caché.

Además de estas diferencias (como otros señalaron): la sesión es por usuario / sesión, mientras que la caché es por aplicación.

AFAIK, la diferencia clave es que la sesión es por usuario, mientras que la caché será para los artículos con scope de la aplicación.

Como se indicó en las otras respuestas, puede almacenar información por usuario en la caché, siempre que proporcione una clave (ya sea por sesión o por cookie). Entonces tendría más control para caducar los elementos en el caché y también establecer dependencias en ellos. Entonces, si la DataTable en cuestión va a cambiar de manera regular, entonces el almacenamiento en caché probablemente sea una opción adecuada. De lo contrario, si es sesión estática podría ser más apropiado. Steven Smith tiene un excelente video sobre el almacenamiento en caché en dnrtv que vale la pena echarle un vistazo.

Realmente depende de lo que estás tratando de lograr, cuánto tiempo tienes. Hay otras alternativas a considerar con respecto a cómo almacenar el estado en una aplicación. Dependiendo de cuán grande sea la tabla, podría considerar almacenar el estado en una cookie (encriptada si es información confidencial). Alternativamente, si se trata de datos del ámbito de la aplicación, utilice un campo estático en una página o clase. También está el objeto Aplicación.

Actualización : Creo que la pregunta clave que debe hacerse es quién debería ver estos datos.

 Are they going to access the data frequently? 

(No, no te molestes).

 Is it going to change? 

(No, use un campo estático o Aplicación).

 Is it acceptable for user a and user b to see the same results? 

(No, use la caché con una clave que incluya el nombre de usuario y el término de búsqueda).
(Sí, use la caché usando una clave del término de búsqueda).

Honestamente, sin embargo, si no estás lejos en tu desarrollo, consideraría aparcar el problema del almacenamiento en caché / estado para una fecha posterior, incluso puede que no lo necesites.

Las primeras tres reglas de ajuste del rendimiento son: 1. Medir, 2. Medir un poco más. 3. Medir de nuevo …

Otra diferencia importante es que el estado de la sesión se bloqueará si se ejecutan solicitudes concurrentes de async Ajax, esto afectará el rendimiento

La memoria caché se encuentra en el ámbito Aplicación con el objective de reducir el número de veces que se obtiene una información. La sesión se encuentra en el ámbito de sesión de un usuario con el fin de proporcionar un estado de usuario particular.

Bueno, depende de cómo haya configurado la sesión para ASP.NET. ¿Estás almacenando sesión en una base de datos o en la memoria? Si en la memoria está utilizando un servidor separado o está utilizando el servidor web actual para la sesión?

Dependiendo de cómo se configuren las cosas para usted, puede haber implicaciones de rendimiento cuando está usando algo como una tabla de datos que me dice que quizás esté almacenando grandes cantidades de datos.

Además, la sesión se almacena por usuario y se recupera por usuario mediante su ticket de sesión que se almacena en una cookie de sesión o en la URL si no aceptan cookies y usted ha configurado ASP.NET en modo sin cookies. Todo lo que almacena en caché se almacenará en caché en el nivel de la aplicación y estará disponible para todas las sesiones de usuario que pueden ser o no lo que usted desea.

La sesión es por usuario, la memoria caché es para la aplicación.

Los elementos en Caché pueden eliminarse automáticamente en función de los tiempos de caducidad (deslizantes o fijos) y de las limitaciones de memoria del proceso de trabajo de IIS.

Así que, básicamente, los elementos en Caché nunca se garantiza que existan, pero la sesión permanecerá allí hasta que finalice la sesión.

El almacenamiento de elementos por usuario (a través de la sesión o de un uso creativo de Cache) puede generar una gran cantidad de memoria y debe considerarse con cuidado.

Además de todo esto, si IIS restablece el proceso de trabajo, puede perder su caché y sesión.

Vea esta respuesta .

La sesión puede matar el rendimiento de tu aplicación, a menos que uses algún proveedor de back-end como memcached o velocidad. En general, debes evitarlo.

La sesión I usa específica donde Cache no lo es. Este artículo es útil .