Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Multi-tiered Node Architectures - JSConf 2011

16,135 views

Published on

Published in: Technology
  • Tom - do you have any data to back up the suggestion on slide 56. In particular, I'm curious to know what kind of work load, and request patterns influenced that suggestion.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Multi-tiered Node Architectures - JSConf 2011

  1. 1. Multi-tiered Node.jsArchitecturesTom Hughes-Croucher@sh1mmertom@joyent.com
  2. 2. Scalable Server-Side Code with JavaScriptNode Up and Running Tom Hughes-Croucher
  3. 3. Goal 1.Minimise clientresponse time
  4. 4. Goal 2.Maximise resourceefficiency on server
  5. 5. Client → Server Server → DB Computation Computation
  6. 6. Pre-allocate resources to the client for the entire duration
  7. 7. Get efficiency within each connection
  8. 8. Pre-allocation = sacrificing resource efficiency forconnection response times
  9. 9. Server
  10. 10. Request
  11. 11. In order to serve thefastest request memory is heavily wasted
  12. 12. When you run out ofmemory the server gets overwhelmed
  13. 13. And that sucks.
  14. 14. Don’t pre-allocate memory
  15. 15. Create a place-holder for ‘slow’ tasks
  16. 16. Place-holder
  17. 17. Shared WorkResources
  18. 18. Deal with tasks when they are ready in a FIFO way
  19. 19. App (event loop) AppEvents Event OS StackEvents
  20. 20. If we block the event loop then we can’t serve requests
  21. 21. If we do “big” work in the event loop then we can only serve requests after the work is finished
  22. 22. Blocking the main event loop is bad. Mmmkay.
  23. 23. Event-loop harassment Pan-da
  24. 24. Multi-tieredArchitectures
  25. 25. The obviousarchitecture
  26. 26. Client Front-end DatabaseUser Node DB
  27. 27. What about this?
  28. 28. Front-end JSDomClient Database Farm Render FarmUser Node Node Node Node DB Node Node Node Node
  29. 29. Why an architecture like this?
  30. 30. Parallelisation?
  31. 31. Client → Server Server → DB Computation Computation
  32. 32. Non-blocking I/O removes resourceallocation during latency
  33. 33. Pushing client-facing processing off the main process does not improve response time
  34. 34. Better multi-tier architectures
  35. 35. Front-endClient Database Farm DBUser Node Node Node Node Big Slow Logging farm Disk Node Node Disk
  36. 36. Move work which isn’tuser-facing out of main event loop
  37. 37. Use pre-forking todistribute work acrossprocessors into ‘farms’
  38. 38. Distributing work
  39. 39. Cluster
  40. 40. children.js:var server = require(http).createServer( function(req, res) { res.writeHead(200, {}); res.end("Sever stuff"); });
  41. 41. Run
  42. 42. var cluster = require(cluster);cluster(children).listen(80);
  43. 43. Use load balancers to distribute across servers
  44. 44. node-proxy squid varnish haproxy
  45. 45. Sharding
  46. 46. Disclaimer:Sharding is hard
  47. 47. Node processes can hold many clients soyou can do big shards
  48. 48. Inter-processcommunication on machine
  49. 49. Use file descriptor sharing to do onmachine multicast
  50. 50. Load Front-endClient Database balancers Shards Node Node Node NodeUser Node Node DB Node Node Node Node Node Node
  51. 51. Unix FDs have much lower unboundedlatency than network
  52. 52. Summary
  53. 53. 1. Don’t sweat client facing CPU time2. Move non client-facing away3. Cluster to use all processors
  54. 54. Fin.(You should follow me, @sh1mmer on Twitter. Like now!)
  55. 55. Bonus

×