web-dev-qa-db-fra.com

Avantages / inconvénients des différentes options de mise en cache ASP.NET

J'ai récemment posé une question sur la mise en cache des données d'application dans une application ASP.NET MVC WebAPI et cela m'a conduit à une nouvelle question. Quels sont les avantages/inconvénients des différentes méthodes de mise en cache disponibles dans ASP.NET?

Je suis tombé sur:

  • Cache mémoire

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

  • Utilisation de variables membres statiques:

    private static Northwind.SuppliersDataTable suppliers = null;

  • État d'application:

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

  • Cache de données:

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

Je suis sûr qu'il y en a d'autres, et je sais qu'ils stockent tous techniquement les données en mémoire ... donc une idée de ce que je dois utiliser pour une webapi ASP.NET MVC?

Ma question précédente: Mise en cache des données d'application en mémoire: MVC Web API

c#asp.netasp.net-mvccachingasp.net-web-api
55
vesuvious

Chaque technologie/méthode de mise en cache a son propre ensemble de fonctionnalités. Ces fonctionnalités peuvent sembler désavantageuses dans une seule application, mais peuvent être avantageuses dans d'autres applications.

En bref, en fonction de vos besoins, décidez de la technologie de mise en cache et des fonctionnalités qui vous conviennent le mieux.

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

MSDN indique que nous pouvons également utiliser HiddenField pour stocker uniquement de petites quantités de données changeant fréquemment dans des champs masqués car ces données sont incluses dans les allers-retours vers le serveur à chaque publication.

Avantage de cette fonctionnalité: Réduit la charge de travail sur votre serveur en stockant les informations de page à l'aide des options côté client.

Cependant, MSDN dit clairement que: Cette approche a une prise en charge de sécurité minimale.

Ainsi, on peut ou non utiliser cette fonctionnalité toujours car des considérations de sécurité sont également là.

Consider one more example, Page Output caching: il est de 2 types, la mise en cache de sortie de page et la mise en cache de fragment de page.

La mise en cache de sortie de page met en cache une page Web entière et ne convient que lorsque le contenu de cette page est assez statique. Si des parties de la page changent, vous pouvez encapsuler les sections statiques en tant que contrôles utilisateur et mettre en cache les contrôles utilisateur à l'aide de la mise en cache des fragments de page.

And one last comment onApplication vs HttpRuntime.cache:

Application n'est pas un cache, c'est une collection globale de valeurs nommées. si vous ajoutez un objet à Application, il restera jusqu'à ce qu'un domaine d'application soit recyclé.

  • Les variables d'application sont des variables partagées entre tous les utilisateurs d'une application Web
  • Les variables d'application se comportent comme des variables statiques et remplacent les variables statiques car les variables statiques sont sans état dans les applications Web
  • Seules les valeurs partagées doivent être conservées dans les variables d'application et dès qu'elles ne sont pas utilisées, elles doivent être supprimées explicitement.

Cache: Il est possible d'obtenir des améliorations significatives des performances dans les applications ASP.NET en mettant en cache les objets et les données fréquemment demandés dans les classes Application ou Cache. Bien que la classe Cache offre certainement beaucoup plus de flexibilité et de contrôle, elle ne semble offrir qu'un avantage marginal en termes d'augmentation du débit sur la classe Application pour la mise en cache. Il serait très difficile de développer un schéma de test qui pourrait mesurer avec précision les avantages potentiels de la gestion intégrée des objets moins utilisés de la classe Cache via le processus de nettoyage, par opposition au fait qu'Application n'offre pas cela. fonctionnalité. Le développeur doit prendre une décision dans ce cas et doit être basé sur les besoins et la commodité du projet et ses modèles d'utilisation. Cochez ce lien pour en savoir plus.

Reportez-vous cet article MSDN pour une excellente explication complète sur toutes les technologies de mise en cache dans Asp. net avec discussion sur les caractéristiques de chaque technologie.

De plus, ces 2 liens sont une excellente source pour commencer:

34
R.C

Concernant MemoryCache vs ASP.NET Cache: ils fournissent des fonctionnalités très similaires. Dans une application ASP.NET 4, je préfère généralement le cache ASP.NET, si pour aucune autre raison, alors à cause de n bogue dans .NET 4 , qui est apparemment corrigé dans .NET 4.5 .

Les champs statiques sont appropriés pour stocker des données partagées qui n'ont pas besoin d'une politique d'expiration.

L'état de l'application n'est pas beaucoup plus qu'un dictionnaire statique avec une sémantique de verrouillage compatible avec le code classique ASP - je ne l'utiliserais que pour la compatibilité descendante avec le code classique classique ASP.

10
Joe

Lorsque vous utilisez l'API Web, votre premier choix pour la mise en cache doit toujours être de définir les en-têtes de mise en cache dans la réponse HTTP. HttpResponseMessage.CacheControlHeader.

Vos dernières options devraient être tout ce qui dépend de HttpContext ou HttpRuntime, car cela vous liera à des hôtes particuliers. Les applications d'API Web doivent être construites indépendamment de leur hôte.

4
Darrel Miller