Meilleure solution pour la mise en cache

Question

Quel est le meilleur endroit pour implémenter la mise en cache dans une application Web?

• Au niveau de la présentation (j'espère que non)?
• Au niveau de la couche de logique applicative?
• Au niveau de la couche de données?

Je vais utiliser quelque chose comme Memcached ou MS Velocity sous le capot.

Je suis en train de rédiger beaucoup de code pour mettre à jour le cache ici et là dans la couche de logique applicative. Par conséquent, serait-il préférable de créer une structure entre la couche d'accès aux données du serveur de base de données pour mettre en cache les données? / p>

Je pense que ces complications sont dues au fait que la plupart des données que nous mettons en cache sont spécifiques à un utilisateur et que nous dupliquons des données dans le cache. Nous avons du mal à trouver la meilleure solution.

Answer 1

Le cache est un élément important ou une application Web, mais il n’existe pas de solution magique qui convienne à tous les projets. Travailler sur des optimisations avant que votre application ne fonctionne est généralement une mauvaise idée. Avant de vous demander où vous devez implémenter une couche de cache, la première étape consiste à vérifier que votre application fonctionne correctement (même lentement) sans optimisation de cache.

Lorsque cette première étape est terminée, vous pouvez commencer à profiler l'application, en énumérant les fonctionnalités qui semblent utiliser beaucoup de ressources (processeur, mémoire, entrées / sorties, accès à la base de données) ou prendre beaucoup de temps. à compléter (généralement à cause des mêmes symptômes).

Une fois que vous disposez d'une liste de fonctionnalités que vous pensez pouvoir optimiser avec un système de cache, vous devez vous poser deux questions:

• "Comment puis-je améliorer toutes ces fonctionnalités en même temps " (focus macro): Une réponse évidente à cette question est souvent le cache d’accès aux données. En règle générale, vous ne souhaitez pas envoyer la même requête à votre serveur de base de données si les données que vous recevez en retour sont toujours les mêmes. Donc, stocker ce type de données dans le cache, avec une durée de vie intelligente, sera toujours une bonne idée.

• "Comment puis-je améliorer chaque fonctionnalité" (micro focus): C'est délicat, et vous avez besoin de bien comprendre votre application pour comprendre celle-ci. Certaines données peuvent être mises en cache, d’autres pas. Un débogueur et un profileur sont généralement d'excellents outils pour cette étape, car ils vous aident à savoir pourquoi une fonctionnalité est lente et vous donnent des conseils sur la façon dont ils doivent être optimisés.

Les optimisations que vous allez découvrir peuvent être liées à n’importe quelle couche de votre application (présentation, logique métier, données), mais cela ne signifie pas que vous devez toutes les implémenter. Il y a plusieurs choses importantes à prendre en compte:

• Cette fonctionnalité doit-elle vraiment être optimisée? (Est-ce un gain notable pour le client? Pour le matériel? Pour l’ensemble de l’application? Pour les autres applications?)
• Quel gain de performance puis-je atteindre? (1%, 200%, ...)
• Combien de temps faut-il pour l'optimiser? (1 heure, 12 jours, ...)
• Quel est le risque de l’optimiser? (pourrait-il casser des choses pour l'application? Pour le client?)

Une fois que vous avez les réponses à ces questions, il est temps d'en discuter avec votre chef de projet, vos collègues ou même des personnes qui ne travaillent pas sur l'application avec vous. Avoir un avis neutre est bon, ainsi que des avis non techniques (ou moins techniques). Parler à ces personnes devrait vous aider à déterminer ce qui devrait être fait et ce qui ne devrait pas être.

À ce stade, vous devriez avoir une liste d’optimisations assez claire, à laquelle vous avez réfléchi à plusieurs reprises, et vous ne devriez avoir aucun problème à les coder et à les tester.

Answer 2

La mise en cache est une optimisation des performances, donc faites-le là où se trouve le goulot d'étranglement. Vous savez où se situe le goulet d'étranglement en le mesurant trois fois, puis une fois de plus.

Faites attention à la cohérence décontractée de vos données lorsque vous mettez en cache, par exemple. vous ne voulez pas mettre en cache l'ensemble de votre application de trading.

Answer 3

Vous devriez envisager la mise en cache à CHAQUE couche.

Le meilleur endroit pour mettre en cache est aussi proche que possible de la demande du client (afin que vous fassiez le moins de travail possible pour répondre à la demande). Dans les applications Web, oui au niveau de la couche présentation, au niveau de la couche métier et au niveau de la couche de données.

(Remarque: si vous bricolez votre code de logique métier avec la logique de mise en cache ici et là, vous devriez vraiment vous pencher sur séparation des problèmes pour éviter que votre code ne devienne une grosse boule de boue :-))

Answer 4

Couche de données - toutes les couches situées au-dessus de cette couche n'ont pas besoin de savoir d'où proviennent les données. Je voudrais aussi ne mettre en cache que les données qui ne sont pas très volatiles ou inclure une politique d’expiration.

Answer 5

Nous l’implémentons au niveau de la couche logique entre les interactions avec la couche de présentation. Si une requête de la couche de présentation arrive et qu'elle est mise en cache, nous pouvons alors ignorer toute une série de problèmes de logique et d'accès aux données.

Je recommanderais vivement MemCached à MS Velocity. Velocity a été difficile à installer!

Answer 6

Cache: mis en œuvre au niveau de la couche d'accès aux données, accessible par la couche de logique applicative.

Cela signifie que vous devez surveiller attentivement la cache qui devient périmée.

Answer 7

Couche de données. Mais c'est déroutant parce que nous utilisons la mise en cache ASP.NET. Avec sa capacité d'expiration et de dépendance, il est très pratique. Notre couche métier n'a donc aucune idée de la mise en cache de la couche de données, mais celle-ci utilise une technologie de couche de présentation pour la mise en cache! : (

Answer 8

Si vous mettez en cache des objets métier, et compte tenu des 3 niveaux que vous décrivez, la couche métier est l'endroit idéal.

Une configuration simple serait (pour un seul objet métier):

1. MyCache est une classe statique
2. Une méthode statique: MyCache.Retrieve (id), retourne un objet
3. La classe utilise un dictionnaire statique pour le stockage et un static ReaderWriterLock

La méthode Retrieve effectue alors les opérations suivantes:

1. L'id est-il dans votre cache ( Dictionnaire de l'id / objet)?
2. Non
   • Récupérez l'objet de la base de données
   • AquireWriterLock à partir de ReaderWriterLock (pourquoi ReaderWriter? parce que vous n'écrivez pas souvent mais vous lisez souvent)
   • Ajouter l'objet au cache
3. Oui
   • Récupérer l'objet du dictionnaire

C’est ma solution préférée, vous pouvez ajouter des délais, une compensation, etc. si vous en avez besoin. Vous pouvez également utiliser memcached ou le blocage de la mise en cache de la bibliothèque d'entreprise Microsoft . généralement excessif.

Answer 9

Je ne peux pas parler de choses spécifiques à ASP.NET, mais j'ai généralement constaté que vous pouviez mettre en cache à chaque niveau. Votre couche de données mettra en cache les réponses de données, votre couche de présentation trouvera peut-être le besoin de mettre en cache des éléments de présentation générés (par exemple, des feuilles de style spécifiques à l'utilisateur), etc. un cache d'objets s'il s'avère que cela est nécessaire.

Le plus difficile est de faire en sorte que l’invalidation du cache fonctionne correctement. Les caches obsolètes sont un casse-tête majeur lors du déploiement. Assurez-vous de bien comprendre comment vous allez gérer la durée de vie de chaque objet du cache. Les caches LRU fonctionnent bien pour mettre en cache des éléments statiques basés sur la demande. Cependant, la plupart des caches de données nécessiteront un cycle de vie explicite, qu'il soit basé sur un minuteur d'expiration ou lié à une sorte de session utilisateur.