variables de sesión vs variables locales

Question

Siempre que tengo para almacenar cualquier cosa en la sesión, me han cogido el hábito de reducir al mínimo el número de veces que tengo que acceder a la sesión haciendo algo como esto:

private List<SearchResult> searchResults; 

private List<JobSearchResult> SearchResults 
    { 
     get 
     { 
      return searchResults ?? (searchResults = Session["SearchResults"] as List<SearchResult>); 
     } 

     set 
     { 
      searchResults = value; 
      Session["SearchResults"] = value; 
     } 
    } 

Mi El razonamiento es que si el objeto se usa varias veces durante una devolución de datos, el objeto debe recuperarse de la sesión con menos frecuencia. Sin embargo, no tengo ni idea de si esto realmente ayuda en términos de rendimiento, o de hecho es solo una pérdida de tiempo, o incluso una mala idea. ¿Alguien sabe cuán computacionalmente costoso sacar constantemente un objeto de la sesión se compararía con el enfoque anterior? O si hay algunas mejores prácticas que rodean esto?

Answer 1

depende de qué tipo de almacenamiento de sesión que está utilizando (para más información, véase: here).

Si está utilizando el almacenamiento InProc, entonces la diferencia de rendimiento es probablemente mínimo, a menos que estés acceder al objeto con mucha frecuencia. Sin embargo, la copia local realmente no duele de ninguna manera.

Answer 2

Depende del tamaño de los datos que se almacenarán, ancho de banda (internet o LAN), escala de aplicación. Si el tamaño de los datos es pequeño, el ancho de banda es lo suficientemente bueno (LAN), la escala es mundial (como Whitehouse.gov), debemos almacenarlo en el lado del cliente (como parámetro oculto). En otras situaciones (el tamaño de los datos es muy grande, el ancho de banda es muy bajo, la escala es pequeña (solo un grupo de 3-4 personas usará la aplicación), luego podemos almacenarlo en el servidor (sesión). Hay muchos otros factores para considerarlos en esta elección de decisión. Además, no recomendaría que use solo un campo en el objeto de sesión. Cree algo como Dictionary (HashMap en Java) en sesión, y úselo como almacenamiento y el usuario debe pasar la clave de este Diccionario para obtener estos datos es necesario para proporcionar la capacidad del usuario para abrir su sitio web en varias pestañas

Ejemplo de URL, el acceso de búsqueda necesario:..

http://www.mysite.com/SearchResult.aspx?search_result=d38e8df908097d46d287f64e67ea6e1a 

Answer 3

seguramente depende de su S unidad torage, pero es un buen enfoque en cualquier caso, ya que le impide DeSerialization si el almacenamiento no es InProc ... e incluso en el caso de InProc impide Boxing \ UnBoxing ... por lo que mi voto es a favor de su enfoque.

Answer 4

No veo nada de malo con su enfoque. El único inconveniente es que cuando otra parte de su código (o el de otra persona) cambia el valor de la sesión después de que su campo privado se haya inicializado, su propiedad contenedora aún devolverá el valor anterior. En otras palabras, no hay garantía de que su propiedad realmente devuelva el valor de la sesión, excepto por primera vez.

En cuanto al rendimiento, creo que en el caso de InProc hay poca o ninguna ganancia. Probablemente similar a cualquier otro diccionario vs almacenamiento variable. Sin embargo, puede marcar la diferencia cuando usa otros modos de almacenamiento de sesión. Y si realmente quieres saber puedes personalizar tu aplicación y descubrirla;) Incluso puedes probar algo tan simple como 2 escrituras de rastreo y algunas lecturas/escrituras de sesión en bucle entre ellas.

Y aquí es una lectura de partes internas de almacenamiento de sesión: http://www.codeproject.com/KB/session/ASPNETSessionInternals.aspx