J'exécute un test où je comparais le temps de récupération du temps B / W appfabric et SQL Server 2008 et l'apparence appfabric fonctionne 4 fois plus de temps plus lent que SQL Server.
J'ai une configuration SQL Server 2008 qui contient une seule table avec 4 colonnes (tous Voici le code p> et voici la boucle pour récupérer les données du cache p> J'ai exactement la même logique de récupérer des données de SQL Server. Il crée un P> nvarchar code>). La table a 6000 rangées. J'insère la même ligne (que CLR Serializable Obj) dans le cache AppFabric. Je gère une boucle pour récupérer des données x fois. P> SQL Server 2008 R2 Reading-1(ms) Reading-2(ms) Reading-3(ms) Average Time in Seconds
Iteration Count = 5 2528 2649 2665 2.614
Iteration Count = 10 5280 5445 5343 5.356
Iteration Count = 15 7978 8370 7800 8.049333333
Iteration Count = 20 9277 9643 10220 9.713333333
AppFabric Reading-1 Reading-2 Reading-3 Average Time in Seconds
Iteration Count = 5 10301 10160 10186 10.21566667
Iteration Count = 10 20130 20191 20650 20.32366667
Iteration Count = 15 30747 30571 30647 30.655
Iteration Count = 20 40448 40541 40503 40.49733333
3 Réponses :
Je pense que votre test est biaisé et vos résultats sont non optimaux.
sur le cache distribué
à propos de votre test
Une autre chose importante est que vous ne testez pas la même chose: sur un côté, vous testez SELECT * et et de l'autre côté que vous testez N x obtenir l'article.
Je ne pense pas que vous ayez utilisé D-cache avant. Je connais simplement des choses ne suffisent pas. >> Si je active le cache local, ce serait un test injuste. >> Bulk Get - J'aurais pu faire de même pour SQL Server et je suis sûr que cela serait vraiment rapide. SQL Server ne déteste rien de plus que simplement de récupérer une seule ligne. >> Pourquoi voudrais-je activer la compression pour seulement 6k enregistrements? chacun avec seulement 4 rangements de chaînes.
@ user1707312 Je ne comprends pas votre commentaire. pourriez-vous expliquer ? Je ne suis pas un maître d'appfabric. Je l'ai utilisé depuis un an. Si vous avez déjà utilisé D-cache avant, vous devez également savoir que l'utilisation de D-cache ne vise pas l'amélioration des performances, mais une évolutivité. "Le test de charge" dans A pour boucle sur un seul client avec une seule table de données n'est pas la meilleure approche.
oublie -Il permet de ne pas y entrer. Point de vue de performance de formulaire BTW Essayez de comparer l'appfabric avec MemCache / Couchbase.
@ user1707312 Votre scénario n'est pas clair. Ajoutez également le test SQL Server et les données (6000 rangées OK, mais qu'est-ce qui se trouve à l'intérieur de chaque ligne). Pour une mise en cache D-Caching efficace, vous devez catégoriser vos données et utiliser un modèle d'accès approprié. De mes expériences passées, la mise en cache la plus difficile (locale ou distribuée) est de savoir comment trouver la meilleure granularité.
J'ai une meilleure réponse sur la forme MSDN. social.msdn.microsoft. Com / Forums / en-US / Velocity / Fil / ...
Hey user1707312 Pouvez-vous mettre la réponse ici et le marquer comme répondu.
Ceci peut être causé par la sérialisation intégrée.
.NET La sérialisation utilise la réflexion qui a à son tour
La différence est la tenue de réseau. Dans votre exemple SQL, vous saurez sur le réseau une fois et sélectionnez N lignes. Dans votre exemple Appfabric, vous saurez sur le réseau par enregistrement au lieu de en vrac. C'est la différence. Pour prouver cela, stockez temporairement vos enregistrements dans AppFabric sous forme de liste et obtenez simplement la liste une fois, ou utilisez l'API d'Appfabric Bulk pour les sélectionner dans une requête - cela devrait expliquer une grande partie de la différence.
NE PENSEZ PAS QU'IL SUR LE FAIRE: Il semble être récupérer des données de données par ligne: SQLCOMMAND = 'SELECT * du nom de table où posid =' SIONID ''