如何cpu密集是太多的node.js（担心阻塞事件循环）
我正在与各个社区编写一个节点应用程序，在这些社区中，用户可以创build和join房间/大厅。 我已经将这些大厅的逻辑写入了节点应用程序本身，但通过大厅对象的集合。
大堂一旦创build，需要一些维护。 用户可以改变大厅内的各种状态，而且我还可以定期（大约每2秒）使用socket.io调用每个大厅，以跟踪一些用户input的“实时”。
这些任务都不是太密集的CPU。 我预见到的最大的潜在威胁是负载分配algorithm，但它不是“实时呼叫”之一，仅在大厅创build者按下button时激活（它也不会在超过10件事情上执行）。
我担心的是，在生产中，如果服务器也开始接近100-200大厅，我可能冒着阻塞事件循环的风险。 我的担心是否合理？ 这些操作的潜在数量，尽pipe它们很小，足够大，以将代码卸载到单独的可执行文件中，或者涉及各种frank-thread的JavaScript库吗？
TL; DR：节点应用程序具有运行常规小任务的对象。 我应该担心事件循环阻塞，如果这些对象很多。
事先没有办法知道你描述的是否会“填充”事件循环，并且一直占用一个线程。 如果你想“知道”，你将不得不build立一个模拟和测量，同时使用相应的硬件与你期望在生产中使用。
几乎所有的性能问题，你必须再次测量，测量和测量，以真正了解或了解你是否有问题，如果是的话，这个问题的主要来源是什么。
对于非计算密集型的东西，你的CPU可能会处理很多活动。 如果每两秒钟就有大量用户碰到交易，那么最终可能会导致问题的瓶颈。 200个用户每2秒交易一次意味着100个交易/秒，这意味着如果你每次交易的CPU或者任何其他序列化资源（比如网卡）超过10ms，那么你可能会遇到问题。
至于把一些工作分stream到另一个stream程，我不会花太多时间去担心，直到你衡量你是否有问题。 如果你这样做，那么了解问题的主要原因是非常重要的。 将node.js进程简单地集群化，将多个进程放在同一个服务器上比将核心逻辑分解为多个进程更有意义。 这将取决于你的问题的主要原因是什么（如果你甚至有问题）。 或者，你可能最终需要多个网卡。 或者是其他东西。 在衡量和理解之前知道这些还为时过早。