Performance d'hébergement de WCF

Je suis en train d'écrire une application au niveau de l'entreprise utilisant les services WCF et NetTCP. J'ai d'abord choisi NetTCP par curiosité, mais plus tard, j'ai déterminé que c'était la meilleure option pour moi car je peux avoir des services qui durent 5+ heures pour retourner les résultats en raison de la quantité de données impliquées.Performance d'hébergement de WCF

La façon dont je crée actuellement mes services est un processus en plusieurs étapes. J'ai un élément de configuration (using System.Configuration) qui spécifie certains trucs par défaut (numéro de port, nom de serveur pour les clients qui se connectent, si activer HTTP aussi bien que NetTCP, etc.) et qui a une collection de "services" dessous il. Par exemple, voici ce qu'un basique ressemble à:

<serverConfiguration tcpListenerPortNumber="60000" httpGetEnabled="true" httpListenerPortNumber="6000" serverName="localhost" retryEnabled="true" retryInterval="5" maxRetryAttempts="3"> 
    <services> 
     <add virtualDirectory="Service1" applicationName="Service1" assembly="SampleService" type="SampleService.Service1" />    
    </services> 
</serverConfiguration>

Fondamentalement, ce qui se passe ici est mon service Windows démarre et regarde tout dans la collection < services/> et engendre hors un fil par service pour accélérer le temps de démarrage et chaque thread contient un AppDomain où le service vit vraiment, donc si un service a une sorte de faute, il ne fait pas tomber le système.

Le "problème" que je rencontre est que cette application héberge environ 20 services et qu'il faut 15 à 20 secondes pour que tous les services soient opérationnels. J'ai fait les threads et les pièces d'AppDomain pour l'abaisser à cette valeur (utilisé pour prendre plus d'une minute car chaque service a été ouvert séquentiellement) mais il me semble que cela pourrait aller beaucoup plus vite.

Quelqu'un a des suggestions? ~~Google~~ Bing a une pléthore d'exemples pour l'hébergement d'un service, mais je ne trouve pas beaucoup là-bas pour les applications du monde réel (malheureusement, "Hello World" n'est pas attrayante pour les utilisateurs finaux). Si vous hébergez actuellement plusieurs services via un service Windows et NetTCP, comment le faites-vous?

Source

2009-06-20 RubyHaus

Est-ce que _need_ doit être plus rapide que cela? Si cela ne démarre qu'une fois par jour, cela fait 20 secondes par jour. Ce n'est pas long. –

C'est surtout pendant le débogage que c'est plus lent, donc c'est la zone principale dans laquelle j'essaie d'extraire les performances. Les services eux-mêmes fonctionneront indéfiniment (moins les redémarrages et tels bien sûr). – RubyHaus

Je l'ai compris finalement et cela n'avait rien à voir avec WCF ou mes pièces de configuration après tout. Lorsque j'ai créé l'AppDomain, j'ai volé le code d'un autre projet dont la taille était beaucoup plus petite et j'ai découvert que la section créant AppDomains utilisait l'option SingleDomain. Le changement à MultiDomain a fait passer les choses à> 4 secondes pour la charge totale et l'utilisation de la mémoire a chuté à ~ 40 Mo à partir de ~ 150 Mo.

Merci pour l'aide si - au moins il m'a fait revoir le code!

Source

2009-06-25 21:26:46 RubyHaus

J'ai trois suggestions:

Tout d'abord, si un appel peut prendre 5+ heures, je considérerais une mise en attente/appelerons architecture de style.

Envisagez de scinder vos services en 20 services Windows, où chaque service s'exécute dans ses propres services Windows. Cela ajoute de la complexité et augmente l'utilisation de la mémoire, mais un service individuel peut être disponible plus rapidement. Enfin, vérifiez le code qui est dans le consructor du service, pour tout code inutile.

Source

2009-06-20 22:19:54

20 services ne sont vraiment pas réalisables - en particulier du point de vue du débogage. Nous sommes encore en développement et je suppose que nous avons encore 10-20 services à construire. La complexité de quelque chose comme ça pourrait facilement disparaître des graphiques du point de vue de la maintenance. – RubyHaus

Pourquoi est-ce un problème de maintenance, si tous les services ont été créés sur le même framework, utilisent la même infrastructure, conventions de nommage, etc. Je veux dire la même technologie de journalisation, configuration, etc. 40 services presque identiques ne devraient pas être plus difficile à maintenir qu'un ou deux qui ne sont pas identiques. –

Eh bien, beaucoup de services s'utilisent les uns les autres (c.-à-d. Qu'on peut appeler quelqu'un, etc.), donc déboguer ce serait vraiment une douleur contre un seul "point" si vous voulez (pas un vrai point final, mais je pense vous obtenez mon point). Pour ne pas mentionner, 40 Windows Services semble juste une quantité intense d'overkill - surtout si un morceau de base change et je dois ensuite déployer ces DLL à chaque emplacement. Je pourrais GAC le noyau de choses, mais il semble encore beaucoup d'exagération. – RubyHaus

Performance d'hébergement de WCF

Répondre

Questions connexes