我有一个现有的服务器应用程序,可以跟踪网络上的各种计算机。有时,网络最多可以有6000台需要跟踪的计算机。跟踪只需知道计算机已启动。有时,服务器会将消息发送回客户端,需要进行处理和处理。
我已经尝试过WCF,但它似乎没有非常优雅地处理大量负载(当接近1200-2000范围的客户端时,高CPU使用率很常见);另外,使用WCF我必须使它成为一种“拉”机制,而不是“推送”来向客户端发送消息(即,客户端要求服务器提供消息)。我正在考虑切换到低级TCP套接字通信,但我不确定会发生什么,这就是这个问题的关键所在。
所以:
1 - 我可以期望有多少客户端能够连接并保持与我的服务器的连接? 2 - 假设此连接主要用于让服务器知道客户端是否仍在线,并且从服务器发送非常偶然的消息,我可能会看到很多资源使用(就CPU / RAM / tcp而言)服务器上的端口/等)?
谢谢
答案 0 :(得分:2)
1 - 我可以期望有多少客户端能够连接并保持与我的服务器的连接?
5000应该不是任何问题。
2 - 假设此连接主要用于让服务器知道客户端是否仍在线,并且从服务器发送非常偶然的消息,我可能会看到很多资源使用(就CPU /而言) RAM / tcp ports / etc)在服务器上?
定义"多"。打开的TCP连接占用资源。但最大的资源是您在byte[]
中使用的BeginReceive
缓冲区。但是我们假设它的32768字节很大。这总共约163Mb。记忆很便宜,不是吗?
至于CPU使用情况,没有。空闲连接不使用任何CPU。
答案 1 :(得分:0)
看看this bytes.com question关于听起来像类似情况的理论最大连接数。
似乎最相关的回应是:
The magic setting you're looking for is "MaxUserPort". You can google this,
then make the appropriate registry change.
The value is typically set at 5000, and if you want lots and lots of client
connections then you need to bump the value up.
如果它与您的设计完美融合,那么您可能会在本地LAN环境中使用UDP over TCP。我没有亲自在C#中对此进行任何基准测试,但是已成功支持C ++中的10,000多个UDP客户端,几乎没有问题(还有一个巨大的盒子)。
答案 2 :(得分:0)
你真的需要保持这么多连接吗?
这不是因为您需要保持“跟踪”需要持久连接的工作站。您可以让客户端按照您的建议连接并轮询间隔时间。在架构上与HTTP有一些相似之处。这样,Web服务器甚至可能满足您的服务器需求:所有轮询的客户端都可以被视为 up ,并且您的服务器可能有话要说,或者可能没有。只要你尽可能地保持连接打开,这并不重要。使用这种方法结合轻松的轮询时间很可能很容易覆盖一台服务器“跟踪”的上述6000工作站。
另一个选择可能是考虑消息传递基础架构。服务器将命令发送到命令队列,并且接收命令的客户端通过响应队列进行响应。
我认为UDP可以被认为是实现后者的可能方式。但你必须做更多的工作......