Drupalcon 2009 scalability
Jump to navigation
Jump to search
- look at hourly hit traffic - design for peak traffic
- 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"
- static content, dynamic cacheable, and dynamic
- content delivery network, reverse proxy cache, drupal + page cache+ memcache, drupal + pagecache, drupal
- design your architecture deliver the fastest hits
- 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
- apache solr for serach
- squid or varnish (better) for reverse proxy caching - generally
- at least one management box - probe services fairly deeply
- 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
- Nagios - monitor for failures. highly recommended tool, drupal.org, wikipedia, easy to install NRPE agents, responds to requests from nagios for statistics - good notifications
- Cacti - graphs and templates - collects statistics