Drupalcon 2009 scalability

From Colettapedia
Jump to navigation Jump to search
  1. look at hourly hit traffic - design for peak traffic
  2. different parts of your site can be hosted by different architecture - analyzing hit traffic, custom effort from your architecture every page load? anonymous traffic? "pay wall"
  3. static content, dynamic cacheable, and dynamic
    • content delivery network, reverse proxy cache, drupal + page cache+ memcache, drupal + pagecache, drupal
  4. design your architecture deliver the fastest hits
  5. segment out traffic
    • static content directly loaded out of cdn without hitting our servers "our datacenter"
    • Load balancer, DNS round robin -> servers that figure out they can satisfy request without passing to application layer (apache PHP drupal)
    • offload as much as possible operations made by application layer to master database - offload expensive services, caching, search
  6. apache solr for serach
  7. squid or varnish (better) for reverse proxy caching - generally
  8. at least one management box - probe services fairly deeply
  9. cluster management tool - manage version of app across servers, fast atomic deployment and rollback. Use capistrano - ruby based scripting tool. script what it means to deploy application, define each server's role, change sym-link to latest snapshot
    • have capistrano run drush to do unit testing, generate reports. Be part of deployment tool
  10. Nagios - monitor for failures. highly recommended tool, drupal.org, wikipedia, easy to install NRPE agents, responds to requests from nagios for statistics - good notifications
  11. Cacti - graphs and templates - collects statistics