Multi-tiered Node Architectures - JSConf 2011

15,307 views

Published on

Published in: Technology
1 Comment
29 Likes
Statistics
Notes
No Downloads
Views
Total views
15,307
On SlideShare
0
From Embeds
0
Number of Embeds
209
Actions
Shares
0
Downloads
297
Comments
1
Likes
29
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 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

    ×