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