This presentation provides a deep dive into the Node.js event loop, which is a key part of how Node.js handles asynchronous I/O. The presentation is written in a clear and concise style, and it is packed with helpful diagrams.
It is an essential resource for anyone who wants to understand how the Node.js event loop works and how to use it effectively.
2. AGENDA
● What is the event loop?
● Is Node.js single or multi-threaded? (or when?)
● Why Node.js scale well?
● Traditional Web Applications
● What is Node.js?
● Node.js Architecture
● Node.js Runtime
● Event Loop
● What is Libuv?
● Libuv Architecture
● When to use Node.js?
● Companies Using Node in Production
● Conclusion
5. ● Thread-based networking ( concurrency model, in which OS threads are employed)
● Drops connections when threads limit is reached.
● Threads limit is reached because threads are waiting/blocked for I/O.
● Thread context switching is not free.
● High Memory consumption per request (Thread takes more memory than just creating a new
tcp connection).
● Difficult to Manage concurrency.
● Dead lock
TRADITIONAL WEB APPLICATIONS
11. ● Node.js offloads the I/O call to libuv/linux Kernel
● Can handle more connections (High Throughput)
● Single Threaded (No Context switching overhead)
● CPU can be used well (As context switching is less)
● Low Memory consumption
● Easy to Manage concurrency
● No Threads, No Dead lock.
● Easy to Write code without worrying about thread locks and being thread safe.
● Node.js allows developers to write JavaScript for both the server and client side.
NODE.JS SOLUTION
15. ● Asynchronous event-driven JavaScript runtime.
● Server-side Javascript.
● Built on Google’s V8 engine.
● Purely evented, non-blocking I/O. Influenced by system like EventMachine or Twisted.
● 8k lines of C/C++, 2k lines of Javascript (maybe some more PRs got merged)
● Designed to build scalable network applications.
● Designed because I/O needs to be done differently.
● It has an Event Loop for orchestration and a Worker Pool for expensive tasks.
NODE.JS
16. ● No function should directly perform I/O. To receive info from disk, network, or another
process there must be a callback. (Thinking about async / await)
● Have Built in support for the most important protocols. TCP, DNS, HTTP
● Have support for many HTTP features.
○ Chunked requests and responses.
○ Keep-alive etc.
● Be platform independent.
● As Node is designed without threads, doesn't mean you cannot take advantage of
multiple cores in your environment.
○ child_process.fork()
○ cluster module
NODE.JS DESIGN GOALS
32. ● Libuv is a multi-platform support library with a focus on asynchronous I/O
and more.
● Small (relatively) C library : ~ 30K LOC (without tests)
● Designed for Node.js and C programs that miss the joy of javascript callback hell.
● Used by many other projects. https://github.com/libuv/libuv/wiki/Projects-that-use-libuv.
● Libuv is the heart of Node.js architecture.
● It abstract internal I/O complexities and provide a generalized interface to upper layers of
Node, so that Node can perform platform independent asynchronous I/O without
worrying about what platform it is run on.
LIBUV
33. ● Full-featured Event Loop backed by epoll, kqueue, IOCP, event ports
● Asynchronous TCP and UDP sockets
● Asynchronous DNS resolution (dns.lookup)
● Asynchronous file and file system operations (fs.readFile, fs.readFileSync)
● High resolution clock and Timer (setTimeout, setInterval)
● Child processes (child_process.fork, process.nextTick)
● Thread pool and Threading utilities
● Signal handling
● Coolest Logo ever :)
LIBUV FEATURES
35. The event loop: uv_loop_t (Single Threaded)
LIBUV ARCHITECTURE
36. ● Libuv event loop is single threaded.
● Libuv only use threads for file i/o and getaddrinfo(dns lookup).
● http://blog.libtorrent.org/2012/10/asynchronous-disk-io/
● Default thread pool size is 4 (runtime env var: UV_THREADPOOL_SIZE)
● NOT FOR NETWORK I/O
● NOT FOR NETWORK I/O
● NOT FOR NETWORK I/O
LIBUV THREADS
37. Node uses the thread Pool to handle "expensive" tasks. This includes I/O for
which an operating system does not provide a non-blocking version, as well as
particularly CPU-intensive tasks.
1. I/O-intensive
1. DNS: dns.lookup(), dns.lookupService().
2. File System: All file system APIs except fs.FSWatcher() and those that are explicitly
synchronous use libuv's threadpool.
2. CPU-intensive
1. Crypto: crypto.pbkdf2(), crypto.scrypt(), crypto.randomBytes(), crypto.randomFill(),
crypto.generateKeyPair().
2. Zlib: All zlib APIs except those that are explicitly synchronous use libuv's threadpool.
NODE.JS THREAD POOL
47. ● Node.js internally uses a library called Libuv. Which basically does most of the magic for
node.
● Libuv is multithreaded and uses preallocated set of threads called Thread Pool. The
default size of thread pool is 4.
● All javascript, V8 and event loop executes on the same thread called main thread.
● Node.js Event loop is part of Libuv library and does not resides inside node.js code base.
IS NODE REALLY SINGLE THREADED?
49. For keeping your Node server speedy: Node is fast when the work associated with each
client at any given time is "small".
This applies to callbacks on the Event Loop and tasks on the Worker Pool.
WHEN TO USE NODE?
