Websocket 最大并发Socket.IO连接数

这个问题以前有人问过，但最近没有，也没有明确的答案

使用Socket.io，在您需要添加另一台服务器之前，是否有可以维护的最大并发连接数

有人知道有任何活动生产环境大规模使用WebSocket（特别是socket.io）吗？我真的很想知道什么样的设置是最好的最大连接

---

因为WebSocket构建在TCP之上，我的理解是，除非连接之间共享端口，否则您将受到64K端口限制的约束。但我也看到了关于这方面的报道。所以我不知道

这篇文章可能会帮助您：

我想知道同样的问题，所以我最后编写了一个小测试（使用XHR轮询）来查看连接何时开始失败（或落后）。我发现（在我的例子中）套接字在大约1400-1800个并发连接时开始工作

---

这是我做的一个简短的要点，类似于我使用的测试：

这家伙似乎已经成功地在一个Node.js服务器上拥有超过100万个并发连接

---

但我不清楚他到底使用了多少端口。

我尝试在AWS上使用socket.io，我最多可以保持大约600个连接稳定

我发现这是因为socket.io首先使用长轮询，然后升级到websocket

在我将配置设置为仅使用websocket之后，我可以保持大约9000个连接

在客户端设置此配置：

const socket = require('socket.io-client')
const conn = socket(host, { upgrade: false, transports: ['websocket'] })

---

对于+300k并发连接：

在

/etc/sysctl.conf

中设置这些变量：

fs.file-max = 10000000 
fs.nr_open = 10000000

* soft nofile 10000000
* hard nofile 10000000
root soft nofile 10000000
root hard nofile 10000000

另外，在

/etc/security/limits.conf

中更改这些变量：

fs.file-max = 10000000 
fs.nr_open = 10000000

* soft nofile 10000000
* hard nofile 10000000
root soft nofile 10000000
root hard nofile 10000000

最后，在

/etc/sysctl.conf

中增加TCP缓冲区：

net.ipv4.tcp_mem = 786432 1697152 1945728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216

---

有关更多信息，请参阅。

进行配置后，您可以通过在终端上写入此命令进行检查

sysctl -a | grep file

---

大规模使用套接字（特别是socket.io）。那篇文章有多老了？Trello最近每月的活跃用户数刚刚超过100万，所以我可以想象他们现在运行的活跃套接字超过10000个。坐在socket.io之上实现可伸缩性Trello现在显然拥有超过400万用户，但他们肯定在大量服务器上运行，对吗？这让我回到了我最初的问题：他们（或其他人）每台服务器的实际峰值并发用户数是多少？了解他们使用什么样的服务器/容器也很好。他们还在使用自己的叉子，还是回到原点/主控点？我问这个问题的唯一目的是试图评估我的公司（当时）是否有能力为大约120000个并发连接维护Socket.io应用程序。关于端口限制，我想解释一下为什么这不是一个问题。基本上，系统上使用的唯一端口是您正在侦听的端口。为每个连接创建套接字，这些套接字使用文件描述符，但它们不使用您的设备上的端口。请不要在RHEL或CENTOS中使用@MajidJafari answer。由于/etc/sysctl.conf已损坏，您将无法使用sudo。这意味着您将被锁定在EC2实例或PC之外。我必须分离卷，装载一个备份卷作为根卷，并编辑/etc/sysctl.conf和/etc/security/limits.conf。如果您知道自己在做什么，请使用他的答案。我知道这是一个较老的主题，但我在搜索我的答案时首先找到了它，并最终发现这很有用：每个进程的打开文件限制默认为1024个软限制和4096个硬限制，因为每个打开的TCP端口代表一个文件，在确定最大限度地打开库之前，在确定机器有多少个开放的套接字时，考虑这些限制是很重要的。@果酱，你有没有发现为什么你的Web套接字在1400到1800个连接范围内起作用？我有相同的问题，我的文件限制设置为100000，所以我知道这不是问题所在。任何帮助都将不胜感激。谢谢。@seth：我上次查看这个已经有一段时间了，但我认为结论是：XHR轮询占用了太多的资源（相对于其他传输方法）。使用WebSocket时，并发连接的数量更高。@谢谢您的回答。我在使用ws-module（而不是socket.io）时看到了相同的问题，因此不应该对ws-module进行任何XHR轮询。这就是我在故障排除方面遇到的问题。搜索仍在继续。这是一个干净的回答。。根据具体情况也正确。。我个人建议ppl编写自己的基准测试或连接模拟器。虽然对其他人的测试可能是好的，但它并不代表真实世界的环境。。。一旦你有了一个客户端模拟器，它能够处理任何数量的带有各种现实世界故障的客户端。。您可以在主要更改后进行基准测试，也可以在运行时更新模拟器。操作用户聊天界面将不同于监视用户浏览器等。。我发现用Python编写模拟器脚本非常方便……我想不是用socket.io，甚至不是用WebSocket。这家伙似乎在使用长轮询，我想这是较少的资源消耗。你使用EC2吗，哪种类型的实例？t2.micro，t2.nano？当你强制WebSocket时，你注意到响应能力的不同吗？你知道你的实例有多大吗？也正因为如此，将来的任何人都知道一些旧浏览器不支持WebSocket，这就是为什么升级对某些人来说可能很重要。我们如何测试服务器支持多少连接？你是怎么测量的？请建议..这个线程很旧，但是有人知道应该使用哪种EC2实例吗？我正试图找出要选择的实例：50、100、200和300个并发连接。希望有人会回答。你能编辑一下你的答案并简短地解释一下吗