Puis-je utiliser des variables statiques pour mettre en cache des informations dans ASP.net?

Question

Je travaille actuellement sur une application d'administration de projet en C # 3.5 sur ASP.net. Afin de réduire les occurrences dans la base de données, je mets en cache beaucoup d'informations à l'aide de variables statiques. Par exemple, une liste d'utilisateurs est conservée en mémoire dans une classe statique. La classe lit toutes les informations de la base de données au démarrage et la mettra à jour chaque fois que des modifications seront apportées, mais elle n'aura jamais besoin de lire depuis la base de données.

La classe interroge les autres serveurs Web (s'ils existent) avec des informations mises à jour en même temps qu'une écriture dans la base de données. Le mécanisme de ping est un service Windows auquel l'objet de cache s'enregistre en utilisant un port disponible aléatoire. Il est également utilisé à d'autres fins.

La quantité de données n'est pas si géniale. Pour le moment, je l'utilise uniquement pour mettre en cache les utilisateurs (hachages de mots de passe, autorisations, nom, e-mail, etc.). Il enregistre simplement une pile d'appels vers la base de données.

Je me demandais s'il y avait des pièges à cette méthode et / ou s'il y avait de meilleures façons de mettre en cache les données?

Answer 1

Un piège: un champ statique est défini par domaine d'application, et une charge accrue obligera le serveur à générer davantage de domaines d'application dans le pool. Ce n'est pas nécessairement un problème si vous ne lisez que les statistiques, mais vous obtiendrez des données en double en mémoire et vous obtiendrez un succès chaque fois qu'un domaine d'application est créé ou recyclé.

Il est préférable d’utiliser l’objet Cache: il est destiné à des applications comme celle-ci.

Modifier: il s'avère que je me suis trompé à propos d'AppDomains (comme indiqué dans les commentaires): plusieurs instances de Application seront générées sous charge, mais elles seront toutes exécutées dans le même AppDomain. (Mais vous devriez toujours utiliser l'objet Cache!)

Answer 2

Tant que vous pouvez vous attendre à ce que le cache n'atteigne jamais une taille supérieure à la quantité de mémoire disponible, c'est correct. Assurez-vous également qu’il n’y aura qu’une seule instance de cette application par base de données, sinon les caches des différentes instances de l’application pourraient ne pas être synchronisés.

Là où je travaille, nous avons un O / RM maison et nous faisons quelque chose de similaire à ce que vous faites avec certains tableaux qui ne devraient pas grandir ou changer beaucoup. Donc, ce que vous faites n’est pas sans précédent et, en fait, dans notre système, il est éprouvé.

Answer 3

Un autre piège dont vous devez tenir compte est la sécurité des threads. Toutes vos demandes d'application s'exécutent dans le même domaine d'application, mais peuvent provenir de différents threads. L'accès à une variable statique doit rendre compte de son accès à partir de plusieurs threads. Probablement un peu plus de frais généraux que ce que vous recherchez. L'objet de cache est préférable à cette fin.

Answer 4

Hmmm ... Le "classique" La méthode serait le cache d’application, mais à condition de ne jamais mettre à jour les variables statiques, ni comprendre les problèmes de verrouillage, et que vous comprenez qu’elles peuvent disparaître à tout moment avec un redémarrage d’appdomain, je ne vois pas vraiment le mal à utiliser un statique.

Answer 5

Je vous suggère de rechercher un moyen de créer un cache distribué pour votre application. Vous pouvez consulter NCache ou indeXus.Net

La raison que j’ai suggérée est que vous avez créé votre propre méthode ad hoc de mise à jour des informations que vous mettez en cache. Les variables / références statiques conviennent, mais elles ne sont pas mises à jour / actualisées (vous devrez donc gérer vous-même le vieillissement) et vous semblez avoir une configuration distribuée.