Avantages de Cache vs Session

Quelle est la différence entre stocker un datatable dans Session vs Cache? Quels sont les avantages et les inconvénients?

Donc, s’il s’agit d’une page de recherche simple qui renvoie un résultat dans une firebase database et le lie à une vue de grid. Si l’utilisateur «a» effectue des recherches et effectue des recherches «b», vaut-il mieux le stocker dans Session car chaque utilisateur aura probablement des résultats différents ou puis-je toujours stocker chacune de ses recherches dans Cache ou cela n’a pas de sens un seul cache. Je suppose que ce que j’essaie de dire, c’est que le cache serait écrasé.

Une différence importante est que les éléments du cache peuvent expirer (seront supprimés du cache) après un laps de temps spécifié. Les éléments placés dans une session y restront jusqu’à la fin de la session.

ASP.NET peut également supprimer des éléments du cache lorsque la quantité de mémoire disponible diminue.

Autre différence: l’état de la session peut être maintenu externe (serveur d’état, serveur SQL) et partagé entre plusieurs instances de votre application Web (pour l’équilibrage de charge). Ce n’est pas le cas avec le cache.

Outre ces différences (comme d’autres l’ont noté): la session est par utilisateur / session alors que le cache est par application.

AFAIK, La différence principale est que la session est par utilisateur, tandis que le cache sera pour les articles de scope d’application.

Comme indiqué dans les autres réponses, vous pouvez stocker des informations par utilisateur dans le cache, à condition de fournir une clé (par session ou par cookie). Ensuite, vous aurez plus de contrôle pour expirer les éléments dans le cache et définir des dépendances sur ceux-ci. Donc, si le DataTable en question change régulièrement, la mise en cache est probablement une option appropriée. Sinon, s’il s’agit d’une session statique, cela pourrait être plus approprié. Steven Smith a une excellente vidéo sur la mise en cache chez dnrtv qui vaut le détour.

Cela dépend vraiment de ce que vous essayez de réaliser, combien de temps vous avez. Il existe d’autres alternatives à prendre en compte en ce qui concerne la manière dont vous stockez l’état dans une application. Selon la taille de la table, vous pouvez envisager de stocker l’état dans un cookie (crypté s’il s’agit d’informations sensibles). Si vous utilisez des données de scope d’application, vous pouvez également utiliser un champ statique sur une page ou une classe. Il y a aussi l’object Application.

Mise à jour : Je pense que la question clé que vous devez vous poser est de savoir qui devrait voir ces données.

 Are they going to access the data frequently?

(Non, ne vous embêtez pas).

 Is it going to change?

(Non, utilisez un champ statique ou une application).

 Is it acceptable for user a and user b to see the same results?

(Non, utilisez le cache avec une clé comprenant le nom d’utilisateur et le terme de recherche.)
(Oui, utilisez le cache en utilisant une clé du terme de recherche).

Honnêtement, cependant, si vous n’êtes pas très avancé dans votre développement, je considérerais le stationnement du problème de mise en cache / d’état à une date ultérieure – vous n’en aurez peut-être même pas besoin.

Les trois premières règles de réglage des performances sont les suivantes: 1. Mesurer, 2. Mesurer plus. 3. Mesurer à nouveau …

Une autre différence importante, l’ état de la session sera bloqué si des requêtes Ajax asynchrones simultanées sont exécutées, cela affectera les performances

Le cache est dans la scope de l’application afin de réduire le nombre de fois où une donnée est obtenue. Session est dans l’étendue de la session d’un utilisateur dans le but de donner un état d’utilisateur particulier.

Eh bien, cela dépend de la façon dont vous avez configuré la session pour ASP.NET. Stockez-vous la session dans une firebase database ou en mémoire? Si en mémoire utilisez-vous un serveur séparé ou utilisez-vous le serveur Web actuel pour la session?

Selon la manière dont les choses sont configurées pour vous, il peut y avoir des conséquences sur les performances lorsque vous utilisez quelque chose comme un fichier datatable, qui indique que vous stockez peut-être de grandes quantités de données.

De plus, Session est stockée par utilisateur et est extraite par utilisateur au moyen de son ticket de session stocké dans un cookie de session ou sur l’URL si elle n’accepte pas les cookies et si vous avez configuré ASP.NET en mode sans cookie. Tout ce que vous mettez en cache sera mis en cache au niveau de l’application et sera disponible pour toutes les sessions utilisateur qui peuvent ou non être ce que vous voulez.

La session est par utilisateur, le cache est pour l’application.

Les éléments du cache peuvent et seront supprimés automatiquement en fonction des délais d’expiration (glissants ou fixes) et des contraintes de mémoire du processus de travail IIS.

Donc, fondamentalement, les éléments du cache n’existent jamais, mais la session y restra jusqu’à la fin de la session.

Le stockage d’éléments par utilisateur (via une session ou une utilisation créative du cache) peut entraîner une utilisation importante de la mémoire et doit être considéré avec soin.

En plus de tout cela, si IIS réinitialise le processus de travail, vous pouvez perdre votre cache et votre session.

Voir cette réponse .

Session peut tuer les performances de votre application, sauf si vous utilisez un fournisseur de backend tel que memcached ou velocity. En général, vous devriez l’éviter.

Session que j’utilise spécifiquement là où Cache n’est pas. Cet article est utile .