Your SlideShare is downloading. ×
0
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Introduction to node.js
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introduction to node.js

16,446

Published on

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

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,446
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
531
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

    ×