WCF可伸缩性与会话

我们正在评估一个新的项目，它将有一个。net服务器，可以在互联网上使用。我们可以访问服务器，但托管是由第三方公司完成的。

我们正在。net服务器上使用WCF进行评估。(我没有WCF的专业经验，只是阅读这个主题)。WCF服务将与SQL Server对话以执行其职责。

场景如下:

运行我们自己的ActionScript软件的多个客户端机器将连接到。net服务器。

• 客户端可能是24/7在线，应该定期轮询我们的服务器，告诉服务器他们在那里。
• 客户端需要能够登录，只有在登录成功的情况下，其他调用才会被允许，并且在某个时候它会注销。所以我们需要"记住"特定客户端的状态…
• 最高预期负载约为1000个客户端，其中500个只进行轮询，而其他500个将"活动"。"活动"意味着每分钟最多1个调用，每个调用中没有沉重的负载，无论是在请求中还是在响应中，每个调用只有1-3个数据库访问。

我们已经测试了一些"HelloWorld"与ActionScript和WCF使用BasicHttp(s)绑定。但是因为我们需要会话处理，所以我们考虑使用wsHttpBinding绑定，因为它可以为我们提供WCF会话。到目前为止一切顺利，但后来我偶然发现它应该然而:

我发现在我的Oreilly WCF服务第三版书(第177页)中是这样写的

甚至微软都在写要小心使用

http://msdn.microsoft.com/en-us/magazine/cc163590.aspx

"由于与每个此类专用服务实例相关的成本，为私有会话配置的服务通常不能支持超过几十个(或最多几百个)未完成的客户端。"

因此，因为我们需要识别每个客户端的状态，我们当然可以在无状态的HttpBindingBinding之上实现我们自己的"会话处理"，并在每次调用我的WCF方法时调用SessionHandling类，但我不愿意这样做，在我看来，成千上万的人应该已经面临同样的问题。

所以，我现在的问题是:您认为服务器上的wsHttpBinding可以处理有效负载吗?在WCF上使用wsHttpBinding到底有多"糟糕"?有人已经有过这方面的经验吗?我可以用它吗?你会用什么?

最后的话:我不局限于WCF如果我们不喜欢它，我们应该做一个评估。

从公司的角度来看，通过TCP和ActionScript客户端实现protobuf-RPC或XML-RPC解决方案也很好。(例子!)所以不需要在服务器上的IIS中托管WCF，只要编码部分对双方的程序员来说是舒适的(足够的)，并且部署服务器上的管理也不是太多。我有点担心，仅仅做一些基于tcp端口的通信对防火墙和其他东西的管理意味着什么。有效负载不是问题，客户端处理能力也不是问题。我唯一关心的是服务器的可伸缩性和安全性。

提前感谢您的任何建议!