11

对于即将使用 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 毫秒。每一秒，我们都会打印短周期中预期的滴答数与短计数器更新的实际次数之间的差异。

以下是短计时器为 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。

这些数字各不相同，但在运行之间却惊人地一致：在 9267、9259 和 9253 的 10 秒后运行 3 次前 1 毫秒基准测试会产生延迟。

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

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

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

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

4

4 回答 4

12

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

于 2012-09-15T00:19:55.617 回答
8

看看这个文档：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 毫秒，计时器将准确触发。但这在实际应用中是不可行的。

于 2012-09-14T23:59:30.353 回答
2

答案恰好是 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) 不像我担心的那样使用递归（例如：等待一段时间，然后调用回调），它只是将回调放在一个队列中，运行时轮到它时将调用该队列来，在全球范围内。

于 2012-09-17T21:29:57.997 回答
0

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

于 2020-12-21T14:34:49.467 回答