Worker Role WCF Performance

Question

J'essaie de déterminer le scénario d'hébergement de service WCF le plus performant possible. J'assemble une application Web sur site très volumineuse (qui sera éventuellement hébergée dans Azure). L'application ASP.Net communiquera avec les services WCF hébergés dans les rôles de travail à l'aide de NetTcpBinding. 1) Héberger les services dans les rôles de travail, puis utiliser le bus de service (en utilisant ACS pour la sécurité) pour connecter le client et le service sera toujours plus lent que d'héberger les services WCF dans les rôles de travail, se connecter directement au point de terminaison et utiliser une approche nom d'utilisateur/mot de passe. 2) Les services REST seront toujours plus lents que les services NetTcpBinding car ils utilisent HTTP au lieu de binaires. Initialement, j'ai opté pour l'approche ServiceBus parce que j'aime le nettoyage du mécanisme de sécurité, mais à moins que la connexion en cours ne puisse être directe, le relais entraînera un surcoût important. Sur la base de ces hypothèses, j'ai opté pour: -WCF Services hébergés dans des rôles de travailleurs -custom Nom d'utilisateur/mot de passe ou utiliser le nom d'utilisateur/mot de passe ACS ?????? -NetTcpBinding

Cela vous semble-t-il exact? Une autre exigence est la plus petite quantité de code spécifique à la sécurité que j'ai besoin de créer. Donc, devrais-je utiliser le nom d'utilisateur ACS/mot de passe ou ????

tout aperçu sur la façon de configurer la sécurité du code le moins performant et le moins personnalisé serait super!

merci

Answer 1

Premièrement: référence, indice de référence, indice de référence. Nous avons été plutôt surpris par les caractéristiques de performance d'Azure; en particulier SQL Azure était plus lent que notre système hébergé Rackspace par un facteur de deux ou trois. La latence entre la base de données et le serveur a éclipsé tout le reste. Cela dit: en théorie, je confirmerais que l'utilisation des noms d'utilisateur/mots de passe entre le client et le service sera plus rapide que celle d'ACS.

Mais avez-vous besoin de vérifier vos informations d'identification? Pouvez-vous utiliser des points de terminaison internes privés (comme ici: http://msdn.microsoft.com/en-us/library/windowsazure/gg432980.aspx) - si c'est le cas, vous n'avez pas besoin de vérification des informations d'identification.

Si vous avez besoin d'exposer un point de terminaison public, j'envisagerais sérieusement d'utiliser des certificats SSL client à la place car cela peut fournir un chiffrement ainsi qu'une authentification. En ce qui concerne REST versus binaire, cela dépend beaucoup du type d'application que vous utilisez. Mon expérience avec la pile Microsoft REST est qu'elle est remarquablement efficace: en pratique au moment où la connexion est établie et que les données circulent, vous avez essentiellement une connexion TCP brute entre le client et le serveur. Ce que vous gagnez avec REST, cependant, est la sémantique HTTP, la possibilité d'utiliser des équilibreurs de charge et la commodité générale.

Mais, encore une fois: je créerais quelques exemples d'applications et testerais par vous-même. (Et revenez et postez un lien vers votre entrée de blog où vous publiez les résultats, hein?)

Answer 2

Je n'utiliserais pas l'ACL sauf si j'en avais vraiment besoin, ce que je ne pense pas que ce soit votre scénario. L'ajout d'un courtier supplémentaire juste pour authentifier les clients ajoutera une latence inutile. Deuxièmement, vous n'avez pas besoin d'un rôle de travailleur pour utiliser NetTcp, vous pouvez simplement configurer un rôle web avec un point de terminaison tcp. Cela hébergera votre service dans IIS en utilisant WAS et TCP.Vous pouvez même configurer les services WCF dans un point de terminaison privé dans azure que seule l'application Web également hébergée dans azure peut voir, donc aucune authentification n'est nécessaire.