DAL, Session, Architecture de cache

Question

Je tente de créer un Data Access Layer pour mon application Web. Actuellement, toutes les données sont stockées dans la session. Quand je suis fini, le DAL va peupler et retourner les données. Est-ce une bonne idée de stocker les données renvoyées dans la session? Un cache distribué/partagé? Ou juste ping la base de données à chaque fois? Remarque: En général, le nombre de lignes dans la table de données sera faible < 2000.

Informations complémentaires:

Presque aucun des données sont partagées. Les paramètres qui sont envoyés aux requêtes SQL sont choisis par l'utilisateur. Les valeurs de paramètre disponibles pour l'utilisateur dépendent de l'utilisateur. Dans la plupart des cas, il est impossible pour deux utilisateurs d'exécuter les mêmes requêtes SQL. Cependant, le même utilisateur peut exécuter la même requête plus d'une fois.

Plus d'infos: Nombre d'utilisateurs simultanés ~ 50 000

Informations importantes: Dans 99% des cas, deux utilisateurs auront les mêmes données/requêtes, cependant, le même utilisateur peut exécuter la même requête/obtenir les mêmes données plusieurs fois.

Merci

Answer 1

Le stockage des données en session est pas une bonne idée parce que:

1. Chaque utilisateur reçoit une copie distincte des mêmes données - énorme gaspillage de la mémoire du serveur.
2. IIS recycle une session si vous la remplissez avec trop de données.

Je recommande de stocker les tables de données dans Cache, et de remplir chaque table uniquement lors de la première demande plutôt que toutes à la fois. De cette façon, si IIS commence à récupérer de l'espace dans le cache, votre code ne sera pas affecté.

Très simple exemple de récupération à la demande:

T GetCached<T>(string cacheKey, Func<T> getDirect) { 
    object value = HttpContext.Current.Cache.Item(cacheKey); 
    if(value == null) { 
     value = getDirect(); 
     HttpContext.Current.Cache.Insert(cacheKey, value); 
    } 
    return (T) value; 
} 

EDIT: - Question mise à jour

Cache vs session locale - état de la session locale est tout ou rien. S'il est trop plein, IIS va tout recycler. En revanche, les éléments du cache sont supprimés individuellement lorsque la mémoire est trop faible, c'est donc beaucoup moins un problème.

Cache vs serveur d'état de session - Je n'ai pas de données pour le sauvegarder, alors dites le si je me trompe, mais j'aurais pensé que la mise en cache des données de manière indépendante dans chaque serveur physique AppDomain serait plus évolutif que de le stocker dans un service d'état de session partagé.

Answer 2

Stockage cette quantité de données dans le Session est une très mauvaise idée. Chaque utilisateur aura sa propre version!

Si c'est partagé données (même pour tous les utilisateurs), envisagez de le déplacer vers l'objet Application.

Answer 3

Boutique /dictionnaires - LookUps et les éléments que votre application nécessiterait très souvent dans Application ou Cache objet; base de données de requête pour les données qui dépendent du rôle de l'utilisateur.

--EDIT--

C'est en réponse à votre commentaire.

Habituellement dans tout système orienté données, les requêtes tournent autour de la table de faits (ou des tables qui sont inévitables à interroger); en supposant que vous avez un mis des tables inévitables, vous pouvez utiliser Cache.Insert():

1. charge les tables inévitables au démarrage de l'application;
2. Charge la plupart des tables interrogées dans le cache à la demande de la table;
3. Base de données de requêtes pour les tables les moins demandées.

Si vous n'avez aucun problème de performances, laissez SQL gérer tout.

Answer 4

La première chose que je dirais est: le cache n'est pas obligatoire partout. Vous devriez l'utiliser judicieusement et très spécialement sur les goulots d'étranglement liés à l'accès aux données.

Je ne pense pas que ce soit une bonne idée de stocker 1000 données différentes avec 2000 enregistrements n'importe où. Si les requêtes sont si dynamiques qu'ayant la même requête sur une courte période est l'exception, le cache ne semble pas être une bonne option.

Et en ce qui concerne une option de cache distribué, je vous suggère de vérifier http://memcached.org. Un cache distribué utilisé par de nombreux grands projets dans le monde.

Je sais que Velocity est proche, mais jusqu'à présent, je sais qu'il a besoin de Windows Server 2008 et c'est quelque chose de très nouveau pour le moment. Normalement, les produits Microsoft sont bons à partir de la version 2.0 :-)