许多 setTimeouts 的结果

the consequence of MANY setTimeouts

我正在构建一个页面,用户可以在其中生成自定义计时器。这些计时器通过 setTimeout 在 heroku nodejs 后端 运行。然而,我有点担心可能同时有数千个长时间的 setTimeouts 运行ning。

我发现了 this SO 问题,其中指出 javascript 计时器在浏览器的单独线程上 运行。 nodejs也是这样吗?如果是这样,这个线程上有数千个计时器的后果是什么?

编辑:关于我正在尝试做的事情的更多信息。我正在构建一个可以放在屏幕上的同步页面,然后用户可以在浏览器中访问该页面并更改其实例上的内容。这将反映在页面的所有打开实例中。用户还应该能够设置定时器,它应该在定时器结束时推送新内容。这就是我正在考虑使用服务器端 setTimeouts 来做的事情。我知道我可能应该使用 heroku 调度程序插件之一,但我想降低成本(这种页面并不完全是赚钱机器)。最后,用户应该能够使用新的 url 等生成他们自己的此页面实例。这就是可伸缩性问题发挥作用的地方。如果该页面存在100个实例,并且每个实例都设置了10个定时器,即后端有1000个定时器。

根据评论中mscdex的解释:

The source code for timers.js is pretty easy to follow, but basically what happens is that all calls to both setTimeout() and setInterval() with the same expiration/interval are grouped together and use the same backing timer. These setTimeout()/setInterval() requests are appended to a list tied to that timer in the order they're added so that every time the timer fires, it iterates the list (executing callbacks) until it reaches a timeout that hasn't expired yet. At that point it waits the delta between the current time and the next timeout in that group. I hope that made sense.

我得出的结论是,设置多个 setTimeout 并不会对性能产生不利影响,因为它们实际上都是一个计时器。只是回答我自己,因为没有其他人回答。