我正在编写一个包含各种社区的 Node 应用程序，在这些社区中，用户能够创建和加入房间/大厅。我已通过大厅对象集合将这些大厅的逻辑写入 Node 应用程序本身。
大厅一旦创建就需要一些维护。用户可以在大厅内更改各种状态，我还使用 socket.io 定期(大约每 2 秒)为每个大厅进行调用，以“实时”跟踪一些用户输入。
所有任务都不是 CPU 密集型的。我预见到的最大潜在威胁是负载分配算法，但它不是“实时调用”之一，并且仅在大厅创建者按下按钮时激活(它也不会在超过 10 件事上执行)。
我担心的是，在生产中，如果服务器开始接近 100-200 个大厅，我可能会冒着阻塞事件循环的风险。我的担忧合理吗？这些操作的潜在数量，尽管它们很小，但足够大，足以避免将此代码卸载到单独的可执行文件或涉及各种 franken-thread javascript 库吗？
TL;DR: Node 应用程序具有运行常规小任务的对象。如果制作了许多这样的对象，我是否应该担心事件循环阻塞。
最佳答案
无法提前知道您所描述的内容是否会“填满”事件循环并占用一个线程的所有时间。如果您想“知道”，则必须构建模拟和测量，同时使用与您期望在生产中使用的硬件相称的硬件。
对于几乎所有的性能问题，您都必须测量、测量和再次测量，才能真正知道或理解您是否有问题，如果有，问题的主要根源是什么。
对于非计算密集型事物，您的 CPU 可能可以处理大量事件。但是，如果你让很多用户每两秒都在处理交易，你最终可能会在某个地方遇到导致问题的瓶颈。 200 个用户每 2 秒处理一个事务意味着 100 个事务/秒，这意味着如果每个事务占用超过 10 毫秒的 CPU 或任何其他序列化资源(比如网卡)，那么您可能会遇到问题。
至于将一些工作卸载到另一个进程，在您衡量是否存在问题之前，我不会花太多时间担心这个问题。如果这样做，那么了解问题的主要原因是什么将非常重要。简单地集群 node.js 进程以将多个进程放在同一台服务器上可能比将核心逻辑分解为多个进程更有意义。这完全取决于问题的主要原因是什么(如果您有问题的话)。或者，您可能最终需要多个网卡。或者是其他东西。在测量和理解之前就知道还为时过早。
关于javascript - cpu 密集程度对于 node.js 来说太多了(担心阻塞事件循环)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32038756/