De nombreux facteurs différents peuvent entrer en ligne de compte. Si l'on admet que la modification du modèle d'instanciation du service n'a eu aucun effet (c'est une grande hypothèse), il est possible que le goulot d'étranglement se trouve en amont du service. Soit au niveau du serveur web, soit au niveau du générateur de charge du client.
Vous avez plusieurs domaines à examiner pour les réglages : le client, le serveur web, le serveur de service wcf - en supposant qu'il n'y ait pas de périphériques réseau au milieu. Choisissez une extrémité et travaillez vers l'autre extrémité. Puisque je suppose déjà que ce n'est pas le service, je commencerais par le client et j'irais vers le service wcf.
Client
Quelle est la machine qui supporte la charge du serveur web ? Un ordinateur portable ? Un ordinateur de bureau ? Un agent de test dédié ou partagé ? Le client qui joue le rôle de générateur de charge dans le cadre de ce test est également susceptible de maxConnections car il s'agit d'un environnement client.
Quelle est l'utilisation de l'unité centrale du client qui génère la charge ? Se pourrait-il que le pilote de test soit tout simplement incapable de générer une charge suffisante pour pousser ces boîtes ? Pouvez-vous ajouter des clients supplémentaires à votre test ?
Serveur Web
Qu'est-ce que la system.net/processModel dans le fichier machine.config du serveur web ASP.NET ? Essayez de définir autoConfig = true. Cela permettra à la configuration de se dimensionner automatiquement en fonction de la "taille" de la machine sur laquelle elle est exécutée.
Service WCF
Examiner le service WCF pour vérifier s'il existe des paramètres par défaut d'étranglement et les modifier en conséquence. Voir ServiceThrottlingBehavior sur MSDN.
Faites-nous part de tout changement de comportement que vous pourriez observer (le cas échéant) si vous procédez à des changements !