Réglage service WCF pour le client plusieurs appels

Question

J'ai fait un service WCF qui est défini comme suit:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)] 

liaison est effectuée à l'aide netTcpBinding.

Nous prenons en charge plus de 50 clients qui appellent le serveur de temps en temps. Chaque client ouvre un canal en utilisant channelfactory une fois qu'il est chargé et utilise ce canal pour tous les appels (ne crée le canal et le proxy qu'une seule fois).

Nous avons construit un petit testeur de charge qui imite le client en appelant le serveur par 50 threads différents à la fois (en utilisant 50 canaux différents). lorsque nous exécutons ce testeur, après que le 10ème client a essayé de se connecter, tous les autres clients ont échoué à se connecter. Nous avons mis à 100.

limitation

Mes questions sont:

1. est-il exact pour chaque client de créer un canal et l'utiliser par la durée de vie du client? ou dois-je utiliser une instruction using pour chaque appel au serveur (créer et distraire un nouveau canal pour chaque appel).
2. Le service a-t-il une limite de connexions de canal? autre alors étranglement?

Answer 1

Avez-vous vérifié la limite de CAL sur votre serveur?

Il est généralement bon de nettoyer si vous n'utilisez pas quelque chose, donc je collerais tout dans une déclaration using.

Answer 2

Le nombre de connexions simultanées au serveur est contrôlé à la fois par le comportement de limitation du service WCF et par votre machine (c'est le système d'exploitation, en réalité). Windows XP machines avait une limite stricte sur 10 connexions simultanées - pourrait-il être le problème? Si vous utilisez un serveur, cette limite ne devrait pas s'appliquer. Le service throttling behavior a aussi une valeur par défaut de MaxConcurrentSessions qui est 10 - et vos connexions netTcpBinding auront toutes une session au niveau du transport, donc c'est certainement aussi un problème.

Vous pouvez modifier les paramètres du comportement d'étranglement de service dans le fichier de configuration de votre application:

<serviceBehaviors> 
    <behavior name="TcpMoreThan10"> 
     <serviceThrottling 
     maxConcurrentCalls="100" 
     maxConcurrentSessions="50" 
     maxConcurrentInstances="50" /> 
    </behavior> 
    </serviceBehaviors> 

et que vous devez ajouter ce comportement de service à votre étiquette <service>, bien sûr, pour lui permettre:

<service name="....." behaviorConfiguration="TcpMoreThan10"> 
    .... 
</service> 

Si vous avez seulement jusqu'à 50 clients appelant de façon sporadique, et ils sont tous les clients « internes » à l'aide netTcpBinding, je ne vois aucune raison pourquoi vous voulez faire cette chose un multithread singleton, vraiment. En remarque: les singletons multithread sont notoirement difficiles à écrire, difficiles à corriger, vous devez vous soucier de l'accès simultané à vos variables internes, etc. - programmation plutôt désordonnée. Pourquoi ne pas utiliser le mode d'instance par appel par défaut?Avec ceci:

• chaque demande à venir tets dans son propre, séparé, isolé, par exemple fraîchement créé de la classe de service
• chaque instance de classe de service ne gère que jamais exactement un appelant, il n'y a donc pas besoin de désordre et compliqué modèles de programmation multithread