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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Introduction to node.js

15,678
views

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