Ir al contenido principal

Manejo de Caché en ASP NET MVC

Hola a todos, el objetivo de este post es aclarar ciertos puntos sobre el manejo de caché en ASP NET MVC.

El manejo de la caché correctamente nos permite mejorar el rendimiento de nuestras aplicaciones, permitiéndonos almacenar información de uso frecuente y dentro de la memoria de alta velocidad.
El manejo de la caché se puede dar tanto en el servidor como en el cliente.

Este es un resumen de manejo de caché en ASP NET MVC:

  1. Page Output Caching: Es el manejo de caché a nivel de página o de acción en MVC. El navegador web puede almacenar en caché cualquier solicitud HTTP GET durante un periodo predefinido por lo que si el usuario solicita la misma URL, el navegador no llama al servidor, si no que carga la página desde la caché del navegador local. Te da la opción de decidir donde se va almacenar la página ya sea en el cliente o en el servidor. Solo se necesita decorar la acción con el atributo "OutputCache" e indicarle como se va a manejar:
    • Duration (tiempo de duración en segundos)
    • Location
      • Any
      • Client
      • Downstream (solo para dispositivos que acepten HTTP 1.1)
      • Server
      • ServerAndClient
    • VaryByParam (considera paramétros de entrada)
          *Estas son las opciones que mas se usan con el atributo "OutputCache", pero existen mucho mas y las pueden encontrar en OutputCacheAttribute Class.

  1. Donut Caching: Nos permite mantener en caché toda la página excepto ciertas partes que son dinámicas, es una tecnología por el lado del servidor y está soportada en ASP.NET Web Forms, pero NO en ASP.NET MVC, sin embargo, mediante el método HttpResponse.WriteSubstitution es posible crear un helper que lo aplique. 

  2. Donut Hole Caching: Es un enfoque inverso a Donut Caching ya que permite guardar en caché parte de la página (Partial View). A diferencia de Donut Caching, Donut Hole Caching SI esta soportada por ASP NET MVC. Hay que tener en cuenta que para aplicarla, debemos colocar los atributos ChildActionOnly y OutputCache sobre la acción de la vista parcial a la cual queremos aplicarle caché.
  3. Data Caching: Es otra forma de almacenamiento en caché que puede ocurrir en el lado del servidor. La implementación predeterminada utiliza los objetos ObjectCache y MemoryCache que están dentro del ensamblado System.Runtime.Caching. Este tipo de almacenamiento de caché disminuye la carga a la base de datos permitiendo el mejor uso de llamada a datos que no cambian a menudo. También se puede implementar con ORM como Entity Framework. 
  4. Application Caching: Este tipo de almacenamiento de caché viene de la mano con HTML 5, diseñado para que la aplicación web pueda ejecutarse sin conexión. Funciona creando un archivo .manifest donde se colocará cuales elementos de la web se almacenarán en caché. Las secciones clave son CACHE, NETWORK y FALLBACK. El CACHE representa los recursos que se deben almacenar en caché en el cliente, NETWORK define aquellos elementos que nunca se almacenan en caché y FALLBACK define los recursos que se deben devolver si no se encuentran los recursos correspondientes.
¿Cómo manejamos la distribución de la caché?
Que pasa si estamos en una granja de servidores y se necesita compartir la caché entre servidores, necesitaríamos implementar una solución para manejar este tipo de escenario. Tenemos 2 alternativas, montamos nosotros mismo nuestros servidores de caché o consumimos algunos servicios que brinden esta infraestructura como: 
  • Windows Server AppFabric / 
  • Windows Azure AppFabric / Azure Cache
  • Ncache
  • TayzGrid
  • Redis
  • .net Memory Cache
  • VM Ware GemFire
  • IBM Xtreme Scale


En este tema hay para profundizar mucho mas, pero esta vez no quiero concentrarme solo en la teoría si no llevarlo también a la practica, creo que los conceptos mencionados anteriormente son suficientes para llevar a cabo el entendimiento del manejo de caché.

Para esta ocasión mostraré un pequeño ejemplo de Page Output Caching en ASP NET MVC, el código lo puedes encontrar aquí.

1. Tengo una acción que renderiza una página con una lista de usuarios:
 Podemos ver que tiene un atributo llamado OutputCache configurado para que la caché dure 60 segundos y esté localizado en el cliente (browser). Hay mas parámetros para configurar y son de igual de intuitivos como los que vemos, pueden revisarlos mas a fondo aquí OutputCacheAttribute.

2. Tenemos también la opción de guardar las configuraciones del manejo de caché de manera mas centralizada en el web.config, asi que para el ejemplo trasladaremos la configuración del atributo OutputCache al web.config.

3. Ahora lo que nos faltaría es llamar la configuración desde la acción.
*Podemos ver que ahora solo hacemos referencia al nombre del cache profile que hemos definido en el web.config.

4. Pasemos a probarlo, levantemos la aplicación y ubiquémonos en la siguiente url http://xxxx/usuario/index, ingresemos a la opción del navegador "Herramientas de desarrolladores" con F12 y nos ubicamos en la pestaña "Network".



*Podemos ver que la página a demorado en cargar 25 mili segundos y que el tamaño de descarga fue 5.2 KB.

5. Ahora ingresemos le damos clic al botón "Nuevo Usuario" y luego retornamos dando clic a la opción "Regresar a la Búsqueda de Usuarios".


*Podemos ver que la página a demorado en cargar 5 mili segundos y que no ha descargado nada del servidor. Otra forma de probar es poniendo un punto de interrupción en la acción y validando si entra a la acción.


Espero les sea de ayuda estas notas sobre manejo de caché, les dejo algunos links para que profundicen en el tema, gracias.

  • Código del ejemplo: Aquí
  • https://code2read.com/2016/01/16/caching-tipos-de-cache/
  • https://www.tutorialspoint.com/asp.net_mvc/asp.net_mvc_caching.htm
  • https://www.codeproject.com/Articles/1046483/Caching-In-MVC
  • http://dejanstojanovic.net/aspnet/2015/april/microsoft-iis-and-aspnet-mvc-caching-techniques/
  • https://msdn.microsoft.com/es-es/communitydocs/web-dev/mvc/implementando-cache-con-azure-cache
  • https://diegobersano.com.ar/2014/08/08/usar-cache-para-mejorar-rendimiento-en-asp-net-mvc/
  • https://docs.microsoft.com/en-us/aspnet/web-forms/overview/data-access/caching-data/caching-data-at-application-startup-cs
  • Developing ASP .NET MVC 4 Web Application Exam Ref 70-486, William Penberthy
  • Programming ASP .NET MVC 4, Jess Chadwick , Todd Snyder y Krusikesh Panda

Comentarios

Entradas populares de este blog

Configuración de Modo de estado de Sesión StateServer para aplicaciones ASP NET de alta disponibilidad

Hola a todos, el objetivo de este post es mostrar cómo se configura una aplicación para que soporte balanceo de carga y este alojado en una granja de servidores.  Con esto se quiere lograr que la aplicación sea de alta disponibilidad. Se necesita que la sesión persista a pesar de que se redireccione al usuario hacia otro servidor (recordar que estamos con un balanceador en una granja de servidores) o se reinicie la aplicación. Para esto en ASP .NET, ya sea web form o mvc la forma de poder manejar este caso es configurando el modo de estado de sesión fuera del proceso. ASP .NET tiene los siguientes modos de estado de sesión: ·          Modo InProc , que almacena el estado de sesión en memoria en el servidor Web. Éste es el valor predeterminado. ·          Modo StateServer , que almacena el estado de sesión en un proceso distinto denominado "servicio de estado de ASP.NET". Este modo garantiza que el estado de sesión se mantiene si se reinicia la aplicación Web y qu

Inicio de sesión basado en tokens con Web Api

Hola a todos, el objetivo de este post será realizar el mecanismo de inicio de sesión basado en tokens para un servicio Rest Full con Web Api y Owin. Antes de empezar veamos un poco de teoría: Web Api:     Es un marco que facilita la creación de servicios HTTP disponibles para una amplia variedad de clientes, entre los que se incluyen exploradores y dispositivos móviles. ASP.NET Web API es la plataforma perfecta para crear aplicaciones RESTful en .NET Framework. Autenticación basada en Token: La forma preferida hoy en día para autenticarse desde el front-end ya sea web o mobile es la de tokens por las siguientes razones: Escalabilidad de servidores: El token que se envía al servidor es independiente, contiene toda la información necesaria para la autenticación del usuario, por lo que añadir más servidores a la granja es una tarea fácil ya que no depende de una sesión compartida. Bajo acoplamiento: Su aplicación front-end no se acopla con el mecanismo de autenticación