套接字方法的瓶颈？答案

【问题标题】：Bottleneck with sockets approach?套接字方法的瓶颈？
【发布时间】：2013-03-10 06:59:33
【问题描述】：

考虑创建一个用户可以协作的实时应用。发现 node.js + socket.io 是此类问题的解决方案之一。

我从其他开发人员那里听说，就我的服务器向用户提供的套接字数量而言，将会存在瓶颈。因此，如果我有数百个用户同时协作，则打开的套接字数量将用完，用户将无法连接。这是一个有效的担忧吗？

更新： 关于某种相关说明，我希望使用 SockJS 而不是 Socket.io。这些库中有一个thread that explains pros and cons。还有this is a good read。

【问题讨论】：

JS 并不是最快的语言。如果您发现自己对 JS 感到窒息，那么使用 C++ 解决方案可以轻松地将您的吞吐量翻两番。问题不在于您拥有多少个套接字，而在于您是否能够及时处理它们。
进程允许打开的文件描述符（包括套接字）的数量在所有（大多数？）UNIX类型的操作系统上都是可配置的，通常使用ulimit（在shell中）或@987654324 @（系统范围内，仍然需要ulimit）。

【解决方案1】：

已经有solutions using this approach like Cloud9 并且效果很好。将有一个点，您将需要向外扩展。因此，如果您正在计划一些大事，我会考虑一下。

Here are some tests on sockets.io 具有 10,000 个并发连接。看起来这是一个很好的解决方案，但由于回退机制，这并不容易。

【讨论】：

【解决方案2】：

对于数百名用户来说，我认为这不是问题。

众所周知，Sockets 在客户端和服务器之间具有持久连接，并且双方可以随时开始发送数据。保持它们打开并不是一个问题，就像处理每秒发送的消息的负载一样。

Socket.io 可以轻松处理 1000 个并发连接。但如果每秒发送超过 8-10k 条消息，它将失败。在您的套接字耗尽之前，您将遇到负载障碍。在大多数情况下，处理更多并发用户会转化为更高的负载。所以不用担心套接字会变低。试图超越这个障碍需要更多的服务器资源。

有用的链接：

【讨论】：