Accès simultané au proxy client WCF

Question

Je suis actuellement en train de jouer un peu avec WCF, pendant ce temps j'ai posé une question où je ne suis pas sûr d'être sur la bonne voie. Supposons une configuration simple qui ressemble à ceci: client -> service1 -> service2. La communication est basée sur tcp. Donc, là où je ne suis pas sûr, s'il est logique que le service1 met en cache le proxy client pour service2. Je pourrais donc avoir un accès multi-thread à ce proxy, et je dois y faire face. Je voudrais profiter de la session tcp pour obtenir de meilleures performances, mais je ne suis pas sûr si cette "architecture" est supportée par WCF/réseau/quoi que ce soit. Le problème que je vois est que toute la communication passe par le même canal, si je n'utilise pas de verrous ou une autre synchronisation.

Je suppose que la meilleure idée est de mettre en cache le proxy dans une variable threadstatic. Mais avant cela, je voulais confirmer que ce n'est vraiment pas une bonne idée d'avoir une seule instance de proxy.

tia Martin

Answer 1

Si vous ne savez pas que vous avez un problème de performances, alors pourquoi s'inquiéter de la mise en cache? Vous vous ouvrez au risque de mettre en œuvre de façon incorrecte le code multithread, et sans aucun avantage clair et mesurable.

Avez-vous encore mesuré les performances, ou profilé l'application pour voir où elle passe son temps? Si ce n'est pas le cas, il se peut que vous constatiez que la surcharge de plusieurs sessions TCP ne correspond pas à vos problèmes de performance. Vous voudrez peut-être avoir le temps d'optimiser une autre partie de votre application, mais vous aurez passé du temps à optimiser quelque chose qui n'a pas besoin d'être optimisé.

Answer 2

prudent avec ThreadStatic, .net change le fil de sorte que la variable peut obtenir nulle.

Pour la session ... peut-être vous pouvez utiliser la session des appels activés: http://msdn.microsoft.com/en-us/library/ms733040.aspx

Mais je ne recommande pas utiliser si vous n'avez pas problème de performance. J'utiliser la voie normale, ou si le service 1 est pour vous transmettre pouvez utiliser cette fonctionnalité facilement avec 4.0: http://www.sdn.nl/SDN/Artikelen/tabid/58/view/View/ArticleID/2979/Whats-New-in-WCF-40.aspx

Cordialement

Answer 3

Tout d'abord, assurez-vous que vous savez sur le comportement de ThreadStatic dans ASP.NET applications:

http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html

le même fil qui a commencé votre demande ne peut pas être le même fil qu'il se termine. Fondamentalement, le seul moyen sûr de stocker le stockage local Thread dans les applications ASP.NET est à l'intérieur de HttpContext. La prochaine approche évidente consisterait à créer un client wrapper pour gérer votre proxy client WCF et à vous assurer que chaque requête IO est thread-safe à l'aide de verrous.

Bien que ma préférence personnelle serait d'utiliser un pool de clients proxy. Chaque fois que vous en avez besoin, mettez-le hors de la file d'attente de la piscine et quand vous en avez fini, remettez-le.

Answer 4

J'utilise déjà une telle structure. J'ai un service qui collabore avec d'autres services et réalise la mise en œuvre. Bien sûr, dans mon cas, le client appelle une méthode unidirectionnelle du premier service. Je reçois très bien benifit.Bien sûr, je l'ai également configuré pour limiter le nombre d'appels simultanés dans certains cas.

Answer 5

Oui, cette architecture est prise en charge par WCF. Je fais face à des applications tous les jours qui utilisent des structures similaires, en utilisant NetTCPBinding.

La plus grande chose à se soucier est le ConcurrencyMode des différents services concernés, et en veillant à ce qu'ils ne bloquent pas inutilement. Il est très facile d'entrer dans un scénario où vous aurez des délais d'attente garantis, ou du moins des performances médiocres en raison de plusieurs appels synchrones à travers les limites de service. Même les appels OneWay ne sont pas garantis de revenir immédiatement.