每台服务器的套接字连接的实际/硬限制是多少
我有许多客户端设备打开由 Windows 2008 R2 服务器上运行的服务公开的套接字连接。我想知道并发客户端连接数的硬限制是什么。
I have a number of client devices that open socket connection exposed by a service running on a Windows 2008 R2 server. I'm wondering if what is hard limit on the number of concurrent client connections.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据这篇文章，一个硬限制是（曾经）16,777,214。实际限制还取决于您的应用程序：例如，如果您为每个连接创建一个线程，则实际限制来自线程数量的限制，而不是来自网络堆栈的限制。任何进程可能拥有的句柄数量也有限制，等等。
According to this article, one hard limit is (was) 16,777,214. The practical limit depends on your application also: for example, if you create a thread per connection, then the practical limit comes from the limitation in the number of threads more than from the network stack. There is also a limit on the number of handles any process may have, and so on.
假设您为服务器选择了合理的架构，那么限制将与内存和 CPU 相关。恕我直言，你永远不会达到马丁提到的硬限制:)
因此，与其担心你永远不会达到的理论限制，恕我直言，你应该考虑如何设计你的应用程序以及如何测试它确定在给定硬件上您的应用程序可以维持的当前最大客户端连接数。对我来说重要的是从第 0 天开始运行性能测试（请参阅 此处查看我解释这一点的博客文章）。现代操作系统和硬件允许您构建高度可扩展的系统，但简单的日常编码和设计错误很容易浪费可扩展性，因此您必须始终运行性能测试，以便您知道何时为您的系统构建障碍。表现。您根本无法在项目结束时返回并修复此类错误。
顺便说一句，我使用低规格 VM 在 Windows 2003 Server 上运行了一些测试，并使用基于重叠 I/O（I/O 完成端口）设计的简单服务器轻松实现了超过 70,000 个并发和活动连接。有关更多详细信息，请参阅此答案。
我个人的方法是使用您决定的任何技术快速组合服务器的外壳（我喜欢使用 I/O 完成端口和最少线程的非托管 C++），请参阅 此博客文章了解更多详细信息。然后构建一个客户端或一系列客户端，可以对应用程序进行压力测试，并在实现服务器逻辑时不断更新和运行测试客户端。随着服务器的复杂性增加，您可能会看到最大并发客户端的曲线逐渐下降；可扩展性的大幅下降应该会导致您检查最新的检查以查找不幸的设计决策。
Assuming you select a sensible architecture for your server then the limit will be memory and cpu related. IMHO you'll never reach the hard limit that Martin mentions :)
So, rather than worrying about a theoretical limit that you'll never hit you should, IMHO, be thinking about how you will design your application and how you will test it to determine the current maximum number of client connections that you can maintain for your application on given hardware. The important thing for me is to run your perf tests from Day 0 (see here for a blog posting where I explain this). Modern operating systems and hardware allow you to build very scalable systems but simple day to day coding and design mistakes can easily squander that scalability and so you simply MUST run perf tests all the time so that you know when you are building in road blocks to your performance. You simply cannot go back and fix these kind of mistakes at the end of the project.
As an aside, I ran some tests on Windows 2003 Server with a low spec VM and easily achieved more than 70,000 concurrent and active connections with a simple server based on an overlapped I/O (I/O completion port) based design. See this answer for more details.
My personal approach would be to get a shell of a server put together quickly using whatever technology you decide on (I favour unmanaged C++ using I/O Completion Ports and minimal threads), see this blog posting for more details. Then build a client or series of clients that can stress test the application and keep updating and running the test clients as you implement your server logic. You would expect to see a gradually declining curve of maximum concurrent clients as you add more complexity to your server; large drops in scalability should cause you to examine the latest check ins to look for unfortunate design decisions.