对于node.js，cpu的密集程度太高了(担心会阻塞事件循环) [英] How cpu intensive is too much for node.js (worried about blocking event loop)

问题描述

我正在与各个社区一起编写节点应用程序，并且在这些社区中，用户可以创建并加入会议室/大厅.我通过游说对象的集合将这些大厅的逻辑写到了节点应用程序本身中.

I am writing a node app with various communities and within those communities users are able to create and join rooms/lobbies. I have written the logic for these lobbies into the node app itself though a collection of lobby objects.

大厅创建后需要进行一些维护.用户可以在大厅内更改各种状态，我还可以使用socket.io定期(大约每2秒一次)为每个大厅打电话，以跟踪某些用户输入的实时".

Lobbies require some maintenance once created. Users can change various statuses within the lobby and I also have calls using socket.io at regular intervals(about every 2 seconds) for each lobby to keep track of some user input "live".

所有任务都不是CPU密集型任务.我预见到的最大潜在威胁是负载分配算法，但它不是实时呼叫"之一，只有在大厅创建者按下按钮时才会激活(它也绝不会执行超过10件事).

None of the tasks are too cpu intensive. The biggest potential threat I foresee is a load distributing algorithm but it is not one of the "live calls" and is only activated upon a button press by the lobby creator (it also is never performed on more than 10 things).

我的担忧是，在生产中，如果服务器在100-200个大厅之间开始变得太接近，我可能会冒着阻塞事件循环的风险.我的担心合理吗?这些操作的潜在数量虽然很小，但是否足够大以至于可以警告将这些代码卸载到单独的可执行文件中，或者涉及各种Franken-Thread javascript库?

My concern arises in that, in production, if the server starts to get close too around 100-200 lobbies I could be risking blocking the event loop. Are my concerns reasonable? Is the potential quantity of these operations, although they are small, large enough to warent offloading this code to a separate executable or getting involved with various franken-thread javascript libs?

TL; DR: 节点应用程序具有运行常规小任务的对象.如果制造了许多这样的对象，我是否应该担心事件循环的阻塞.

TL;DR: node app has object with regular small tasks run. Should I worry about event-loop blocking if many of these objects are made.

推荐答案

无法提前知道您所描述的内容是否会填充"事件循环并占用一个线程所占用的全部时间.如果您想知道"，则必须在使用与预期在生产中使用的硬件相当的硬件的同时，进行仿真和测量.

There is no way to know ahead of time whether what you describe will "fill" up the event loop and take all the time one thread has or not. If you want to "know", you will have to build a simulation and measure while using commensurate hardware with what you expect to use in production.

对于几乎所有的绩效问题，您都必须进行测量，重新测量，然后重新测量才能真正知道或理解您是否有问题，如果存在问题，那么问题的主要根源是什么.

With pretty much all performance questions, you have to measure, measure and measure again to really know or understand whether you have a problem and, if so, what is the main source of the problem.

对于非计算密集型的事情，您的CPU可能可以处理很多活动.但是，如果让很多用户每两秒钟就完成一次事务，那么最终可能会导致出现问题的瓶颈.每2秒200个用户进行一次事务处理意味着每秒100个事务处理，这意味着如果每次事务处理占用了10ms以上的CPU或任何其他序列化资源(例如网卡)，那么您可能会遇到问题.

For non-compute intensive things, your CPU can probably handle a lot of activity. If you get a lot of users all pounding transactions every two seconds though, you could end up with a bottleneck somewhere that causes issues. 200 users with a transaction every 2 seconds means 100 transactions/sec which means if you take more than 10ms of CPU or of any other serialized resource (like perhaps the network card) per transaction, then you may have issues.

关于将一些工作转移到另一个过程，在您确定是否有问题之前，我不会花太多时间担心这一点.如果这样做，那么了解问题的主要原因是非常重要的.简单地将您的node.js进程集群以将多个进程放在同一服务器上可能比将您的核心逻辑分解为多个进程更有意义.这完全取决于问题的主要原因(如果您甚至遇到问题).或者，您可能最终需要多个网卡.或者是其他东西.在测量和理解之前了解还为时过早.

As for offloading some work to another process, I wouldn't spend much time worrying about that until you've measured whether you have an issue or not. If you do, then it will be very important to understand what the main cause of the issue is. It may make more sense to simply cluster your node.js processes to put multiple processes on the same server than it does to break your core logic into multiple processes. It will all depend upon what the main cause of your issue is (if you even have an issue). Or, you may end up needing multiple network cards. Or something else. It's far too early to know before measuring and understanding.

这篇关于对于node.js，cpu的密集程度太高了(担心会阻塞事件循环)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！