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?
ainsi, si c'est une simple page de recherche qui renvoie le résultat dans un datatable et le lie à un gridview. Si l'Utilisateur 'a' Recherche et l'utilisateur 'B' Recherche, est-il préférable de le stocker en Session car chaque utilisateur aurait très probablement des résultats différents ou Puis-je encore stocker chacune de leurs recherches dans le Cache ou est-ce que cela n'a pas de sens puisqu'il n'y a qu'un seul cache. En gros, ce que j'essaie de dire, c'est que la Cache serait écrasée.
8 réponses
une différence importante est que les éléments dans le cache peuvent expirer (seront retirés du cache) après un certain temps. Les articles mis en session y resteront jusqu'à la fin de la session.
ASP.NET peut également supprimer des éléments de cache lorsque la quantité de mémoire disponible devient petite.
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 load équilibrage.) 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 tandis que le cache est par application.
AFAIK, la différence clé est que la session est par utilisateur, tandis que le cache sera pour les éléments d'application scoped.
comme indiqué dans les autres réponses, vous pouvez stocker des informations par utilisateur dans le cache, à condition que vous fournissiez une clé (soit par session, soit par cookie). Ensuite, vous aurez plus de contrôle pour expirer les éléments dans le cache et aussi définir les dépendances sur eux. Donc, si le DataTable en question va changer sur une base régulière, alors la mise en cache est probablement une option appropriée. Sinon, si c'est la séance statique pourrait être plus approprié. Steven Smith a une excellente vidéo sur la mise en cache à dnrtv qui vaut le détour.
Cela dépend vraiment de ce que vous essayez d'atteindre, comment beaucoup de temps vous avez. Il y a d'autres alternatives à considérer en ce qui concerne la façon dont vous stockez l'état dans une application. Selon la taille de la table, vous pourriez envisager de stocker l'état dans un cookie (chiffré s'il s'agit d'informations sensibles). Alternativement, si c'est l'application scoped des données que vous utilisez à froid un champ statique sur une page ou une classe. Il est l'objet Application.
Update : 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, pas la peine).
Is it going to change?
(Non, utiliser un champ ou une Application statique).
Is it acceptable for user a and user b to see the same results?
(Non, utilisez le cache avec un 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 loin dans votre développement, je considérerais Le stationnement de la question de cache/État à une date ultérieure - vous pourriez même ne pas en avoir besoin.
les trois premières règles de l'accord de performance sont: 1. Mesure, 2. Mesure un peu plus. 3. Mesurer à nouveau...
une autre différence importante, L'État de Session sera bloqué si les requêtes Ajax async concurrentes sont exécutées, il produira des performances
Cache est dans le champ d'Application dans le but de réduire le nombre de fois qu'un élément de données est obtenu. La Session est dans la portée de session d'un utilisateur avec 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. Vous stockez session dans une base de données ou en mémoire? Si en mémoire vous utilisez un serveur séparé ou si vous utilisez le serveur web courant pour la session?
selon la façon dont les choses sont organisées pour vous, il peut y avoir des implications de performance lorsque vous utilisez quelque chose comme un datatable qui me dit que vous stockez peut-être de grandes quantités de données.
aussi Session est stocké par utilisateur et est récupéré par utilisateur au moyen de leur ticket de Session qui est stocké soit dans un cookie de Session ou sur L'URL s'ils n'acceptent pas les cookies et que vous avez configuré ASP.NET pour le mode sans cuisson. Tout ce que vous cachez 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.
Session est par utilisateur, le Cache est pour l'application.
les éléments dans le 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 dans le Cache ne sont jamais garantis d'exister, mais la Session y restera jusqu'à la fin de la session.
stocker des éléments sur une base par utilisateur (via une Session ou une utilisation créative de Cache) peut conduire à une beaucoup d'utilisation de la mémoire et doit être considérée avec soin.
en plus de tout cela, si IIS réinitialise le processus worker, vous pouvez perdre votre Cache et votre Session.
Voir cette réponse .
La Sessionpeut réduire à néant les performances de votre application, à moins que vous n'utilisiez un fournisseur d'arrière-plan comme memcached ou velocity. Généralement, vous devriez l'éviter.
Session-je utiliser spécifique où Cache pas. cet article est utile .