我一直在构建一个实时通知系统。它是 Web 应用程序的一部分，但必须在事件发生后立即查看。长轮询不是一种选择，因为当没有可用事件时，Web 服务器保持连接的成本会很高，所以我不得不进行短期轮询。
每个客户端每 2 秒访问一次 Web 服务器(这是一个相当高的频率)。当事件可用时，它们会作为 JSON 发送到 JavaScript 客户端。现在，这需要一个服务器设置来处理大量的短期连接。我已经使用 Yaws Web 服务器实现了一个这样的系统。然而，因为 Yaws 启动了相当多的许多其他服务，当连接超过 30,000 时，感觉很重，连接开始被拒绝或中止(可能是因为我在 Yaws 运行的同一个 Erlang VM 中运行一些 ETS 表分离这些可能需要 rpc:call/4 ，我担心这会增加延迟])。我知道有一些特定于操作系统的调整要做，而且这些调整已经完成。
如果可以轻松地将多个 Yaws 实例聚集在一起，这将不是问题。在 Yaws 中，我使用了一些 appmod，并且我正在以 REST 方式做事。我在想 Cowboy Web 服务器可能会在这里增强一些东西。我之前没有用过 Cowboy，但我用过 Misultin。看看 Cowboy，它是一个成熟的 OTP 应用程序，它似乎很容易集群，而且重量轻，可能会增加整个系统可以处理的客户端数量。存储在 Mnesia 上，我可以轻松分发它以添加更多节点(可能通过复制)，这样每个 Mnesia 实例前面都有一个 Cowboy 实例。
我的问题是:
Appmods 和 #arg{} 记录有一个干净的 API。 Cowboy 有这两个东西的等价物吗(请举例说明)？ Cowboy 可以处理文件上传吗？如果是这样，您认为在频繁上传文件的情况下使用哪个服务器(Yaws 或 Cowboy)会更好？说明如何使用 Cowboy 完成文件上传。 yaws.conf 参数 max_connections = nolimit 时，我将如何在 Cowboy 中指定相同的参数？ 现在，我关注了 interview with Cowboy author，他讨论了为什么 Cowboy 比 Yaws 更轻巧的原因。他说
那是因为 Cowboy 使用监听器池库 Ranch ，它以某种方式结束了处理更多连接的更高能力，加上使用二进制文件而不是列表。
同一次采访中的另一句话:
我想知道 yaws 如何处理这种情况。不知何故，我的问题域需要轻量级的 HTTP 处理。实际上，与 Mochiweb、Misultin 或 Cowboy 相比，Yaws 会导致更多的内存消耗。我最担心的是 Yaws 拥有最好/最干净的 API，它使我们能够访问
#arg{}，其中包含我们作为 Erlang 记录所需的一切，这样我们就可以自己将它们取出来，而不是其他具有许多用于提取外部内容的函数的 API。甚至文档:Yaws 文档都非常好且简单明了。也许我需要查看更多 Cowboy 代码，例如文件上传和简单的 GET 和 POST 请求处理。否则，我之前提出的问题仍然是紧迫的问题。 Yaws 相当不错，但对于这种快速、轻量级、短暂的高利率民意调查情况似乎有些矫枉过正，你怎么看？
最佳答案
您的 30000 拒绝限制听起来很像某个地方的 32k 限制。要么是默认进程数，即 32k，要么是对文件描述符等的一些系统限制。您不应该排除限制在内核方面的可能性。我已经看到系统很容易达到极限，因为内核配置确实很难处理。
关于http - Web 服务器对高客户端轮询率的容忍度 : Cowboy vs. Yaws Web 服务器，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/12892777/