工作者角色 WCF 性能
我正在尝试确定可能的最佳性能 WCF 服务托管方案。我正在组装一个非常大容量的本地 Web 应用程序（最终将托管在 Azure 中）。 ASP.Net 应用程序将使用 NetTcpBinding 与辅助角色中托管的 WCF 服务进行通信。我想验证以下假设：
1）在辅助角色中托管服务，然后使用服务总线（使用 ACS 来确保安全性）连接客户端和服务始终比在辅助角色中托管 WCF 服务（直接连接到端点，并使用用户名/密码方法。
2) REST 服务总是比 NetTcpBinding 服务慢，因为它们使用 HTTP 而不是二进制。
最初，我选择了 ServiceBus 方法，因为我喜欢这种安全机制的干净程度，但除非正在进行的连接可以是 Direct，否则中继将导致显着的开销。
基于这些假设，我选择了： -以工作者角色托管的WCF服务 -自定义用户名/密码或使用 ACS 用户名/密码?????? -NetTcpBinding
这听起来正确吗？另一个要求是我需要创建最少数量的安全特定代码。那么，我应该使用 ACS 用户名/密码模型还是？？？
任何有关如何设置性能最佳、自定义代码安全性最少的见解都会很棒！
谢谢
I am trying to determine the best performing WCF service hosting scenario possible. I am assembling a very high volume, on-premise web app (which will eventually be hosted in Azure). The ASP.Net app will communicate with WCF services hosted in worker roles using NetTcpBinding. I would like verification on the following assumptions:
1) Hosting the services in worker roles, then using the Service Bus (using ACS for security) to connect client and service will always be slower than hosting WCF services in worker roles, connecting directly to the endpoint, and using a username/password approach.
2) REST services will always be slower than NetTcpBinding services because they use HTTP instead of binary.
Initially, I opted for the the ServiceBus approach because I like how clean the security mechanism is, but unless the ongoing connection can be Direct, the relay will cause significant overhead.
Based on these assumption, I have opted for:
-WCF Services hosted in worker roles
-custom Username/Password or use ACS username/password??????
-NetTcpBinding
Does this sound about right? Another requirement is the least amount of security specific code I need to create. So, should I use the ACS username/password model or????
any insight on how to setup the best performing, least custom code security would be great!
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
第一：基准，基准，基准。我们对 Azure 的性能特点感到非常惊讶；特别是 SQL Azure 比我们的 Rackspace 托管系统慢两到三倍。数据库和服务器之间的延迟使其他一切都黯然失色。
也就是说：理论上我会证实您的猜测，即在客户端和服务之间使用用户名/密码会比 ACS 更快。
但您是否需要进行任何凭证检查？您可以使用私有内部端点（如下所示：http://msdn.microsoft .com/en-us/library/windowsazure/gg432980.aspx) - 如果是这样，则无需进行任何凭据检查。
如果您确实需要公开公共端点，那么我会认真考虑使用客户端 SSL 证书，因为这可以提供加密和身份验证。
关于 REST 与二进制，很大程度上取决于您正在使用的应用程序的类型。我对 Microsoft REST 堆栈的体验是它非常高效：在实践中，当连接建立并且数据流动时，客户端和服务器之间基本上已经建立了原始 TCP 连接。然而，您通过 REST 获得的是 HTTP 语义、使用负载均衡器的能力以及一般的便利性。
但是，再次强调：我会创建一些示例应用程序并自行测试。 （并且一定要回来发布一个指向您发布结果的博客条目的链接，嗯？）
First: benchmark, benchmark, benchmark. We were quite surprised at the performance characteristics of Azure; in particular SQL Azure was slower than our Rackspace hosted system by a factor of two or three. The latency between the database and the server eclipsed everything else.
That said: in theory I'd confirm your guess that using usernames/passwords between client and service will be faster than ACS.
But do you need to do any credential checking at all? Can you use private internal endpoints (as here: http://msdn.microsoft.com/en-us/library/windowsazure/gg432980.aspx) -- if so then there's no need for any credential checking.
If you do need to expose a public endpoint then I'd seriously consider using client SSL certificates instead as this can provide encryption as well as authentication.
Regarding REST versus binary, much depends on the kind of application you're working with. My experience with the Microsoft REST stack is that it's remarkably efficient: in practice by the time the connection is established and data is flowing you basically have a raw TCP connection between client and server. What you gain with REST, however, is the HTTP semantics, ability to use load balancers, and general convenience.
But, again: I'd create some sample applications and test for yourself. (And do come back and post a link to your blog entry where you publish the results, eh?)
除非您确实需要它，否则我不会使用 ACL，但我认为这不是您的情况。添加额外的代理只是为了验证客户端的身份，这会增加不必要的延迟。其次，使用 NetTcp 不需要辅助角色，只需配置具有 tcp 端点的 Web 角色即可。这将使用 WAS 和 TCP 在 IIS 中托管您的服务。您甚至可以在 azure 中的专用端点中配置 WCF 服务，只有同样托管在 azure 中的 Web 应用程序才能看到，因此不需要身份验证。
I wouldn't use the ACL unless you really need it, which I don't think it's your scenario. Adding an additional broker just for authenticating the clients will add an unnecessary latency. Secondly, you don't need a worker role for using NetTcp, you can just configure a web role with a tcp endpoint. That will host your service in IIS using WAS and TCP. You can even configure the WCF Services in a private endpoint in azure that only the web application also hosted in azure can see, so no authentication is needed.