c# - data - Pros/Contras de diferentes opciones de almacenamiento en caché ASP.NET

web api cache data

Question

Hace poco hice una pregunta acerca de los datos de la aplicación de almacenamiento en caché en una aplicación ASP.NET MVC WebAPI y esto me llevó a una nueva pregunta. ¿Cuáles son los pros / contras de los diferentes métodos de almacenamiento en caché disponibles en ASP.NET?

Me he encontrado con:

• Memoria caché

  http://msdn.microsoft.com/en-us/library/system.runtime.caching.memorycache.aspx

• Usando variables de miembros estáticos:

  private static Northwind.SuppliersDataTable suppliers = null;

• Estado de aplicación:

   HttpContext.Current.Application["key"] ="Value"

• Caché de datos:

  HttpRuntime.Cache.Insert(
    /* key */                "key", 
    /* value */              "value", 
    /* dependencies */       null, 
    /* absoluteExpiration */ Cache.NoAbsoluteExpiration, 
    /* slidingExpiration */  Cache.NoSlidingExpiration, 
    /* priority */           CacheItemPriority.NotRemovable, 
    /* onRemoveCallback */   null);

Estoy seguro de que hay otros, y sé que todos ellos almacenan técnicamente los datos en la memoria ... así que ¿alguna idea de lo que debería usar para un ASP.NET MVC webapi?

Mi pregunta anterior: datos de la aplicación de almacenamiento en caché en la memoria: MVC Web API

Answer 1

Al utilizar la API web, la primera opción para el almacenamiento en caché siempre debe ser establecer los encabezados de almacenamiento en caché en la respuesta HTTP. HttpResponseMessage.CacheControlHeader .

Tus últimas opciones deberían ser cualquier cosa que dependa de HttpContext o HttpRuntime , ya que eso te vinculará a hosts particulares. Las aplicaciones de la API web deben construirse independientemente de su host.

Answer 2

Cada tecnología / método de caché tiene su propio conjunto de características. Estas características pueden parecer una desventaja en los requisitos de una aplicación, pero pueden ser ventajosas en otros requisitos de la aplicación.

Por lo tanto, en resumen, según sus necesidades, decida qué tecnología de almacenamiento en caché y qué funciones son las mejores para usted.

For example, Let us discuss some client side Caching techniques .

MSDN dice que también podemos usar HiddenField para almacenar solo pequeñas cantidades de datos que cambian con frecuencia en campos ocultos porque estos datos están incluidos en los recorridos de ida y vuelta al servidor en cada devolución.

Ventaja de esta característica: reduce la carga de trabajo en su servidor almacenando información de la página usando opciones del lado del cliente.

Sin embargo, MSDN dice claramente que: este enfoque tiene un mínimo soporte de seguridad.

Por lo tanto, uno puede o no usar esta característica siempre que las consideraciones de seguridad también estén ahí.

Consider one more example , el Page Output caching : es de 2 tipos, el almacenamiento en caché de salida de página y el almacenamiento en caché de fragmento de página.

El almacenamiento en caché de resultados de página almacena en caché una página web completa y solo es adecuado cuando el contenido de esa página es bastante estático. Si partes de la página están cambiando, puede envolver las secciones estáticas como controles de usuario y almacenar en caché los controles de usuario utilizando el almacenamiento en memoria caché de fragmentos de página.

And one last comment on Application vs HttpRuntime.cache :

Application no es un caché, es una colección de valores con nombre global. si agrega un objeto a la Application , permanecerá hasta que se reinicie un dominio de la aplicación.

• Las variables de aplicación son variables compartidas entre todos los usuarios de una aplicación web
• Las variables de aplicación se comportan como variables estáticas y son sustitutos de variables estáticas ya que las variables estáticas son sin estado en aplicaciones web
• Solo los valores compartidos deben persistir en las variables de la Aplicación, y tan pronto como no estén en uso, deben eliminarse explícitamente.

Cache : es posible obtener mejoras de rendimiento significativas en aplicaciones ASP.NET almacenando en caché objetos y datos solicitados con frecuencia en las clases de Application o de Cache . Si bien la clase Cache ciertamente ofrece mucha más flexibilidad y control, solo parece ofrecer una ventaja marginal en términos de mayor rendimiento en la clase de Application para el almacenamiento en caché. Sería muy difícil desarrollar un esquema de prueba que pudiera medir con precisión las ventajas potenciales de la administración incorporada de la clase Cache objetos menos utilizados a través del proceso de eliminación, en oposición al hecho de que la Aplicación no ofrece esta característica. El desarrollador debe tomar una decisión en este caso y debe basarse en las necesidades y la conveniencia del proyecto y sus patrones de uso. Consulte este enlace para más información.

Consulte este artículo de MSDN para obtener una explicación completa sobre todas las tecnologías de almacenamiento en caché en Asp.net con una explicación sobre las características de cada tecnología.

Además, estos 2 enlaces son una gran fuente para comenzar:

• http://weblogs.asp.net/pjohnson/httpruntime-cache-vs-httpcontext-current-cache
• http://devshop.wordpress.com/2008/04/10/how-to-choose-from-viewstate-sessionstate-cookies-and-cache/

Answer 3

Con respecto a MemoryCache frente a ASP.NET Cache: proporcionan una funcionalidad muy similar. En una aplicación ASP.NET 4, generalmente preferiría el caché ASP.NET, aunque no sea por otro motivo, debido a un error en .NET 4 , que aparentemente está solucionado en .NET 4.5.

Los campos estáticos son apropiados para almacenar datos compartidos que no necesitan una política de caducidad.

El estado de la aplicación no es mucho más que un diccionario estático con semántica de bloqueo que es compatible con ASP clásico: solo lo usaría para compatibilidad con versiones anteriores con el código ASP heredado clásico.