How to scale your web app

  • 55,519 views
Uploaded on

Scaling web applications, as present at Barcamp London 2 by George Palmer

Scaling web applications, as present at Barcamp London 2 by George Palmer

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • How do you navigate between pages?
    Are you sure you want to
    Your message goes here
  • Thanks a lot for sharing ~~~
    Are you sure you want to
    Your message goes here
  • Great and interesting slides. Thanks for sharing

    http://www.diyhousepainting.net/
    http://www.diyhousepainting.net/category/walls-painting/
    http://www.diyhousepainting.net/category/wood-painting/
    Are you sure you want to
    Your message goes here
  • nice slides about ruby application, but not sure whether it's still relevant or not.

    bread machine review - kitchenmaster
    Are you sure you want to
    Your message goes here
  • very nice slides!
    http://www.myselfhypnosis.net/
    http://www.mindpowerspecialreport.com/
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
55,519
On Slideshare
0
From Embeds
0
Number of Embeds
13

Actions

Shares
Downloads
1,041
Comments
7
Likes
194

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
  • First barcamp Rails but principles applied elsewhere blog

Transcript

  • 1. How to scale (with ruby on rails) George Palmer [email_address] 3dogsbark.com
  • 2. Overview
    • One server
    • Two servers
    • Scaling the database
    • Scaling the web server
    • User clusters
    • Final architecture
    • Caching
    • Cached architecture
    • Links
    • Questions
  • 3. How you start out
    • Shared Hosting
    • One web server and DB on same machine
    • Application designed for one machine
    • Volume of traffic will depend on host
    DB Web Server Shared Hosting
  • 4. Two servers
    • Possibly still shared hosting
    • Web server and DB on different machine
    • Minimal changes to code
    • Volume of traffic will depend on whether made it to dedicated machines
    DB Web Server
  • 5. Scaling the database (1)
    • DB setup more suited to read intensive applications (MySQL replication)
    • Should be on dedicated hosts
    • Minimal changes to code
    Master DB Web Server Slave Slave Slave
  • 6. Scaling the database (2)
    • DB setup more suited to equal read/write applications (MySQL cluster)
    • Should be on dedicated hosts
    • Minimal changes to code
    Master DB Web Server Master DB MySQL Cluster
  • 7. Scaling the web server
    • Web Server comprises of “Worker threads” that process work as it comes in
    DB Farm Worker thread Worker thread Worker thread Worker thread Web Server
  • 8. Load balancing
    • App Server depends:
      • Rails (Mongrel, FastCGI)
      • PHP
      • J2EE
    • Some changes to code will be required
    DB Farm App Server App Server App Server Load balancer
  • 9. The story so far…
    • App servers continue to scale but the database side is somewhat limited…
    App Server App Server App Server Load balancer Master DB Slave Slave Slave
  • 10. User Clusters
    • For each user registered on the service add a entry to a master database detailing where their user data is stored
      • UserID
      • DB Cluster
      • Basic authorisation details such as username, password, any NLS settings
  • 11. User Clusters (2) App Server Master DB User Cluster 1 User Cluster 2 User clusters are themselves one of the two database setups outlined earlier SELECT * FROM users WHERE username=‘Bob’ AND … user_id=91732db_cluster=2
  • 12. User Clusters (3)
    • ID management becomes an issue
      • Best to use master DB id as user_id in user cluster
      • If let cluster allocate then make sure use offset and increment (not auto_increment)
    • Other DBs such as session must reference a user by id and DB cluster
    • Serious code changes may be required
    • Will want to have ability to move use users between clusters
  • 13. The final architecture
    • As number of app servers grow it’s a good idea to add a database connection manager (eg SQLRelay)
    • Extract out session, search, translation databases onto own machines
    • Use MySQL cluster (or equivalent) for any critical database
      • In replication setup can make a slave a backup master
    • Add a NFS/SAN for static files
  • 14. The final architecture (2) Load balancer Master DB App Server 1 App Server 2 App Server 50 … DB Connection Manager Master DB Session DB Search DB NLS DB Master Slave Slave Slave Master Slave Slave Slave User Cluster 2 User Cluster 1 NFS/SAN
  • 15. Issues
    • Load balancer and database connection manager are single point of failure
      • Easy solved
    • 2PC needed for some operations. For example a user wants to be removed from search database
      • 2PC not supported in rails
    • Rails doesn’t support database switching for a given model
      • Can do explicitly on each request but expensive due to connection establishment overhead
      • Can get round if using connection manager but a proper solution is required (I may write a gem to do this)
  • 16. Making the most of your assets
    • In a lot of web applications a huge % of the hits are read only. Hence the need for caching:
      • Squid
        • A reverse-proxy (or webserver accelerator)
      • Memcached
        • Distributed memory caching solution
  • 17. Squid
    • Lookup of pages is in memory, storing of files is on disk
    • Can act also act as a load balancer
    • Pages can be expired by sending DELETE request to proxy
    Squid App Server 1 App Server 2 NFS/SAN In cache Not in cache …
  • 18. Memcached
    • Location of data is irrespective of physical machine
    • A really nice simple API
      • SET
      • GET
      • DELETE
    • In rails only a fews LOC will make a model cached
    • Also useful for tracking cross machine information – eg dodge user behaviour
    App Server DB Farm Memcached Physical Machine App Server Memcached Physical Machine (Not in memcached)
  • 19. Cached Architecture
    • Introduce Squid
      • Acts as load balancer (note there are higher performing load balancers)
    • Introduce memcached
      • Can go on every machine that has spare memory
        • Best suited to application servers which have high CPU usage but low memory requirements
  • 20. Cached architecture Squid Master DB App Server 1 App Server 2 App Server 50 … DB Connection Manager Master DB Session DB Search DB NLS DB Master Slave Slave Slave Master Slave Slave Slave User Cluster 2 User Cluster 1 NFS/SAN M C M C M C MC=memcached
  • 21. Cached architecture
    • Wikipedia quote a cache hit rate of 78% for squid and 7% for memcached
      • So only 15% of hits actually get to the DB!!
    • Performance is a whole new ball game but we recently gained 15-20% by optimising our rails configuration
      • But don’t get carried away - at some point the time you spend exceeds the money saved
  • 22. Cached architecture – 1 machine Squid Master DB App Server 1 App Server 2 App Server 5 … DB Connection Manager Master DB Session DB Search DB NLS DB Master Slave Slave Slave User Cluster 1 NFS/SAN Memcached Physical Machine
  • 23. How far can it go?
    • For a truly global application, with millions of users - In order of ease:
      • Have a cache on each continent
      • Make user clusters based on user location
        • Distribute the clusters physically around the world
      • Introduce app servers on each continent
      • If you must replicate your site globally then use transaction replication software, eg GoldenGate
  • 24. Useful Links
    • http://www.squid-cache.org/
    • http://www.danga.com/memcached/
    • http://sqlrelay.sourceforge.net/
    • http://railsexpress.de/blog/
  • 25. Questions?