node.js：setInterval() 跳过调用

Question

对于即将到来的 node.js 项目，我需要定期执行各种内务管理任务。 具体来说，有些任务每毫秒执行一次，有些每 20 毫秒执行一次（每秒 50 次），还有一些每秒执行一次。 所以我考虑使用 setInterval()，结果很有趣：很多函数调用都被跳过了。

我使用的基准如下：

var counter = 0;
var seconds = 0;
var short = 1;
setInterval(function() {
        counter ++;
    }, short);
setInterval(function() {
        seconds ++;
        log('Seconds: ' + seconds + ', counter: ' +
             counter + ', missed ' +
             (seconds * 1000 / short - counter));
    }, 1000);

有一个一秒的长计时器和一个可以使用变量short调整的短计时器，在本例中为 1 ms。 我们每一秒都打印短周期中预期的滴答数与短计数器更新的实际次数之间的差值。

以下是短定时器为 1 ms 时的行为：

2012-09-14T23:03:32.780Z Seconds: 1, counter: 869, missed 131
2012-09-14T23:03:33.780Z Seconds: 2, counter: 1803, missed 197
2012-09-14T23:03:34.781Z Seconds: 3, counter: 2736, missed 264
...
2012-09-14T23:03:41.783Z Seconds: 10, counter: 9267, missed 733

许多函数调用被跳过。 这是 10 毫秒：

2012-09-14T23:01:56.363Z Seconds: 1, counter: 93, missed 7
2012-09-14T23:01:57.363Z Seconds: 2, counter: 192, missed 8
2012-09-14T23:01:58.364Z Seconds: 3, counter: 291, missed 9
...
2012-09-14T23:02:05.364Z Seconds: 10, counter: 986, missed 14

更好，但大约每秒跳过一个函数调用。 对于 20 毫秒：

2012-09-14T23:07:18.713Z Seconds: 1, counter: 46, missed 4
2012-09-14T23:07:19.713Z Seconds: 2, counter: 96, missed 4
2012-09-14T23:07:20.712Z Seconds: 3, counter: 146, missed 4
...
2012-09-14T23:07:27.714Z Seconds: 10, counter: 495, missed 5

最后 100 毫秒：

2012-09-14T23:04:25.804Z Seconds: 1, counter: 9, missed 1
2012-09-14T23:04:26.803Z Seconds: 2, counter: 19, missed 1
2012-09-14T23:04:27.804Z Seconds: 3, counter: 29, missed 1
...
2012-09-14T23:04:34.805Z Seconds: 10, counter: 99, missed 1

在这种情况下，它跳过很少的调用（间隔在 33 秒后增加到 2，在 108 秒后增加到 3。

数字有所不同，但在运行之间惊人地一致：运行第一个 1 毫秒基准测试 3 次，在 9267、9259 和 9253 10 秒后产生延迟。

我没有找到这个特定问题的参考。 有很多引用的 Ressig 帖子和许多相关的 JavaScript 问题，但大多数假设代码在浏览器中运行，而不是在 node.js 中运行。

现在问一个可怕的问题：这里发生了什么？ 开个玩笑； 显然函数调用被跳过。 但我看不到这种模式。 我认为长周期可能会阻止短周期，但在 1 毫秒的情况下没有任何意义。 短周期函数调用不会重叠，因为它们只是更新一个变量，即使是 1 毫秒的短周期，node.js 进程也接近 5% 的 CPU。 不过，平均负载很高，约为 0.50。 我不知道为什么一千个调用对我的系统造成如此大的压力，因为 node.js 完美地处理了更多的客户端； setInterval() 确实是 CPU 密集型的（或者我做错了什么）。

一个明显的解决方案是使用更长的计时器对函数调用进行分组，然后多次运行短周期函数调用来模拟更短的计时器。 然后将长周期用作“扫帚马车”，使任何在较低间隔中错过的电话。 示例：设置 20 毫秒和 1000 毫秒的 setInterval() 调用。 对于 1 ms 调用：在 20 ms 回调中调用它们 20 次。 对于 1000 ms 调用：检查 20ms 函数被调用了多少次（例如 47），执行任何剩余的调用（例如 3）。 但是这个方案会有点复杂，因为调用可能会以有趣的方式重叠； 虽然它可能看起来像它，但它也不会是常规的。

真正的问题是：使用 setInterval() 或 node.js 中的其他计时器可以做得更好吗？ 提前致谢。

Answer 1

JavaScript 中的 SetInterval 函数不准确。 您应该尝试使用高分辨率计时器。 在 javascript 中构建准确的计时器

Answer 2

看看这个文档： http : //nodejs.org/api/timers.html#timers_settimeout_callback_delay_arg

重要的是要注意，您的回调可能不会在确切的延迟毫秒内被调用 - Node.js 不保证回调将触发的确切时间，也不保证将触发的顺序。回调将被调用为尽可能接近指定的时间。

这是因为应用程序代码阻塞了事件循环。 所有计时器和 I/O 事件只能在nextTick上处理。

您可以使用以下代码查看此行为：

setInterval(function() {
    console.log(Date.now());
    for (var i = 0; i < 100000000; i++) {
    }
}, 1);

尝试更改迭代次数并查看结果。

理想情况下，如果应用程序滴答持续时间少于 1 毫秒，则将准确触发计时器。 但这在实际应用中是不可行的。

Answer 3

答案恰好是 Vadim 和 zer02 给出的答案的组合，所以我在这里留下了一篇文章。 正如 Vadim 所说，系统无法应对过于频繁的更新，给系统增加一些负载也无济于事。 或者更确切地说，运行时无法应对； 如果需要，系统应该能够每毫秒触发一次回调，但由于某些无法解释的原因，它通常不想要。

解决方案是使用准确的计时器，正如 zer02 评论的那样。 不要被名字误导； 使用的机制与 setTimeout() 相同，但延迟会根据计时器触发之前的剩余时间进行调整。 因此，如果时间结束，那么“准确计时器”将调用立即运行的 setTimeout(callback, 0)。 令人惊讶的是，系统负载比 setInterval() 少：在我非常不科学的样本中，大约是 CPU 的 2% 而不是 5%。

这个简单的函数可能会派上用场：

/**
 * A high resolution timer.
 */
function timer(delay, callback)
{
    // self-reference
    var self = this;

    // attributes
    var counter = 0;
    self.running = true;
    var start = new Date().getTime();

    /**
     * Delayed running of the callback.
     */
    function delayed()
    {
        callback(delay);
        counter ++;
        var diff = (new Date().getTime() - start) - counter * delay;
        if (!self.running) return;
        setTimeout(delayed, delay - diff);
    }

    // start timer
    delayed();
    setTimeout(delayed, delay);
}

要使用，只需调用new timer(delay, callback); . （是的，我颠倒了参数的顺序，因为首先进行回调非常烦人。）要停止它，请设置timer.running = false 。

最后一个注意事项：setTimeout(callback, delay) 没有像我担心的那样使用递归（例如：等待一段时间，然后调用回调），它只是将回调放在一个队列中，该队列将在轮到运行时调用来，在全球范围内。

Answer 4

我禁用调试器并再次尝试。它对我来说很好用