Do Not Thrash the Node.js Event Loop
summary
Node.js apps self‑DoS when synchronous work blocks the event loop, forcing huge overprovisioning. Concrete fixes: measure with the eventLoopUtilization API (or a timer drift probe), reject excess traffic by return 503 when utilization > ~80–98% or event‑loop delay > ~200ms, or serve a cached empty HTML for busy React SSR. Examples: 20ms blocking limits to ~50 RPS, React SSR often costs 50–100ms, and a demo with 10s sync work falls to near zero without protection; these mitigations keep throughput and reduce timeouts.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:07Node.js event loop basics
- 5:00Synchronous blocking impact
- 8:38Event loop saturation
- 11:50Scaling CPU limits
- 13:19Measuring event loop health
- 15:28Event loop utilization API
- 17:40Fastify plugin protection
- 19:54Live demo setup
- 21:40Stress testing 50 connections
- 22:45Server collapse under load
- 23:27Event loop monitoring
- 24:55Traffic shaping resilience
- 26:38Worker threads offloading
- 27:40Request deduplication
- 29:26Platformatic solutions
- 29:49Q&A
related talks
22mScaling Node.js and unblocking the Event Loop
20mAfter Years of Node in Production, We Still Block the Event Loop
29mThis DoS goes loop-di-loop – preventing DoS attacks in your Node.js application
27mDon't block the event loop!JavaScript Async for Effortless UX
21mDon't write spaghetti code in server side JavaScript
34mBroken Promises
34mOptimizing Performance in Large-Scale React & Node.js Applications
39mYou Don’t Node.js