Introduction to node.js

  • 15,238 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
15,238
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
438
Comments
2
Likes
25

Embeds 0

No embeds

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