Pros/Contras verschiedener ASP.NET-Caching-Optionen

Question

Ich habe vor kurzem eine Frage zum Zwischenspeichern von Anwendungsdaten in einer ASP.NET MVC WebAPI-Anwendung gestellt und es führte mich zu einer neuen Frage. Was sind die Vor- und Nachteile verschiedener Caching-Methoden in ASP.NET?

Ich bin gekommen, auf:

• Memory Cache

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

• Verwenden von statischen Membervariablen:

  private static Northwind.SuppliersDataTable suppliers = null; 
  

• Staat Anwendung:

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

• Daten-Cache:

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

Ich bin sicher, es gibt andere, und ich kenne sie alle technisch die Daten im Speicher speichern ... so eine Ahnung, was ich für eine verwenden soll ASP.NET MVC webapi?

meine vorherige Frage: Caching application data in memory: MVC Web API

Answer 1

Jeder Caching-Technologie/Methoden, um ihren eigenen Satz von Funktionen. Diese Merkmale scheinen in einem Anwendungsfall von Nachteil zu sein, können aber bei anderen Anwendungsanforderungen vorteilhaft sein.

Also, kurz gesagt, je nach Ihren Anforderungen entscheiden, welche Caching-Technologie und welche Funktionen für Sie am besten sind.

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

MSDN sagt, dass wir auch HiddenField können nur geringe Mengen an häufig wechselnden Daten in versteckten Feldern zu speichern, weil diese Daten in dem Roundtrip zum Server auf jedem Postback enthalten ist.

Vorteile dieser Funktion: Verringern die Arbeitsbelastung auf dem Server von Seiteninformationen unter Verwendung von clientseitigen Optionen zu speichern.

Allerdings sagt MSDN klar, dass: Dieser Ansatz hat minimale Sicherheitsunterstützung.

So kann man diese Funktion immer verwenden oder nicht, da Sicherheitsüberlegungen auch da sind.

Consider one more example, Page Output caching: Es ist aus 2 Typen, Seitenausgabe-Caching und Seitenfragment-Caching.

Seitenausgabe Zwischenspeicherung zwischenspeichert eine gesamte Webseite und ist nur geeignet, wenn der Inhalt dieser Seite ziemlich statisch ist. Wenn sich Teile der Seite ändern, können Sie die statischen Abschnitte als Benutzersteuerelemente umschließen und die Benutzersteuerelemente mithilfe der Seitenfragment-Zwischenspeicherung zwischenspeichern.

And one last comment onApplication vs HttpRuntime.cache:

Application ist kein Cache, das eine globale Sammlung namens Wert. Wenn Sie ein Objekt zu Application hinzufügen, bleibt es so lange bestehen, bis eine AppDomain wiederverwendet wird.

• Application-Variablen Variablen
• Application-Variablen verhalten sich wie statische Variablen und sie sind Ersatz von statischen Variablen unter allen Benutzern einer Web-Anwendung gemeinsam genutzt werden als statische Variablen in Web-Anwendungen
• nur gemeinsame Werte sollten staatenlos sind sein in Anwendungsvariablen beibehalten, und sobald sie nicht verwendet werden, sollten sie explizit entfernt werden.

Cache: Es ist möglich, signifikante Performance-Verbesserungen in ASP.NET-Anwendungen zu erhalten, indem das Zwischenspeichern häufig angeforderten Objekte und Daten entweder in den Application oder Cache Klassen. Während die Cache Klasse sicherlich viel mehr Flexibilität und Kontrolle bietet, scheint es nur einen marginalen Vorteil in Bezug auf erhöhten Durchsatz über die Application Klasse für Caching bieten. Es wäre sehr schwierig, ein Testschema zu entwickeln, das die möglichen Vorteile der integrierten Klasse Cache von weniger genutzten Objekten durch den Aufräumprozess genau messen könnte, im Gegensatz zu der Tatsache, dass Application diese Funktion nicht bietet. Der Entwickler muss in diesem Fall eine Entscheidung treffen und sollte auf den Bedürfnissen und der Zweckmäßigkeit des Projekts und seiner Nutzungsmuster basieren. Überprüfen Sie this link für mehr.

Siehe this MSDN article für eine komplette große Erklärung aller Caching-Technologien in Asp.net mit discusiion auf die Merkmale der einzelnen Technologien.

Auch sind diese zwei Links eine große Quelle für den Anfang:

• 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

Bei der Verwendung von Web-API Ihre erste Wahl für das Caching sollte immer sein, um den Caching Header in der HTTP-Antwort. HttpResponseMessage.CacheControlHeader.

Ihre letzten Optionen sollten alles sein, was von HttpContext oder HttpRuntime abhängt, da dies Sie an bestimmte Hosts bindet. Web-API-Anwendungen sollten unabhängig von ihrem Host erstellt werden.

Answer 3

In Bezug auf MemoryCache vs ASP.NET Cache: Sie bieten sehr ähnliche Funktionen. In einer ASP.NET 4-Anwendung würde ich den ASP.NET-Cache im Allgemeinen bevorzugen, wenn aus keinem anderen Grund, denn a bug in .NET 4, die offenbar in .NET 4.5 behoben ist.

Statische Felder eignen sich zum Speichern von freigegebenen Daten, für die keine Ablaufrichtlinie erforderlich ist.

Anwendungsstatus ist nicht viel mehr als ein statisches Wörterbuch mit Sperrensemantik, das mit klassischem ASP kompatibel ist - ich würde es nur für Abwärtskompatibilität mit altem klassischem ASP-Code verwenden.