2011-03-11 5 views
3

Nous avons environ 50 sites Web exécutés dans différents pools d'applications, qui lisent à partir d'une base de données de cache commune (à l'aide du bloc d'application Microsoft Enterprise Library Caching).Partage du cache entre plusieurs sites Web

Nous avons actuellement une application console qui remplit le cache à 3h du matin tous les matins. Cependant, nous voulons nous débarrasser de cette application et obtenir le cache pour actualiser automatiquement les éléments expirés, en utilisant l'interface ICacheItemRefreshAction.

Nous allions créer notre objet cache dans le Global.asax de chacun des 50 sites web. Cependant, ma préoccupation est que si nous définissons une politique d'expiration de cache dans Global.asax, chacun des 50 sites Web déclenchera une action d'actualisation, entraînant la mise en cache des données 50 fois.

Nous ne souhaitons pas qu'un seul site Web définisse les règles d'expiration, car les 49 autres sites Web auront une dépendance vis-à-vis de ce site Web, ce qui constitue une non-architecture.

Compte tenu de ces contraintes - des recommandations?

Répondre

1

Peut-être que vous pouvez regarder une solution de mise en cache alternative comme memcached, NCache ou Velocity.

Avec cela vous pouvez avoir un cache partagé par tous les sites.

+0

Nous avons un cache partagé par tous nos sites - c'est la mise en cache de la bibliothèque d'entreprise. Ce que nous voulons, c'est un moyen d'avoir une instance singleton de notre objet cache. Sauf si vous suggérez d'avoir un cache pour notre cache - ce qui, je pense, marcherait, mais je préférerais une solution plus élégante si possible! –

+0

Cette bibliothèque dispose-t-elle d'une API pour parcourir les objets existants dans le cache? Si tel est le cas, vous pouvez probablement faire en sorte que tous les sites déclenchent un code qui actualise l'élément UNIQUEMENT s'il n'a pas été actualisé au cours des X dernières minutes. –

+0

Je pense que nous pourrions faire quelque chose comme ça, mais EL Caching a déjà des politiques d'expiration très sophistiquées (à temps de glissement, absolues, à base de fichiers, etc.), donc nous devrions plutôt réinventer la roue ici. Notre objectif est de simplifier le problème, plutôt que de le rendre plus complexe! Merci pour la suggestion cependant. –

2

Stick avec ce que vous avez.

Si les applications de la console remplissant la mémoire cache à 3 heures fonctionnent correctement, continuez à l'utiliser. Vous pouvez toujours modifier la granularité à laquelle elle est appelée si vous devez actualiser le cache plus fréquemment. Si vous souhaitez activer ICacheItemRefreshAction pour activer une granularité plus fine (certains objets tombent du cache après 24 minutes, certains après 24 heures), pensez à rendre l'application console plus flexible afin de pouvoir lui indiquer les parties de cache le cache pour invalider et re-remplir.

L'un bit d'information manquante de votre question qui serait utile pour affiner la réponse est pourquoi voulez-vous pour se débarrasser de l'application de la console et, peut-être plus important encore, pourquoi voulez-vous passer à en utilisant l'interface ICacheItemRefreshAction?

+0

Strictement parlant, nous n'avons pas encore implémenté l'application console - j'ai dit que nous devions simplifier la question. La raison pour laquelle nous voulons nous en débarrasser est que nous n'avons pas de serveur pour l'exécuter. J'apprécie que cela semble être une raison ridicule, mais je travaille pour A Large Company, et il y a des politiques et procédures et des budgets qui rendent notre vie problématique et, étant donné que nous allons faire un travail quelque part, je pensais que un cache expirant correctement était une solution plus élégante, et qui supprime un composant qui s'intègre mal dans notre stratégie de déploiement. –

Questions connexes