在性能问题之前有多少并发 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 计时器。这意味着无数个定时器都设置在一个相当特定的时间窗口内，将不可避免地共享许多触发时间，因此将共享定时器列表，从而共享许多系统定时器对象。

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

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

---

这里有一些来自计时器的 node.js 代码的解释性 cmets，它解释了设计的更多方面：

// 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.