javascript - 在性能问题之前有多少个并发 setTimeouts？

Question

我有一个 node.js 应用程序，在任何给定时间运行 10k-100k 并发 setTimeouts。 (它们都是 5 分钟的持续时间。)回调非常简单，只是 redis 中的一个 HDECRBY。我还没有遇到任何性能问题，即使是在 t2.micro 实例上也是如此。

我知道如果回调函数不能像我设置 setTimeouts 那样快地执行(很明显)，我会遇到问题，但是有大量的 setTimeouts 本身就存在问题， ?例如，如果我将其扩展到 100 万并发，我是否会遇到 RAM 瓶颈？一千万？

Answer 1

对于这些类型的问题，在 source code 中查看 node.js 如何处理计时器通常很有用。 .

您会发现，node.js 保留了一个或多个其内部计时器对象的链表，并且所有设置为同时发生的计时器共享一个 libuv 计时器。这意味着数以亿计的定时器都设置为在一个相当特定的时间窗口内发生，将不可避免地共享许多触发时间，因此将共享定时器列表，从而将共享许多系统定时器对象。

这使得拥有无数个计时器对象不再是个问题。现在，每个计时器对象仍然需要一些内存，并且不是计时器实现中的每个操作都是常量时间，尽管您可以在下面的评论中看到，他们试图让尽可能多的操作成为常量时间以允许大量计时器性能仍然不错。

如果您不需要绝对精确地确定计时器何时触发，您可以通过仅针对特定时间边界(例如 100 毫秒的偶数)安排计时器来使您的计时器更频繁地合并和共享计时器对象。这将在相同的触发时间安排更多的无数计时器，并允许 node.js 将更多计时器放入同一个列表中，所有这些计时器都共享一个系统计时器。我不知道这对你的计时器是否可行，或者是否需要，但在研究 node.js 的工作原理时，它会提高效率。 node.js 内部的计时器列表和 libuv 中的系统计时器都会更少。

---

以下是 node.js 代码中有关计时器的一些解释性注释，解释了设计的更多方面:

// HOW and WHY the timers implementation works the way it does.
//
// Timers are crucial to Node.js. Internally, any TCP I/O connection creates a
// timer so that we can time out of connections. Additionally, many user
// user libraries and applications also use timers. As such there may be a
// significantly large amount of timeouts scheduled at any given time.
// Therefore, it is very important that the timers implementation is performant
// and efficient.
//
// Note: It is suggested you first read though the lib/internal/linkedlist.js
// linked list implementation, since timers depend on it extensively. It can be
// somewhat counter-intuitive at first, as it is not actually a class. Instead,
// it is a set of helpers that operate on an existing object.
//
// In order to be as performant as possible, the architecture and data
// structures are designed so that they are optimized to handle the following
// use cases as efficiently as possible:

// - Adding a new timer. (insert)
// - Removing an existing timer. (remove)
// - Handling a timer timing out. (timeout)
//
// Whenever possible, the implementation tries to make the complexity of these
// operations as close to constant-time as possible.
// (So that performance is not impacted by the number of scheduled timers.)
//
// Object maps are kept which contain linked lists keyed by their duration in
// milliseconds.
// The linked lists within also have some meta-properties, one of which is a
// TimerWrap C++ handle, which makes the call after the duration to process the
// list it is attached to.
//
//
// ╔════ > Object Map
// ║
// ╠══
// ║ refedLists: { '40': { }, '320': { etc } } (keys of millisecond duration)
// ╚══          ┌─────────┘
//              │
// ╔══          │
// ║ TimersList { _idleNext: { }, _idlePrev: (self), _timer: (TimerWrap) }
// ║         ┌────────────────┘
// ║    ╔══  │                              ^
// ║    ║    { _idleNext: { },  _idlePrev: { }, _onTimeout: (callback) }
// ║    ║      ┌───────────┘
// ║    ║      │                                  ^
// ║    ║      { _idleNext: { etc },  _idlePrev: { }, _onTimeout: (callback) }
// ╠══  ╠══
// ║    ║
// ║    ╚════ >  Actual JavaScript timeouts
// ║
// ╚════ > Linked List
//
//
// With this, virtually constant-time insertion (append), removal, and timeout
// is possible in the JavaScript layer. Any one list of timers is able to be
// sorted by just appending to it because all timers within share the same
// duration. Therefore, any timer added later will always have been scheduled to
// timeout later, thus only needing to be appended.
// Removal from an object-property linked list is also virtually constant-time
// as can be seen in the lib/internal/linkedlist.js implementation.
// Timeouts only need to process any timers due to currently timeout, which will
// always be at the beginning of the list for reasons stated above. Any timers
// after the first one encountered that does not yet need to timeout will also
// always be due to timeout at a later time.
//
// Less-than constant time operations are thus contained in two places:
// TimerWrap's backing libuv timers implementation (a performant heap-based
// queue), and the object map lookup of a specific list by the duration of
// timers within (or creation of a new list).
// However, these operations combined have shown to be trivial in comparison to
// other alternative timers architectures.


// Object maps containing linked lists of timers, keyed and sorted by their
// duration in milliseconds.
//
// The difference between these two objects is that the former contains timers
// that will keep the process open if they are the only thing left, while the
// latter will not.