Introduction to node.js

18,869 views
18,508 views

Published on

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

Published in: Technology
2 Comments
27 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
18,869
On SlideShare
0
From Embeds
0
Number of Embeds
209
Actions
Shares
0
Downloads
689
Comments
2
Likes
27
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

    ×