我正在编写socket.io-client node.js bot app，以便测试我的基于socket.io的服务器应用程序的性能也在节点下运行。
通常服务器运行ubuntu linux但我也在我的本地开发机器上安装和配置了相同的服务器应用程序（node.js，nginx，socket.io）。
如果我启动我的机器人 - ＆＃34;脚本＆＃34;并启动200个机器人创建与服务器的单独连接我没有任何问题，如果我这样做真正的服务器，Linux服务器。
但是，如果我连接到我的本地操作系统基于＆＃34;服务器＆＃34;我无法真正克服~120个连接。
我得到断开连接，过时的套接字以及无限循环的断开/重新连接，这在socket.io的标准设置下只需要更长的时间来完成（延迟重新连接尝试）。
在这样的测试中，我的本地开发机器的负载几乎为0％，因此它与内存或处理器无关。
我已尝试从第二台本地计算机使用相同的bot脚本，以确保该问题与运行在与服务器相同的计算机上的机器人无关。但我得到同样的问题。
只要我将机器人脚本指向真实的服务器，我就没有任何问题。
当我处于问题发生的范围内时，即推送超过120个客户端时，我尝试使用浏览器（真实用户场景）访问我的本地开发服务器并刷新多次。有时我会得到一个内部服务器500＆＃34;。
让我觉得这可能不是与nginx有关的socket.io吗？或者常规os x（非服务器）机器上的其他一些基本套接字限制？
答案 0 :(得分：3)
在发布此问题之前我所做的所有谷歌搜索..... 这样做了3分钟后我偶然发现了答案：
写在终端：
sysctl -a | grep somax
我得到了答案：
kern.ipc.somaxconn: 128
所以我觉得情况非常接近。
只需在终端写一下：
sudo sysctl -w kern.ipc.somaxconn=xyz
其中xyz是允许的连接数。
在这里找到答案： http://b.oldhu.com/2012/07/19/increase-tcp-max-connections-on-mac-os-x/
答案 1 :(得分：0)
somaxconn值128似乎是一个可以接受的解决方案。但在我的情况下，改变这个价值并没有做到。
这篇文章解释了解决方案。 http://docs.basho.com/riak/latest/ops/tuning/open-files-limit/#Mac-OS-X
问题是最大过程限制和最大打开文件限制。 人们可以通过写作来查看这些限制 ulimit -u（打开文档） ulimit -n（max procc）
更改它们的运行时对我来说效果不好，但上面的链接解释了如何为许多流行的操作系统永久更改这些值。
在我做出这个改变之后，我没有遇到超出之前限制的问题，我的kern.ipc.somaxconn：仍然是128 ..