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.

Scalable Architecture 101


Published on

Published in: Technology
  • Be the first to comment

Scalable Architecture 101

  1. 1. Mike Willbanks Blog: Twitter : mwillbanks IRC : lubs on freenode Scalable Architectures 101 MNPHP
  2. 2. Scalability? <ul>Your application is growing, your systems are slowing and growth is inevitable... <li>Where do we go from here? </li><ul><li>Web Servers
  3. 3. Database Servers
  4. 4. Cache Servers
  5. 5. Job Servers
  6. 6. .... </li></ul></ul>
  7. 7. The Beginning... <ul>Single Server Syndrome <li>One Server Many Functions </li><ul><li>Web Server, Database Server, DNS Server, File Server </li></ul></ul>
  8. 8. The Next Step... <ul>Single Separation Syndrome <li>Separation of Web and Database </li><ul><li>Fix the main disk I/O bottleneck. </li></ul><li>However, we can't handle our current I/O on our web server. Let's start there... </li></ul>
  9. 9. Web Servers
  10. 10. Load Balancing Our Environment
  11. 11. Several Options <ul><li>DNS Rotation </li><ul><li>Not very reliable, but works on a small scale. </li></ul><li>Software Based </li><ul><li>Squid, Wackamole, HAProxy, Apache Proxy, Perlbal... </li></ul><li>Hardware Based </li><ul><li>Several vendors ranging based on need. </li></ul></ul>
  12. 12. What We Need to Remember <ul><li>Files </li><ul><li>All web servers need our files.
  13. 13. Static content could be tagged in version control.
  14. 14. Static content may need a file server / CDN / etc.
  15. 15. User Generated content on NFS mount or served from the cloud or a CDN. </li></ul><li>Sessions </li><ul><li>All web servers need access to our sessions.
  16. 16. Remember disk is slow and the database will be a bottleneck. How about distributed caching? </li></ul></ul>
  17. 17. Other Thoughts <ul><li>Running PHP on your web server may be a resource hog, you may want to offload static content requests to nginx, lighttpd or some other lightweight web server. </li><ul><li>Running a proxy to your main web servers works great for hardworking processes. While serving static content from the lightweight server. </li></ul></ul>
  18. 18. Database Servers
  19. 19. Where We All Start <ul>Single Database Server <li>Lots of options and steps as we move forward. </li></ul>
  20. 20. Replication <ul>Single Master, Single Slave <li>Write code that can write to the master and read from the slave. </li><ul><li>Exception: Be smart, don't write to the master and read from the slave on the table you just wrote to. </li></ul></ul>
  21. 21. Multiple Slaves <ul>Single Master, Multiple Slaves <li>It is a great time to start to implement connection pooling. </li></ul>
  22. 22. Multiple Masters <ul>Multiple Master, Multiple Slaves <li>Now we can pool on our masters as well.
  23. 23. Be warned, auto-incrementing now should change so you do not conflict. </li></ul>
  24. 24. Partitioning <ul>Segmenting your Data <li>Vertical Partitioning </li><ul><li>Move less accessed columns, large data columns and columns not likely in the where to other tables. </li></ul><li>Horizontal Partitioning </li><ul><li>Done by moving rows into different tables. </li><ul><li>Based on Range, Date, User or Interlaced </li></ul></ul></ul>
  25. 25. Vertical Partitioning id uri name content 1 / homepage TEXT 2 /contact contact TEXT id uri 1 / 2 /contact id name content 1 homepage TEXT 2 contact TEXT
  26. 26. Horizontal Partitioning id uri name content 1 / homepage TEXT 2 /contact contact TEXT 3 /about about TEXT 4 /services services TEXT id uri name content 1 / homepage TEXT 3 /about about TEXT id uri name content 2 /contact contact TEXT 4 /services services TEXT
  27. 27. Cache Servers
  28. 28. Caching <ul>Speed Up Access <li>Caching is imperative in scaling and performance both. </li><ul><li>Single Server </li><ul><li>APC / Xcache / etc
  29. 29. Not highly scalable, great for configuration files. </li></ul><li>Distributed </li><ul><li>Redvis, Memcached, etc.
  30. 30. Setup consistent hashing. </li></ul></ul><li>Do not cache what cannot be re-created. </li></ul>
  31. 31. Caching <ul>In The Beginning <li>Single Caching Server
  32. 32. Start to cache fetches, invalidate cache on write and write new cache, always reading from the cache. </li></ul>
  33. 33. Distributed Caching <ul>Distributed Mania <li>Write based on consistent hashing (hash of a key that you are writing)
  34. 34. Server depends on the hash.
  35. 35. Hint – use the memcached pecl extension. </li></ul>
  36. 36. The Read / Write Process <ul>In the most simple form... </ul>
  37. 37. Job Servers
  38. 38. Job Servers (Message Queues) <ul><li>Use job servers for asynchronous and synchronous jobs.
  39. 39. Do nothing in real-time if you do not have to. </li><ul><li>Email, Image Resizing, Video Processing, etc. </li></ul><li>Hint – gearman rocks and there is a pecl extension. </li></ul>
  40. 40. Mike Willbanks Blog: Twitter : mwillbanks IRC : lubs on freenode Talk: Questions?