Introduction to node.js

There’s no sleep() in Javascript Introduction to node.js twitter.com/jacek_becela github.com/ncr

node.js

node.js • Server-side Javascript runtime • Google V8 • CommonJS modules

node.js • Server-side Javascript runtime • Google V8 • CommonJS modules • API for highly concurrent programming • All I/O is non-blocking (asynchronous) • Achieved using Event Loop

Two approaches to I/O // blocking I/O + threads var urls = db.query("select * from urls"); // wait urls.each(function (url) { var page = http.get(url); // wait save(page); // wait }); // non-blocking I/O + event loop db.query("select * from urls", function (urls) { urls.each(function (url) { http.get(url, function (page) { save(page); }); }); });

I/O Costs http://nodejs.org/jsconf.pdf

I/O Costs • L1: 3 cycles http://nodejs.org/jsconf.pdf

I/O Costs • L1: 3 cycles • L2: 14 cycles http://nodejs.org/jsconf.pdf

I/O Costs • L1: 3 cycles • L2: 14 cycles • RAM: 250 cycles http://nodejs.org/jsconf.pdf

I/O Costs • L1: 3 cycles • L2: 14 cycles • RAM: 250 cycles • DISK: 41,000,000 cycles http://nodejs.org/jsconf.pdf

I/O Costs • L1: 3 cycles • L2: 14 cycles • RAM: 250 cycles • DISK: 41,000,000 cycles • NETWORK: 240,000,000 cycles http://nodejs.org/jsconf.pdf

Apache vs. Nginx http://blog.webfaction.com/a-little-holiday-present

Why threads are bad

Why threads are bad • Hard to program

Why threads are bad • Hard to program • Shared state and locks

Why threads are bad • Hard to program • Shared state and locks • Deadlocks

Why threads are bad • Hard to program • Shared state and locks • Deadlocks • Giant locks decrease concurrency

Why threads are bad • Hard to program • Shared state and locks • Deadlocks • Giant locks decrease concurrency • Fine-grained locks increase complexity

Why threads are bad • Hard to program • Shared state and locks • Deadlocks • Giant locks decrease concurrency • Fine-grained locks increase complexity • Race conditions

Why threads are bad • Hard to program • Shared state and locks • Deadlocks • Giant locks decrease concurrency • Fine-grained locks increase complexity • Race conditions • Context switching costs

When threads are good

When threads are good • Support Multi-core CPUs

When threads are good • Support Multi-core CPUs • CPU-heavy work

When threads are good • Support Multi-core CPUs • CPU-heavy work • Little or no shared state

When threads are good • Support Multi-core CPUs • CPU-heavy work • Little or no shared state • Threads count == CPU cores count

Event Loop user perspective • You already use it everyday for I/O • You register callbacks for events • Your callback is eventually ﬁred $("a").click(function () { console.log("clicked!"); }); $.ajax(..., function (...) { console.log("internets!"); });

Event Loop life cycle

Event Loop life cycle • Initialize empty event loop (just an array)

Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code

Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code • Execute non-I/O code

Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code • Execute non-I/O code • Add every I/O call to the event loop

Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code • Execute non-I/O code • Add every I/O call to the event loop • End of source code reached

Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code • Execute non-I/O code • Add every I/O call to the event loop • End of source code reached • Event loop starts iterating

Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code • Execute non-I/O code • Add every I/O call to the event loop • End of source code reached • Event loop starts iterating • All this happens in a single thread

Event Loop life cycle

Event Loop life cycle • Iterate over a list of events and callbacks

Event Loop life cycle • Iterate over a list of events and callbacks • Perform I/O using non-blocking kernel facilities: epoll, kqueue, /dev/poll, select

Event Loop life cycle • Iterate over a list of events and callbacks • Perform I/O using non-blocking kernel facilities: epoll, kqueue, /dev/poll, select • Event Loop goes to sleep

Event Loop life cycle • Iterate over a list of events and callbacks • Perform I/O using non-blocking kernel facilities: epoll, kqueue, /dev/poll, select • Event Loop goes to sleep • Kernel notiﬁes the Event Loop

Event Loop life cycle • Iterate over a list of events and callbacks • Perform I/O using non-blocking kernel facilities: epoll, kqueue, /dev/poll, select • Event Loop goes to sleep • Kernel notiﬁes the Event Loop • Event Loop executes and removes a callback

Event Loop life cycle • Iterate over a list of events and callbacks • Perform I/O using non-blocking kernel facilities: epoll, kqueue, /dev/poll, select • Event Loop goes to sleep • Kernel notiﬁes the Event Loop • Event Loop executes and removes a callback • Program exits when Event Loop is empty

Event Loop limitations

Event Loop limitations • Callbacks have to return fast

Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff

Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff • What about multi-core CPUs

Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff • What about multi-core CPUs • Web Workers using separate processes

Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff • What about multi-core CPUs • Web Workers using separate processes • Can do CPU-heavy stuff

Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff • What about multi-core CPUs • Web Workers using separate processes • Can do CPU-heavy stuff • No shared memory - no locks

Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff • What about multi-core CPUs • Web Workers using separate processes • Can do CPU-heavy stuff • No shared memory - no locks • Communication using message passing

Hello World var sys = require('sys'), http = require('http'); http.createServer(function (req, res) { setTimeout(function () { res.sendHeader(200, {'Content-Type': 'text/plain'}); res.write('Hello World'); res.close(); }, 2000); }).listen(8000); sys.puts('Server running at http://127.0.0.1:8000/');

sleep()

sleep() • It is a blocking call per deﬁnition

sleep() • It is a blocking call per deﬁnition • Browser JS has no blocking functions

sleep() • It is a blocking call per deﬁnition • Browser JS has no blocking functions • Except synchronous AJAX which is supposed to be used in “unload” event

sleep() • It is a blocking call per deﬁnition • Browser JS has no blocking functions • Except synchronous AJAX which is supposed to be used in “unload” event • You can emulate sleep() using a “while” loop and checking wall clock but what’s the point...

sleep() • It is a blocking call per deﬁnition • Browser JS has no blocking functions • Except synchronous AJAX which is supposed to be used in “unload” event • You can emulate sleep() using a “while” loop and checking wall clock but what’s the point... • The real reason: JavaScript exceution and Event Loop live in a single thread

Where to go next • github.com/ry/node • groups.google.com/group/nodejs • howtonode.org • dailyjs.org • search twitter for node.js • github.com/ncr/ﬂickr_spy

http://www.slideshare.net	46
http://mj89sp3sau2k7lj1eg3k40hkeppguj6j-a-sites-opensocial.googleusercontent.com	7
http://www.tipiweb.tk	5
http://migueldev.com	1

Introduction to node.js

by jacekbecela on Feb 24, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 59

Statistics

Introduction to node.js — Presentation Transcript