AppFabric Caching - Utilisation correcte de DataCacheFactory et DataCache

Question

Je cherche la manière la plus performante d'organiser l'utilisation de la fabrique de datacache et datacache pour les appels de mise en cache AppFabric, pour entre 400 et 700 cache par chargement de page (et pratiquement aucun put) . Il semble que l'utilisation d'une seule DataCacheFactory statique (ou peut-être un couple dans une installation round-robin) est la voie à suivre. Est-ce que j'appelle GetCache ("cacheName") pour chaque demande d'objet DataCache, ou est-ce que je fais une statique au moment où la fabrique DataCache est initialisée et l'utilise pour tous les appels? Dois-je gérer des exceptions, vérifier les codes d'échec et tenter une nouvelle tentative? Dois-je tenir compte de la contention lorsque plusieurs threads tentent d'utiliser le cache et souhaitent le même élément (par clé)?

Existe-t-il une sorte de documentation qui explore correctement la conception et l'utilisation de cela?

---

Certaines informations que j'ai recueillies jusqu'à présent du forum:

http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/98d4f00d-3a1b-4d7c-88ba-384d3d5da915

« Création de l'usine consiste à se connecter au cluster et peut prendre un certain temps, mais une fois que vous. avoir l'objet usine et le cache que vous voulez utiliser, vous pouvez simplement réutiliser ces objets pour faire des puts et entrer dans le cache, et vous devriez voir des performances beaucoup plus rapides. "

http://social.msdn.microsoft.com/Forums/en-US/velocity/thread/0c1d7ce2-4c1b-4c63-b525-5d8f98bb8a49

« Création unique DataCacheFactory (singleton) est plus performante que la création de multiples DataCacheFactory. Vous ne devez pas créer DataCacheFactory pour chaque appel, il aura frappé la performance. » "Veuillez essayer d'encapsuler un algorithme à tour de rôle (comportant des instances d'usine 3/4/5) dans votre singleton et comparer les résultats du test de charge."

http://blogs.msdn.com/b/velocity/archive/2009/04/15/pushing-client-performance.aspx

« Vous pouvez augmenter le nombre de clients pour augmenter le débit du cache. Mais parfois, si vous voulez avoir plus petit nombre de clients et d'augmenter le débit, une astuce consiste à utiliser plusieurs instances DataCacheFactory. L'instance DataCacheFactory crée une connexion aux serveurs (par exemple s'il y a 3 serveurs, il créera 3 connexions) et multiplexe toutes les requêtes des datacaches sur ces connexions Donc, si le volume put/get est très élevé, ces connexions TCP pourraient Il est donc possible de créer plusieurs instances DataCacheFactory, puis d'utiliser les opérations qui s'y rapportent. " Ici, ce qui est utilisé jusqu'à présent ... la propriété est appelée et si la valeur de retour n'est pas nulle, une opération est effectuée.

private static DataCache Cache 
{ 
    get 
    { 
     if (_cacheFactory == null) 
     { 
      lock (Sync) 
      { 
       if (_cacheFactory == null) 
       { 
        try 
        { 
         _cacheFactory = new DataCacheFactory(); 
        } 
        catch (DataCacheException ex) 
        { 
         if (_logger != null) 
         { 
          _logger.LogError(ex.Message, ex); 
         } 
        } 
       } 
      } 
     } 

     DataCache cache = null; 

     if (_cacheFactory != null) 
     { 
      cache = _cacheFactory.GetCache(_cacheName); 
     } 

     return cache; 
    } 
} 

---

Voir cette question sur le forum Microsoft AppFabric: http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/e0a0c6fb-df4e-499f-a023-ba16afb6614f

Answer 1

Voici la réponse du post sur le forum:

Salut. Désolé pour la réponse différée, mais je tiens à dire que ce sont d'excellentes questions et seront probablement utiles à d'autres.

Il ne devrait pas être un besoin de plus d'un DataCacheFactory par thread à moins que vous différentes configurations exigez. Par exemple, si vous configurez le programme DataCacheFactory avec la classe de DataCacheFactoryConfiguration, alors vous voudrez peut-être créer un qui a cache local activé et un autre qui ne fonctionne pas. Dans ce cas, vous devez utiliser différents objets DataCacheFactory en fonction de la configuration requise par votre scénario. Mais autre que les différences de configuration, vous ne devrait pas voir un gain de performance de en créant plusieurs DataCacheFactories.

Sur le même sujet, il y a un cadre de MaxConnectionsToServer (soit programmatique dans DataCacheFactoryConfiguration ou dans le fichier de configuration de l'application comme un attribut de l'élément dataCacheClient ).Cela détermine le nombre de chennels par DataCacheFactory que sont ouverts au cluster de cache. Si vous avez des exigences de débit élevé et également disponible CPU/réseau bande passante, l'augmentation de ce paramètre à 3 ou supérieur peut augmenter le débit. Nous ne recommandons pas d'augmenter ce sans cause ou à une valeur qui est trop élevée pour vos besoins. Vous devez modifier la valeur puis tester votre scénario pour observer les résultats. Nous espérons avoir plus de conseils officiels sur à l'avenir.

Une fois que vous avez un DataCacheFactory, vous ne pas besoin d'appeler getCache() plusieurs fois pour obtenir plusieurs DataCache objets. Chaque appel à GetCache() pour le même cache sur le même usine renvoie le même objet DataCache . En outre, une fois que vous avez l'objet DataCache, vous n'avez pas besoin de pour continuer à appeler DataCacheFactory pour cela. Il suffit de stocker l'objet DataCache et de continuer à l'utiliser. Cependant, ne laissez pas l'objet DataCacheFactory être éliminé. La vie de l'objet DataCache est liée à l'objet DataCacheFactory.

Vous ne devriez jamais avoir à vous soucier de conflit avec Get demandes. Cependant, avec des demandes Put/Add, il peut y avoir contention si plusieurs clients de cache de données mettent à jour la même clé à en même temps. Dans ce cas, obtiendra une exception avec un code d'erreur ERRCA0017, RetryLater et un sous-statut de ES0005, KeyLatched. Cependant, vous pouvez facilement ajouter la gestion des exceptions et réessayer la logique pour tenter la mise à jour à nouveau lorsque des erreurs telles que celles-ci se produisent. Ceci peut être fait pour les codes RetryLater avec diverses valeurs de sous-états. Pour plus d'informations, voir http://msdn.microsoft.com/en-us/library/ff637738.aspx. Vous pouvez également utiliser le verrouillage pessimiste à l'aide des API GetAndLock() et PutAndUnlock(). Si vous utilisez cette méthode , il est de votre responsabilité de assurez-vous que tous les clients de cache utilisent verrouillage pessimiste. Un appel Put() va effacer un objet qui était précédemment verrouillé par GetAndLock().

J'espère que cela aide. Comme je l'ai dit, nous espérons obtenir ce type de conseils en un certain contenu formel bientôt. Mais il est préférable de le partager ici sur le forum jusque là. Merci!

Jason Roth

Answer 2

Est-ce que j'appelle getCache ("cacheName") pour chaque demande d'objet DataCache ou ne je fais statique au time L'usine DataCache est initialisée et l'utilise pour tous les appels?

Je suppose que la réponse devrait être; essayez les deux manières et voyez s'il y a une différence, mais un DataCache statique me semble avoir plus de sens qu'un appel correspondant à GetCache pour chaque appel à Get. Cet article "Pushing Client Performance" suggère qu'il existe un point fort où le nombre d'instances de DataCacheFactory vous permet d'obtenir des performances maximales au-delà desquelles la surcharge de mémoire commence à fonctionner contre vous - c'est dommage qu'ils n'aient donné aucune directive (ou même une règle de base) sur où cet endroit pourrait être.

Je n'ai pas trouvé de documentation sur la maximisation des performances - Je pense qu'AppFabric est encore trop récent pour que ces directives soient encore supprimées. J'ai jeté un oeil dans le contenu pour le Pro AppFabric book, mais il semble beaucoup plus concerné généralement avec le côté workflow (Dublin) d'AppFabric plutôt que le morceau de mise en cache (Velocity). Une chose que je dirais cependant: y at-il une possibilité pour vous de mettre en cache des objets plus "chunkier" afin que vous puissiez faire moins d'appels à Get? Pourriez-vous mettre en cache des collections plutôt que des objets individuels, puis décompresser les collections sur le client? 700 cache par chargement de page me semble être un nombre énorme!