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...
Two approaches to I/O
// blocking I/O + threads
var urls = db.query("select * from urls"); // wait
urls.each(function (url...
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
      ...
Apache vs. Nginx




http://blog.webfaction.com/a-little-holiday-present
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-grain...
Why threads are bad
• Hard to program
• Shared state and locks
• Deadlocks
• Giant locks decrease concurrency
• Fine-grain...
Why threads are bad
• Hard to program
• Shared state and locks
• Deadlocks
• Giant locks decrease concurrency
• Fine-grain...
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...
Event Loop
 user perspective
• You already use it everyday for I/O
• You register callbacks for events
• Your callback is ...
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...
Event Loop
            life cycle
• Initialize empty event loop (just an array)
• Read and “execute” code
 • Execute non-I...
Event Loop
            life cycle
• Initialize empty event loop (just an array)
• Read and “execute” code
 • Execute non-I...
Event Loop
            life cycle
• Initialize empty event loop (just an array)
• Read and “execute” code
 • Execute non-I...
Event Loop
            life cycle
• Initialize empty event loop (just an array)
• Read and “execute” code
 • Execute non-I...
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
 ...
Event Loop
             life cycle
• Iterate over a list of events and callbacks
• Perform I/O using non-blocking kernel
 ...
Event Loop
             life cycle
• Iterate over a list of events and callbacks
• Perform I/O using non-blocking kernel
 ...
Event Loop
             life cycle
• Iterate over a list of events and callbacks
• Perform I/O using non-blocking kernel
 ...
Event Loop
             life cycle
• Iterate over a list of events and callbacks
• Perform I/O using non-blocking kernel
 ...
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 u...
Event Loop limitations
• Callbacks have to return fast
 • No CPU-heavy stuff
• What about multi-core CPUs
 • Web Workers u...
Event Loop limitations
• Callbacks have to return fast
 • No CPU-heavy stuff
• What about multi-core CPUs
 • Web Workers u...
Event Loop limitations
• Callbacks have to return fast
 • No CPU-heavy stuff
• What about multi-core CPUs
 • Web Workers u...
Hello World
var sys = require('sys'),
   http = require('http');
http.createServer(function (req, res) {
  setTimeout(func...
sleep()
sleep()
• It is a blocking call per definition
sleep()
• It is a blocking call per definition
• Browser JS has no blocking functions
sleep()
• It is a blocking call per definition
• Browser JS has no blocking functions
• Except synchronous AJAX which is
  ...
sleep()
• It is a blocking call per definition
• Browser JS has no blocking functions
• Except synchronous AJAX which is
  ...
sleep()
• It is a blocking call per definition
• Browser JS has no blocking functions
• Except synchronous AJAX which is
  ...
Where to go next
• github.com/ry/node
• groups.google.com/group/nodejs
• howtonode.org
• dailyjs.org
• search twitter for ...
Demo
Introduction to node.js
Upcoming SlideShare
Loading in...5
×

Introduction to node.js

16,807

Published on

Slides I presented in srug.pl meeting on February 26, 2010

Published in: Technology
2 Comments
25 Likes
Statistics
Notes
  • If this is a background process then you're fine - it probably doesn't matter too much. If you're inside a web server - try http://nodejs.org/docs/v0.3.7/api/child_processes.html (this approach also nicely scales across multiple cpu cores). 'Action rendering time' > 'The x seconds of continuous processing without letting go of the CPU'. Less than 100ms is good. Some people say: 'well, it depends' ;)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • You write on slide 49, 'Callbacks have to return fast -- no CPU heavy stuff.' I want to move from a blocking web spider that also does some keyword matching against the returned page, to using non-blocking node stuff. Can you please give me a vague scale of an acceptable range for returning fast? I envision using node to pull a page from a remote server, then perform the keyword processing on it (less than 1s of processing for sure). Is that too CPU heavy / too long of an execution time?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
16,807
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
563
Comments
2
Likes
25
Embeds 0
No embeds

No notes for slide



















































  • Introduction to node.js

    1. 1. There’s no sleep() in Javascript Introduction to node.js twitter.com/jacek_becela github.com/ncr
    2. 2. node.js
    3. 3. node.js • Server-side Javascript runtime • Google V8 • CommonJS modules
    4. 4. 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
    5. 5. 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);     });   }); });
    6. 6. I/O Costs http://nodejs.org/jsconf.pdf
    7. 7. I/O Costs • L1: 3 cycles http://nodejs.org/jsconf.pdf
    8. 8. I/O Costs • L1: 3 cycles • L2: 14 cycles http://nodejs.org/jsconf.pdf
    9. 9. I/O Costs • L1: 3 cycles • L2: 14 cycles • RAM: 250 cycles http://nodejs.org/jsconf.pdf
    10. 10. I/O Costs • L1: 3 cycles • L2: 14 cycles • RAM: 250 cycles • DISK: 41,000,000 cycles http://nodejs.org/jsconf.pdf
    11. 11. 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
    12. 12. Apache vs. Nginx http://blog.webfaction.com/a-little-holiday-present
    13. 13. Apache vs. Nginx http://blog.webfaction.com/a-little-holiday-present
    14. 14. Why threads are bad
    15. 15. Why threads are bad • Hard to program
    16. 16. Why threads are bad • Hard to program • Shared state and locks
    17. 17. Why threads are bad • Hard to program • Shared state and locks • Deadlocks
    18. 18. Why threads are bad • Hard to program • Shared state and locks • Deadlocks • Giant locks decrease concurrency
    19. 19. Why threads are bad • Hard to program • Shared state and locks • Deadlocks • Giant locks decrease concurrency • Fine-grained locks increase complexity
    20. 20. Why threads are bad • Hard to program • Shared state and locks • Deadlocks • Giant locks decrease concurrency • Fine-grained locks increase complexity • Race conditions
    21. 21. 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
    22. 22. When threads are good
    23. 23. When threads are good • Support Multi-core CPUs
    24. 24. When threads are good • Support Multi-core CPUs • CPU-heavy work
    25. 25. When threads are good • Support Multi-core CPUs • CPU-heavy work • Little or no shared state
    26. 26. When threads are good • Support Multi-core CPUs • CPU-heavy work • Little or no shared state • Threads count == CPU cores count
    27. 27. Event Loop user perspective • You already use it everyday for I/O • You register callbacks for events • Your callback is eventually fired $("a").click(function () {   console.log("clicked!"); });   $.ajax(..., function (...) {   console.log("internets!"); });
    28. 28. Event Loop life cycle
    29. 29. Event Loop life cycle • Initialize empty event loop (just an array)
    30. 30. Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code
    31. 31. Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code • Execute non-I/O code
    32. 32. 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
    33. 33. 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
    34. 34. 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
    35. 35. 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
    36. 36. Event Loop life cycle
    37. 37. Event Loop life cycle • Iterate over a list of events and callbacks
    38. 38. 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
    39. 39. 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
    40. 40. 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 notifies the Event Loop
    41. 41. 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 notifies the Event Loop • Event Loop executes and removes a callback
    42. 42. 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 notifies the Event Loop • Event Loop executes and removes a callback • Program exits when Event Loop is empty
    43. 43. Event Loop limitations
    44. 44. Event Loop limitations • Callbacks have to return fast
    45. 45. Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff
    46. 46. Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff • What about multi-core CPUs
    47. 47. Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff • What about multi-core CPUs • Web Workers using separate processes
    48. 48. 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
    49. 49. 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
    50. 50. 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
    51. 51. 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/');
    52. 52. sleep()
    53. 53. sleep() • It is a blocking call per definition
    54. 54. sleep() • It is a blocking call per definition • Browser JS has no blocking functions
    55. 55. sleep() • It is a blocking call per definition • Browser JS has no blocking functions • Except synchronous AJAX which is supposed to be used in “unload” event
    56. 56. sleep() • It is a blocking call per definition • 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...
    57. 57. sleep() • It is a blocking call per definition • 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
    58. 58. 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/flickr_spy
    59. 59. Demo
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×