Sensible scaling

5,669 views

Published on

Talk from 4Developers '12 and PHP Barcelona '11

It’s fun to architect your application to handle millions of pageviews, but in reality that’s time where you could be adding features. We’ll examine some practical solutions for designing your platform to deal with increasing traffic and how to add those features on an incremental basis. This will take us through options for scaling the code and additional methods for scaling the infrastructure.

Published in: Technology, Design
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,669
On SlideShare
0
From Embeds
0
Number of Embeds
3,537
Actions
Shares
0
Downloads
46
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Sensible scaling

  1. 1. Sensible Scaling Rowan Merewood
  2. 2. Sensible Scaling “If your application doesnt scale, its your fault not mine.” – Rasmus Lerdorf (@rasmus) Rowan Merewood
  3. 3. Who?
  4. 4. Who?● @rowan_m
  5. 5. Who?● @rowan_m● Software Engineer & Team Lead
  6. 6. Who?● @rowan_m● Software Engineer & Team Lead● @ibuildings & @techportal
  7. 7. Why?
  8. 8. Why? ● Ive built small apps
  9. 9. Why? ● Ive built small apps ● and pretty large ones
  10. 10. Why? ● Ive built small apps ● and pretty large ones ● Ive seen massive over-engineering
  11. 11. Why? ● Ive built small apps ● and pretty large ones ● Ive seen massive over-engineering ● and platforms that cannot scale
  12. 12. TDD Principles
  13. 13. TDD Principles● Write only enough code to pass the test
  14. 14. TDD Principles● Write only enough code to pass the test● Do not over-engineer
  15. 15. TDD Principles● Write only enough code to pass the test● Do not over-engineer● Dont give away work for free!
  16. 16. Build for now
  17. 17. Build for now ● Dont be afraid to throw code away
  18. 18. Build for now ● Dont be afraid to throw code away ● XPs spikes
  19. 19. Build for now ● Dont be afraid to throw code away ● XPs spikes ● Take advantage of current tech. without tying yourself to it
  20. 20. Who are your users?
  21. 21. Who are your users?● Lots of short visits?
  22. 22. Who are your users?● Lots of short visits?● Anonymous or session-based?
  23. 23. Who are your users?● Lots of short visits?● Anonymous or session-based?● Long, complex interactions?
  24. 24. Who are your users?● Lots of short visits?● Anonymous or session-based?● Long, complex interactions?● Subscribers or free users?
  25. 25. Monitor and Analysehttp://community.plus.net/blog/2011/10/24/a-record-setting-manchester-derby/
  26. 26. Monitor and Analyse ● Predict usage patternshttp://community.plus.net/blog/2011/10/24/a-record-setting-manchester-derby/
  27. 27. Monitor and Analyse ● Predict usage patterns ● Plan for peaks and troughshttp://community.plus.net/blog/2011/10/24/a-record-setting-manchester-derby/
  28. 28. Profiling
  29. 29. Profiling● You do not know what is slow
  30. 30. Profiling● You do not know what is slow● Ensure you measure more than just code!
  31. 31. Profiling
  32. 32. Profiling● PHP - Xdebug – Derick Rethans (@derickr) ● Kcachegrind, Webgrind, etc.
  33. 33. Profiling● PHP - Xdebug – Derick Rethans (@derickr) ● Kcachegrind, Webgrind, etc.● PHP – XHProf
  34. 34. Profiling● PHP - Xdebug – Derick Rethans (@derickr) ● Kcachegrind, Webgrind, etc.● PHP – XHProf● JavaScript – Firebug
  35. 35. Profiling● PHP - Xdebug – Derick Rethans (@derickr) ● Kcachegrind, Webgrind, etc.● PHP – XHProf● JavaScript – Firebug● JavaScript – Venkman
  36. 36. Profiling● PHP - Xdebug – Derick Rethans (@derickr) ● Kcachegrind, Webgrind, etc.● PHP – XHProf● JavaScript – Firebug● JavaScript – Venkman● General page display - YSlow
  37. 37. Profiling● CPU Load – top & /proc/loadavg
  38. 38. Profiling● CPU Load – top & /proc/loadavg● Disk IO – iotop
  39. 39. Profiling● CPU Load – top & /proc/loadavg● Disk IO – iotop● Memory – free
  40. 40. Profiling● CPU Load – top & /proc/loadavg● Disk IO – iotop● Memory – free● Network – netstat
  41. 41. Profiling● CPU Load – top & /proc/loadavg● Disk IO – iotop● Memory – free● Network – netstat● Monitoring – watch & time
  42. 42. Profiling under load
  43. 43. Profiling under load ● Code bottlenecks != Platform bottlenecks
  44. 44. Profiling under load ● Code bottlenecks != Platform bottlenecks ● Test in production, if possible
  45. 45. Profiling under load ● Code bottlenecks != Platform bottlenecks ● Test in production, if possible ● Use multiple VMs (Vagrant can help automate this)
  46. 46. Profiling under load ● Code bottlenecks != Platform bottlenecks ● Test in production, if possible ● Use multiple VMs (Vagrant can help automate this) ● Use siege & ab
  47. 47. Finding bottlenecks
  48. 48. Finding bottlenecksRight Wrong
  49. 49. Finding bottlenecks Right Wrong● Database
  50. 50. Finding bottlenecks Right Wrong● Database● Disk IO
  51. 51. Finding bottlenecks Right Wrong● Database● Disk IO● External services
  52. 52. Finding bottlenecks Right Wrong● Database● Disk IO● External services● Application work
  53. 53. Finding bottlenecks Right Wrong● Database ● Autoloaders● Disk IO● External services● Application work
  54. 54. Finding bottlenecks Right Wrong● Database ● Autoloaders● Disk IO ● Config files● External services● Application work
  55. 55. Finding bottlenecks Right Wrong● Database ● Autoloaders● Disk IO ● Config files● External services ● Logging● Application work
  56. 56. Finding bottlenecks Right Wrong● Database ● Autoloaders● Disk IO ● Config files● External services ● Logging● Application work ● Object instantiation
  57. 57. Finding bottlenecks Right Wrong● Database ● Autoloaders● Disk IO ● Config files● External services ● Logging● Application work ● Object instantiation ● Frameworks
  58. 58. Finding bottlenecks Right Wrong● Database ● Autoloaders● Disk IO ● Config files● External services ● Logging● Application work ● Object instantiation ● Frameworks Ask Jo (@juokas) about Doctrine!
  59. 59. Tell users its slow
  60. 60. Tell users its slow ● User experience != Raw speed
  61. 61. Tell users its slow ● User experience != Raw speed ● Keep the UI responsive
  62. 62. Tell users its slow ● User experience != Raw speed ● Keep the UI responsive ● Set expectations
  63. 63. Tell users its slow ● User experience != Raw speed ● Keep the UI responsive ● Set expectations ● Adapt to changes (@blongden)
  64. 64. Fail gracefully
  65. 65. Fail gracefully● Actively choose to time-out
  66. 66. Fail gracefully● Actively choose to time-out● Prioritise core/profitable functionality
  67. 67. Fail gracefully● Actively choose to time-out● Prioritise core/profitable functionality● Have a BIG RED BUTTON
  68. 68. Separate functionality
  69. 69. Separate functionality Admin Batch
  70. 70. Separate functionality Admin Batch● Different users == diff. requirements
  71. 71. Separate functionality Admin Batch● Different users == diff. requirements● No cache
  72. 72. Separate functionality Admin Batch● Different users == diff. requirements● No cache● “Master” storage
  73. 73. Separate functionality Admin Batch● Different users == diff. requirements● No cache● “Master” storage● Security
  74. 74. Separate functionality Admin Batch● Different users == ● Not time critical diff. requirements● No cache● “Master” storage● Security
  75. 75. Separate functionality Admin Batch● Different users == ● Not time critical diff. requirements ● CPU/RAM hungry● No cache● “Master” storage● Security
  76. 76. Separate functionality Admin Batch● Different users == ● Not time critical diff. requirements ● CPU/RAM hungry● No cache ● nice / ionice● “Master” storage● Security
  77. 77. Separate functionality Admin Batch● Different users == ● Not time critical diff. requirements ● CPU/RAM hungry● No cache ● nice / ionice● “Master” storage ● Network rate limiting● Security
  78. 78. Separate functionality Admin Batch● Different users == ● Not time critical diff. requirements ● CPU/RAM hungry● No cache ● nice / ionice● “Master” storage ● Network rate limiting● Security ● Read only?
  79. 79. Configure hardware correctly
  80. 80. Configure hardware correctly ● What is required for 1 request?
  81. 81. Configure hardware correctly ● What is required for 1 request? ● How many concurrent requests?
  82. 82. Configure hardware correctly ● What is required for 1 request? ● How many concurrent requests? ● Is it a linear scale?
  83. 83. Configure hardware correctly ● What is required for 1 request? ● How many concurrent requests? ● Is it a linear scale? ● Ask your hosting company
  84. 84. Aim for services
  85. 85. Aim for services
  86. 86. Obey the “Law of Demeter”
  87. 87. Obey the “Law of Demeter”● Talk to your friends, dont talk to strangers
  88. 88. Obey the “Law of Demeter”● Talk to your friends, dont talk to strangers● Promotes loose coupling
  89. 89. Obey the “Law of Demeter” Good Bad
  90. 90. Obey the “Law of Demeter” Good● $person->requestPayment($amount); Bad
  91. 91. Obey the “Law of Demeter” Good● $person->requestPayment($amount); Bad● $wallet = $person->getWallet();● $wallet->getMoney($amount);
  92. 92. Obey the “Law of Demeter” Good Bad
  93. 93. Obey the “Law of Demeter” Good Bad
  94. 94. Obey the “Law of Demeter” Good Bad
  95. 95. Create immutable objects
  96. 96. Create immutable objects● Objects that cannot change after creation
  97. 97. Create immutable objects● Objects that cannot change after creation● Copy On Write (COW - � ← unicode cow)
  98. 98. Create immutable objects● Objects that cannot change after creation● Copy On Write (COW - � ← unicode cow)● More memory-hungry, but easy to roll back
  99. 99. Create immutable objects● Objects that cannot change after creation● Copy On Write (COW - � ← unicode cow)● More memory-hungry, but easy to roll back● Value objects should be immutable
  100. 100. Create immutable objects● Objects that cannot change after creation● Copy On Write (COW - � ← unicode cow)● More memory-hungry, but easy to roll back● Value objects should be immutable● Think of them like a response from a service
  101. 101. Identify “single server” factors
  102. 102. Identify “single server” factors● File uploads / user content
  103. 103. Identify “single server” factors● File uploads / user content● IP restrictions / server access
  104. 104. Identify “single server” factors● File uploads / user content● IP restrictions / server access● Licensing?
  105. 105. Create services
  106. 106. Create servicesYour API should be:
  107. 107. Create services Your API should be:● Independent of application state
  108. 108. Create services Your API should be:● Independent of application state● Loosely coupled
  109. 109. Create services Your API should be:● Independent of application state● Loosely coupled● Accepting/returning immutable objects
  110. 110. Use caches
  111. 111. Use caches ● REST-ful services over HTTP let you cache easily
  112. 112. Use caches ● REST-ful services over HTTP let you cache easily ● Internal caching is trickier, but “out-of- the-box” with most frameworks
  113. 113. Use caches ● REST-ful services over HTTP let you cache easily ● Internal caching is trickier, but “out-of- the-box” with most frameworksProxy other peoples services through your own cache!
  114. 114. Use queues
  115. 115. Use queues● Full blown job server: Gearman
  116. 116. Use queues● Full blown job server: Gearman● AMQP implementation: RabbitMQ
  117. 117. Use queues● Full blown job server: Gearman● AMQP implementation: RabbitMQ● Light-weight sockets: 0MQ
  118. 118. Use the right storage
  119. 119. Use the right storage
  120. 120. Use the right storage Consistency Availability Partitioning
  121. 121. Use the right storage Consistency Availability Enforced consistency Eventual consistency (RDBMS) (NoSQL) Partitioning
  122. 122. Scale your storage
  123. 123. Scale your storage● Master/slave replication
  124. 124. Scale your storage● Master/slave replication● Table partitioning
  125. 125. Scale your storage● Master/slave replication● Table partitioning● Row partitioning
  126. 126. Scale your storage● Master/slave replication● Table partitioning● Row partitioning● rsync
  127. 127. Scale your storage● Master/slave replication● Table partitioning● Row partitioning● rsync● NFS
  128. 128. Scale your storage● Master/slave replication● Table partitioning● Row partitioning● rsync● NFS● GlusterFS
  129. 129. Now you can use the cloud
  130. 130. Now you can use the cloud● Full service – orchestra.io
  131. 131. Now you can use the cloud● Full service orchestra.io● Infrastructure mgmt. Scalr
  132. 132. Now you can use the cloud● Full service orchestra.io● Infrastructure mgmt. Scalr● Manually $your_code_here
  133. 133. Now you can use the cloud● Full service orchestra.io● Infrastructure mgmt. Scalr● Manually $your_code_here● Automate! Chef & Puppet
  134. 134. Review
  135. 135. Review ● Start with only what you need
  136. 136. Review ● Start with only what you need ● Identify the problems
  137. 137. Review ● Start with only what you need ● Identify the problems ● Pull the problem out to a service
  138. 138. Review ● Start with only what you need ● Identify the problems ● Pull the problem out to a service ● Distribute
  139. 139. Thank you!● Feedback: http://joind.in/6324● Photos & Transformers: Nina Merewood● Legal? Takara & Hasbro● ElePHPant smuggling: Johannes Schlüter (@phperror)● Vintage photo nonsense: http://pixlr.com/o-matic/

×