Frontend and Backend Optimization
session details: Frontend and Backend Optimization
Front End Optimization
- lost most of my notes! :-( :-( but slides will be online.
- why measure? so you can prove your progress
- what to measure?
- most useful metric is when the page becomes usable -- when the DOM is loaded.
- how to measure?
- Firebug's Net tab
- YSlow plugin for Firebug
- AOL Pagetest
- WebKit.org
- all of these tools will reveal that load time is a small factor compared to request & response time.
- what to do?
- reduce requests! each file is an HTTP request.
- use sprites to reduce background images
- aggregate scripts and styles using Drupal's performance settings
- no redirects! at least not for supporting files
- caching
- use CSS border-radius instead of images for rounded corners
- use a CDN (content delivery network) if possible
- comparatively cheap, starting at $0.07/GB
- reduces round-trip time to server
- controlling browser caching
- with Apache default settings, browsers check each piece of content on each load.
- set expires headers to far future to prevent this
- GZip content (text, not images) often more than 50%
- move all CSS to the <head> for faster loading
- loading CSS later will cause page to flash as it is re-rendered
- move scripts to the end, right before </body>, because loading scripts blocks page rendering.
- for this to work, you can't use any onFoo handlers in page (onClick, et. al.)
- minify CSS and JS
- remove comments and whitespace
- Parallelization
- use multiple host names so browser will request content in parallel
- browsers usually do not have more than 2 connections open to a host at a time
- reduce image weight -- hidden content such as comments in image files -- http://smushit.com and Firefox add-on
- move static content to a cookieless host so that cookies need not be sent with each request
Back End Performance Optimization for Large Sites
- slides will be posted to the session's page after
- "performance" -- faster for individual pages? handle traffic spikes?
- define objectives first
- there will always be diminishing returns, so start with low-hanging fruits
- proper diagnosis is essential
- validate the results on a test server
- multiple cores on server are helpful - the more the better
- throwing RAM at the problem can be very helpful, but only if that's a limiting factor
- same with multiple servers -- setup and maintenance are not cheap.
- tuning a system can avoid or delay a server split, saving a ton of money.
- avoid OS bloat, install only what you need -- if you're using MySQL, remove PostgreSQL
- avoid Apache bloat too -- remove unneeded modules such as Python
- be sure to have mod_gzip running
- lighter-weight alternatives to Apache: lighttpd, nginx
- consider pros & cons of MyISAM vs InnoDB for each table -- use InnoDB for sessions, watchdog
- Query cache is most important thing to tune! also table cache, key buffer
- MySQL replication is effective but difficult until Drupal 7.
- always use a recent version of PHP!
- install an op-code cache / accelerator such as Zend (commercial) or APC (stable) or eAccelerator (fast)
- run PHP as mod_php or FastCGI, not CGI
- drupal-specific tips:
- mainly db intensive, with 100s of queries per page, so tune MySQL first
- make sure cron runs regularly
- use throttle if you can, but be wary of its effect on cache
- try not to call things over the network in your modules! cache data, use job_queue and queue_mail
- caching, but helps anonymous users only. Boost helps a lot, but make sure you truncate sessions after install
- block caching in D6
- memcached helps a lot, but requires a lot of setup
- slow modules: statistics, gsitemap, tagadelic when used with lots of terms, node_access with large numbers of nodes
- to monitor problems: top/htop, vmstat, apachetop, slow query log
- stress testing -- for test servers only!