J'ai lu quelque part dans la documentation de Microsoft que le contenu du fichier web.config d'ASP.NET est mis en cache. Si cela est vrai, où est-il mis en cache - dans mémoire ou sur le disque?ASP.NET: Où/comment le fichier web.config est-il mis en cache?
Et une question de suivi: y a-t-il des considérations de performance que je dois faire, si je dois accéder au web.config intensivement?
Son caché dans la mémoire, la mise en cache sur le disque n'a pas de sens, c'est déjà sur le disque. Tout d'abord, dans ASP.NET, vous voulez vous assurer d'accéder aux sections de configuration via la méthode GetSection de l'objet HttpContext (cela utilise les copies mises en cache gérées par ASP.NET).
Les performances d'accès aux valeurs de configuration sont fonction de l'implémentation interne de l'objet Section (l'objet renvoyé par GetSection). Un ConfigurationSection peut simplement agir comme encapsuleur pour un noeud DOM qu'il peut lire à chaque requête d'une propriété. OTH il pourrait intérieurement mettre en cache la valeur et surveiller les changements. Mon conseil serait garder votre code simple et il suffit d'accéder aux valeurs dont vous avez besoin via GetSection plutôt que d'essayer d'en conserver des copies ailleurs mais en tout cas maintenir une référence à l'objet retourné par GetSection pour la durée d'une requête si vous allez y chercher plusieurs valeurs.
Je pense que le web.config est mis en cache dans la mémoire (dans les instances d'objets de System.Web.Configuration). Ceux-ci sont rechargés lorsque le fichier .config est modifié (et donc recharger votre application web).
Frapper ces objets est peu susceptible de vous donner un goulot d'étranglement de performance. Mais si vous devez faire l'analyse, vous pouvez vouloir garder les objets analysés.
[Extra] I bonne pratique (je pense au moins) est de créer des propriétés statiques dans votre fichier global.asax.cs pour vos appsettings. Vous pouvez instancier ces propriétés dans la méthode application_start et les utiliser dans votre application Web. Cela vous empêche d'utiliser une chaîne codée en dur (clés de configuration) dans votre code.
Il est mis en cache en mémoire. La mise en cache sur disque n'a pas beaucoup de sens pour quelque chose auquel on accède souvent et qui est déjà dans un format où vous pouvez le transformer en une structure de données facilement stockée. Mon conseil serait d'y accéder librement car il sera aussi rapide que n'importe quel système que vous avez imaginé pour le stocker et probablement plus rapidement.
Mon conseil serait de l'utiliser comme n'importe quelle autre variable pour la simple raison que les données sont mises en cache. Si vous créez des variables statiques dans global.asax, vous vous obligez à écrire plus de code. Peu importe comment vous êtes prévu, il est fort probable que vous ajoutiez des variables fréquemment dans appconfig au cours du développement.
Il existe 2 types de mise en cache dans ASP .NET.
Caching Application - cache objet interne basé sur memorylimitation, les limites de temps et d'autres dépendances
Page Caching sortie - cache de page rendu au serveur. Les deux sont basés sur la mémoire; pas de disque.
Je ne pense pas que vous ayez compris la question originale de l'OP ... –
Dans ASP.NET, les <appsettings> section est mis en mémoire cache à la mémoire après le 1er accès:
ASP.NET redémarre l'application s'il existe des mises à jour du fichier web.config.
Sur le disque pourrait être d'une manière sérialisée ... d'accord, d'accord, c'est idiot, je sais. Je n'ai pas pensé comme je l'ai écrit ... :-) – splattne
Attends ... je suis fou? Je regarde HttpContext.GetSection dans le réflecteur RedGate, et il semble qu'il appelle ConfigurationManager.GetSection en interne, ce qui ne semble pas mettre en cache quoi que ce soit. S'il vous plaît laissez-moi savoir si j'ai raté quelque chose. –
@Dan: Vous ne spécifiez pas la version que vous regardez, le 2.0.0.0 se rabat sur 'ConfigurationManager' mais utilisera dans ce contexte' CachedPathData' pour obtenir la section. La raison en est qu'il peut y avoir de nombreux fichiers 'web.config' impliqués (un dans chaque dossier du chemin courant), l'état actuel de la config à présenter pour un chemin est composé de tous les fichiers. – AnthonyWJones