How many events can Node.js queue?

Question

From what I see, if an event in Node take a "long time" to be dispatched, Node creates some kind of "queue of events", and they are triggered as soon as possible, one by one.

How long can this queue be?

Answer 1

While this may seem like a simple question, it is actually a rather complex problem; unfortunately, there's no simple number that anyone can give you.

First: wall time doesn't really play a part in anything here. All events are dispatched in the same fashion, whether or not things are taking "a long time." In other words, all events pass through a "queue."

Second: there is no single queue. There are many places where different kinds of events can be dispatched into JS. (The following assumes you know what a tick is.)

• There are the things you (or the libraries you use) pass to process.nextTick(). They are called at the end of the current tick until the nextTick queue is empty.
• There are the things you (or the libraries you use) pass to setImmediate(). They are called at the start of the next tick. (This means that nextTick tasks can add things to the current tick indefinitely, preventing other operations from happening whereas setImmediate tasks can only add things to the queue for the next tick.)
• I/O events are handled by libuv via epoll/kqueue/IOCP on Linux/Mac/Windows respectively. When the OS notifies libuv that I/O has happened, it in turn invokes the appropriate handler in JS. A given tick of the event loop may process zero or more I/O events; if a tick takes a long time, I/O events will queue in an operating system queue.
• Signals sent by the OS.
• Native code (C/C++) executed on a separate thread may invoke JS functions. This is usually accomplished through the libuv work queue.

Since there are many places where work may be queued, it is not easy to answer "how many items are currently queued", much less what the absolute limit of those queues are. Essentially, the hard limit for the size of your task queues is available RAM.

In practice, your app will:

• Hit V8 heap constraints
• For I/O, max out the number of allowable open file descriptors.

...well before the size of any queue becomes problematic.

If you're just interested in whether or not your app under heavy load, toobusy may be of interest -- it times each tick of the event loop to determine whether or not your app is spending an unusual amount of time processing each tick (which may indicate that your task queues are very large).

Answer 2

Handlers for a specific event are called synchronously (in the order they were added) as soon as the event is emitted, they are not delayed at all.

The total number of event handlers is limited only by v8 and/or the amount of available RAM.