Introduction to node.js
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Introduction to node.js

  • 17,715 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • 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' ;)
    Are you sure you want to
    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?
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
17,715
On Slideshare
17,513
From Embeds
202
Number of Embeds
5

Actions

Shares
Downloads
426
Comments
2
Likes
24

Embeds 202

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

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide



















































Transcript

  • 1. There’s no sleep() in Javascript Introduction to node.js twitter.com/jacek_becela github.com/ncr
  • 2. node.js
  • 3. node.js • Server-side Javascript runtime • Google V8 • CommonJS modules
  • 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. 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. I/O Costs http://nodejs.org/jsconf.pdf
  • 7. I/O Costs • L1: 3 cycles http://nodejs.org/jsconf.pdf
  • 8. I/O Costs • L1: 3 cycles • L2: 14 cycles http://nodejs.org/jsconf.pdf
  • 9. I/O Costs • L1: 3 cycles • L2: 14 cycles • RAM: 250 cycles http://nodejs.org/jsconf.pdf
  • 10. I/O Costs • L1: 3 cycles • L2: 14 cycles • RAM: 250 cycles • DISK: 41,000,000 cycles http://nodejs.org/jsconf.pdf
  • 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. Apache vs. Nginx http://blog.webfaction.com/a-little-holiday-present
  • 13. Apache vs. Nginx http://blog.webfaction.com/a-little-holiday-present
  • 14. Why threads are bad
  • 15. Why threads are bad • Hard to program
  • 16. Why threads are bad • Hard to program • Shared state and locks
  • 17. Why threads are bad • Hard to program • Shared state and locks • Deadlocks
  • 18. Why threads are bad • Hard to program • Shared state and locks • Deadlocks • Giant locks decrease concurrency
  • 19. Why threads are bad • Hard to program • Shared state and locks • Deadlocks • Giant locks decrease concurrency • Fine-grained locks increase complexity
  • 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. 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. When threads are good
  • 23. When threads are good • Support Multi-core CPUs
  • 24. When threads are good • Support Multi-core CPUs • CPU-heavy work
  • 25. When threads are good • Support Multi-core CPUs • CPU-heavy work • Little or no shared state
  • 26. When threads are good • Support Multi-core CPUs • CPU-heavy work • Little or no shared state • Threads count == CPU cores count
  • 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. Event Loop life cycle
  • 29. Event Loop life cycle • Initialize empty event loop (just an array)
  • 30. Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code
  • 31. Event Loop life cycle • Initialize empty event loop (just an array) • Read and “execute” code • Execute non-I/O code
  • 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. 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. 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. 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. Event Loop life cycle
  • 37. Event Loop life cycle • Iterate over a list of events and callbacks
  • 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. 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. 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. 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. 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. Event Loop limitations
  • 44. Event Loop limitations • Callbacks have to return fast
  • 45. Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff
  • 46. Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff • What about multi-core CPUs
  • 47. Event Loop limitations • Callbacks have to return fast • No CPU-heavy stuff • What about multi-core CPUs • Web Workers using separate processes
  • 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. 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. 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. 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. sleep()
  • 53. sleep() • It is a blocking call per definition
  • 54. sleep() • It is a blocking call per definition • Browser JS has no blocking functions
  • 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. 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. 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. 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. Demo