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!