All 15 Event Loop & Non-blocking IO questions
More in Event Loop & Non-blocking IO
How does setImmediate() differ from process.nextTick() in terms of timing and typical use cases? How does the event loop handle a large synchronous loop (like processing a huge array with a for loop), and what problem does this cause? What does it mean that Node.js's I/O is handled by libuv, and how does libuv abstract different operating systems' I/O mechanisms? What is the difference between synchronous and asynchronous versions of the same core Node.js API, using fs.readFile vs fs.readFileSync as an example, and when is the synchronous version actually appropriate? What are the distinct phases of the Node.js event loop, and what kind of callbacks does each phase execute? What is 'event loop lag' (or 'event loop delay'), and how would you monitor it in a production Node.js application? What is the poll phase of the event loop, and under what specific conditions does it block waiting versus move on immediately? What is the difference between how Node.js handles I/O-bound concurrency versus CPU-bound work, and why does this distinction shape Node.js's ideal use cases? How would you use async_hooks (the lower-level predecessor to AsyncLocalStorage) to trace the lifecycle of asynchronous resources in Node.js? How does the V8 JavaScript engine's microtask queue interact with the Node.js event loop's macrotask phases, and why does this occasionally surprise developers?
Advertisement
Back to results for “Performance Optimization & Profiling”
Node.js › Event Loop & Non-blocking IO

How would you measure how 'busy' the event loop is in a running Node.js process using a simple technique?

Intermediate

Answer

A basic technique schedules a callback with a known delay (like setImmediate or a short setTimeout) and measures the actual elapsed time versus the expected delay -- if the event loop is busy processing other work, the callback fires later than scheduled, and that measured difference (the 'lag') serves as a rough real-time indicator of how backed up or blocked the event loop currently is, forming the basis of tools like the 'toobusy' or 'blocked-at' packages.
function measureLoopLag(callback) {
  const start = process.hrtime.bigint();
  setImmediate(() => {
    const lagNs = process.hrtime.bigint() - start;
    callback(Number(lagNs) / 1e6); // lag in milliseconds
  });
}

measureLoopLag((lagMs) => console.log('Event loop lag:', lagMs, 'ms'));
Real-world example A health-check endpoint includes a quick event-loop-lag measurement, returning an unhealthy status if the lag exceeds a threshold, letting a load balancer or orchestrator temporarily route traffic away from an instance that's become overloaded and unresponsive.

Common follow-ups: How does this simple technique compare to the more precise, built-in monitorEventLoopDelay from perf_hooks discussed earlier?;What threshold of lag would reasonably indicate an instance should stop receiving new traffic?

Performance Optimization & Profiling;Debugging & Diagnostics
All 15 Event Loop & Non-blocking IO questions