AppFabric Caching - Utilisation correcte de DataCacheFactory et DataCache

Question

Je cherche la façon la plus performante d'organiser l'utilisation du datacache et de la fabrique de datacache pour les appels de cache d'AppFabric, pour un nombre de caches compris entre 400 et 700 par chargement de page (et à peine quelques puts). Il semble que l'utilisation d'un seul DataCacheFactory statique (ou éventuellement deux dans une configuration round-robin) soit la solution.

Dois-je appeler GetCache("cacheName") pour chaque demande d'objet DataCache, ou dois-je en créer un statique au moment de l'initialisation de la fabrique de DataCache et l'utiliser pour tous les appels ?

Dois-je gérer des exceptions, vérifier les codes d'échec et tenter de nouvelles tentatives ?

Dois-je prendre en compte la contention lorsque plusieurs threads essaient d'utiliser le magasin de cache et veulent le même élément (par clé) ?

Existe-t-il une documentation qui explique en détail la conception et l'utilisation de ce système ?

---

Quelques informations que j'ai recueillies jusqu'à présent sur le forum :

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

"La création de la fabrique implique une connexion au cluster et peut prendre un certain temps. Mais une fois que vous avez l'objet factory et le cache avec lequel vous voulez travailler, vous pouvez simplement réutiliser ces objets pour faire des puts et des gets 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

"La création d'un seul DataCacheFactory (singleton) est plus performante que la création de plusieurs DataCacheFactory. Vous ne devez pas créer de DataCacheFactory pour chaque appel, car les performances s'en ressentiront."

"Veuillez essayer d'encapsuler l'algorithme round-robin (ayant 3/4/5 instances d'usine) dans votre singleton et comparez 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 un plus petit nombre de clients et augmenter le débit, une astuce consiste à utiliser plusieurs instances de DataCacheFactory. L'instance de DataCacheFactory crée une connexion aux serveurs (par exemple, s'il y a 3 serveurs, elle créera 3 connexions) et multiplexe toutes les demandes provenant des caches de données sur ces connexions. Par conséquent, si le volume d'entrées/sorties est très élevé, ces connexions TCP risquent d'être engorgées. Une solution consiste donc à créer plusieurs instances de DataCacheFactory, puis à utiliser les opérations sur ces instances."

---

Voici 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 de l'article du forum :

Bonjour, désolé pour la réponse tardive, mais je tiens à dire que ces documents sont excellents. questions et qu'elles seront probablement utiles à d'autres.

T d'une DataCacheFactory par thread sauf si vous avez besoin de différentes configurations. Par exemple, si vous programmez DataCacheFactory avec l'option DataCacheFactoryConfiguration, vous pourriez vouloir en créer une qui dont le cache local est activé et un autre qui ne l'est pas. Dans ce cas, vous devez utiliser différents objets DataCacheFactory en fonction de la configuration que vous configuration requise pour votre scénario. Mais à part les les différences de configuration, vous ne vous ne devriez pas constater de gain de performance en en créant plusieurs DataCacheFactories.

Sur le même sujet, il existe un MaxConnectionsToServer (soit programmatique dans DataCacheFactoryConfiguration ou dans le fichier de configuration de l'application en tant que [ ] un attribut de l'élément dataCacheClient ). Cela détermine le nombre de de chenaux par DataCacheFactory qui sont sont ouverts à la grappe de caches. Si vous vous avez des exigences élevées en matière de débit et que vous disposez d'une bande passante CPU/réseau réseau, l'augmentation de ce paramètre à 3 ou plus peut augmenter le débit. Nous ne recommandons pas d'augmenter ce paramètre sans raison ou à une valeur trop trop élevée pour vos besoins. Vous devez modifier la valeur et tester ensuite votre scénario pour observer les résultats. Nous espérons avoir plus de conseils officiels sur officielle sur ce sujet à l'avenir.

Une fois que vous avez un DataCach n'avez pas besoin d'appeler GetCache() plusieurs fois pour obtenir plusieurs objets DataCache. Chaque appel à GetCache() pour le même cache sur la même usine renvoie le même objet DataCache. De plus, une fois que vous avez l'objet DataCache, il n'est pas nécessaire de de continuer à appeler DataCacheFactory pour l'obtenir. Il suffit de stocker l'objet DataCache et continuez à l'utiliser. Cependant, ne laissez pas l'objet DataCacheFactory soit éliminé. La durée de vie de l'objet DataCache est liée à l'objet DataCacheFactory.

Il ne faut jamais avoir avec les requêtes Get. [ ] avec les requêtes Put/Add, il peut y avoir si plusieurs clients de cache de données mettent à jour la même clé au même moment même clé en même temps. Dans ce cas, vous obtiendrez une exception avec le code d'erreur ERRCA0017, RetryLater et un sous-statut ES0005, KeyLatched. Cependant, vous pouvez facilement ajouter une gestion des exceptions et un d'exception et une logique de réessai pour en cas d'erreurs de ce type. Cela peut être fait pour les codes RetryLater avec différentes valeurs de statut. Pour plus d'informations [ ] http://msdn.microsoft.com/en-us/library/ff637738.aspx . Vous pouvez également utiliser le verrouillage pessimiste en utilisant les API GetAndLock() et PutAndUnlock(). Si vous utilisez cette il est de votre responsabilité de de vous assurer que tous les clients du cache utilisent le verrouillage le verrouillage pessimiste. Un appel à Put() effacera un objet qui a été précédemment verrouillé par GetAndLock().

J'espère que cela vous aidera. Comme je l'ai dit, nous espérons que ce type d'orientation sera intégré dans un contenu formel bientôt. Mais c'est mieux de les partager ici sur le forum d'ici là. Merci beaucoup !

Jason Roth

Answer 2

Dois-je appeler GetCache("cacheName") pour chaque demande d'objet DataCache, ou est-ce que statique au moment de l'initialisation de la l'initialisation de la fabrique de DataCache et et l'utiliser pour tous les appels ?

Je suppose que la réponse devrait être : essayez les deux méthodes et voyez s'il y a une différence, mais un DataCache statique me semble plus logique qu'un appel correspondant à GetCache pour chaque appel à Get.

L'article "Pushing Client Performance" suggère qu'il existe un point idéal où le nombre d'instances de DataCacheFactory permet d'obtenir des performances maximales, au-delà duquel la surcharge de mémoire commence à jouer contre vous - il est dommage qu'ils n'aient pas donné d'indications (ou même une règle empirique) sur la localisation de ce point.

Je n'ai pas trouvé de documentation sur l'optimisation des performances - je pense qu'AppFabric est encore trop récent pour que ces lignes directrices aient été élaborées. J'ai jeté un coup d'œil dans la table des matières de la page d'accueil d'AppFabric. Livre Pro AppFabric mais il semble beaucoup plus concerné par l'aspect workflow (Dublin) d'AppFabric que par l'aspect mise en cache (Velocity).

Une chose que je voudrais dire cependant : y a-t-il une possibilité de mettre en cache des objets plus volumineux afin de 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 gets par chargement de page me semble être un chiffre énorme !

Answer 3

MaxConnectionsToServer : quel est l'impact de ce paramètre lorsque le cache local est activé et que les valeurs sont lues à partir du cache local ? Vous ne contactez pas le serveur pour un "Get" à moins qu'il ne soit pas disponible dans le cache local, n'est-ce pas ?