對於node.js，cpu的密集程度太高了（擔心阻塞事件循環）

Question

我正在與各種社區一起編寫節點應用程序，在這些社區中，用戶可以創建並加入房間/大廳。 我已經通過游說對象的集合將這些大廳的邏輯寫入了節點應用程序本身。

大廳創建后需要進行一些維護。 用戶可以在大廳內更改各種狀態，我還可以使用socket.io以固定間隔（大約每2秒一次）為每個大廳打電話，以跟蹤某些用戶輸入的“實時”。

這些任務都不會占用太多CPU。 我預見到的最大潛在威脅是負載分配算法，但它不是“實時呼叫”之一，僅在游說者創建者按下按鈕時才會激活（也絕不會執行超過10件事）。

我擔心的是，在生產中，如果服務器在100-200個大廳附近開始變得太接近，我可能會冒阻塞事件循環的風險。 我的擔心合理嗎？ 這些操作的潛在數量（盡管很小）是否足夠大，可以警告將這些代碼分流到單獨的可執行文件中，或者涉及各種Franken-Thread javascript庫？

TL; DR：節點應用具有運行常規小任務的對象。 如果創建了許多這些對象，我是否應該擔心事件循環阻塞。

Answer 1

無法提前知道您所描述的內容是否會“填滿”事件循環並占用一個線程所有的時間。 如果您想“知道”，則必須在使用與預期在生產中使用的硬件相當的硬件的同時進行仿真和測量。

對於幾乎所有的性能問題，您都必須重新測量，重新測量，才能真正知道或理解您是否有問題，如果存在問題，那么問題的主要根源是什么。

對於非計算密集型的事情，您的CPU可能可以處理很多活動。 但是，如果讓很多用戶每兩秒鍾就完成一次事務，那么最終可能會導致出現問題的瓶頸。 每2秒有200個用戶進行事務處理，這意味着每秒100個事務處理，這意味着如果每個事務處理占用了10ms以上的CPU或任何其他序列化資源（例如網卡），那么您可能會遇到問題。

至於將一些工作轉移到另一個流程，在您確定是否有問題之前，我不會花太多時間擔心這一點。 如果這樣做，那么了解問題的主要原因是非常重要的。 簡單地將您的node.js進程集群以將多個進程放在同一服務器上可能比將您的核心邏輯分解為多個進程更有意義。 這完全取決於問題的主要原因（如果您甚至遇到問題）。 或者，您可能最終需要多個網卡。 或者是其他東西。 在進行測量和理解之前了解還為時過早。