Pro/Contro di diverse opzioni di caching ASP.NET

Question

Recentemente ho fatto una domanda sulla memorizzazione nella cache dei dati dell'applicazione in un'applicazione WebAPI ASP.NET MVC e mi ha portato a una nuova domanda. Quali sono i vantaggi/svantaggi dei diversi metodi di memorizzazione nella cache disponibili in ASP.NET?

ho scenderà su:

• memoria cache

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

• Utilizzo di variabili statico Stati: Stato

  private static Northwind.SuppliersDataTable suppliers = null; 
  

• Applicazione:

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

• cache dati:

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

Sono sicuro che ci sono altri, e so che tutti tecnicamente memorizzano i dati in memoria ... in modo che qualsiasi idea di cosa dovrei usare per un ASP.NET MVC webapi?

La mia domanda precedente: Caching application data in memory: MVC Web API

Answer 1

Ogni Caching tecnologia/metodi hanno il proprio set di caratteristiche. Queste caratteristiche possono sembrare di svantaggio in un unico requisito applicativo ma possono essere vantaggiose in altri requisiti applicativi.

Quindi, in breve, in base alle proprie esigenze decidere quale tecnologia Caching e quali caratteristiche sono le migliori per voi.

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

MSDN dice che possiamo anche usare HiddenField per memorizzare solo piccole quantità di dati che cambiano frequentemente nei campi nascosti, perché questi dati è incluso nei andata e ritorno al server su ogni postback.

vantaggio di questa funzione: Riduce il carico di lavoro sul server per la memorizzazione delle informazioni pagina utilizzando le opzioni sul lato client.

Tuttavia, MSDN afferma chiaramente che: Questo approccio ha un minimo supporto di sicurezza.

Pertanto, si può o non si può usare questa funzione sempre come anche le considerazioni sulla sicurezza.

Consider one more example, Page Output caching: è di 2 tipi, pagina uscita cache e pagina frammento caching.

Il caching dell'output della pagina memorizza nella cache un'intera pagina Web ed è adatto solo quando il contenuto di tale pagina è abbastanza statico. Se le parti della pagina cambiano, puoi avvolgere le sezioni statiche come controlli utente e memorizzare nella cache i controlli utente utilizzando la memorizzazione nella cache dei frammenti di pagina.

And one last comment onApplication vs HttpRuntime.cache:

Application non è una cache, la sua una collezione di valore denominato globale. se aggiungi un oggetto a Application rimarrà fino al riciclo di un appdomain.

• variabili di applicazione sono le variabili condivise tra tutti gli utenti di un'applicazione web
• variabili Application si comportano come variabili statiche e sono sostituto di variabili statiche come variabili statiche sono apolidi nelle applicazioni web
• valori Solo condivisi dovrebbero essere persistono nelle variabili Application e, non appena non sono in uso, dovrebbero essere rimossi esplicitamente.

Cache: E 'possibile avere significativi miglioramenti delle prestazioni nelle applicazioni ASP.NET mettendo in cache oggetti e dati richieste frequentemente in entrambi i Application o Cache classi. Mentre la classe Cache offre sicuramente molta più flessibilità e controllo, sembra solo offrire un vantaggio marginale in termini di aumento del throughput rispetto alla classe Application per la memorizzazione nella cache. Sarebbe molto difficile sviluppare uno schema di test in grado di misurare con precisione i potenziali vantaggi della gestione integrata della classe Cache di oggetti meno utilizzati attraverso il processo di scavenging, contrariamente al fatto che l'applicazione non offre questa funzionalità. Lo sviluppatore deve prendere una decisione in questo caso e dovrebbe basarsi sulle esigenze e sulla convenienza del progetto e dei suoi modelli di utilizzo. Verifica this link per ulteriori informazioni.

consultare this MSDN article per una grande spiegazione completa su tutte le tecnologie di caching in Asp.net con discusiion sulle caratteristiche di ciascuna tecnologia.

Inoltre, questi 2 collegamenti sono una grande fonte per cominciare:

• 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 2

Quando si utilizza API Web vostra prima scelta per la memorizzazione nella cache dovrebbe sempre essere quello di impostare il caching intestazioni nella risposta HTTP. HttpResponseMessage.CacheControlHeader.

Le tue ultime opzioni dovrebbero essere qualsiasi cosa che dipenda dallo HttpContext o dallo HttpRuntime, dato che ti legherà a determinati host. Le applicazioni API Web dovrebbero essere costruite indipendentemente dal loro host.

Answer 3

Per quanto riguarda MemoryCache vs ASP.NET cache: essi forniscono funzionalità molto simili. In un'applicazione ASP.NET 4, in genere preferisco la cache ASP.NET, se non altro per il motivo, a causa di a bug in .NET 4, che è apparentemente risolto in .NET 4.5.

I campi statici sono appropriati per memorizzare dati condivisi che non richiedono un criterio di scadenza.

Lo stato dell'applicazione non è molto più di un dizionario statico con semantica di blocco compatibile con ASP classico. Lo utilizzerei solo per la compatibilità con le versioni precedenti con il classico codice ASP legacy.