Everyone wants a fast website, especially your users. This session will show you the optimizations you'll need to build a blazing fast Drupal website that can withstand even the largest surge of traffic. Look at real life examples of where traffic spikes brought websites crumbling to their knees, what they did to recover, and what you can do to prevent it. (Some names and details changed to protect the innocent)
Through this interactive session, you will learn you don’t have to be an architecture expert or spend millions to have a fast site with Drupal. It’s all out there. You just have to know how to use it.
Would-be complex concepts like caching, reverse proxies, load testing, and front-end performance will be demonstrated using a range of methods to help you learn and have some fun. The best sessions are those where you can be involved. After all, this is Drupal and we are a community. Let's learn together like we code together.
Join Kenny (and his Nerf arsenal) from the Acquia Client Advisory Team as he covers performance, tuning, and optimization with real world examples and exercises you can use to make your Drupal site faster right from your seat.
Video at archive.org.
Must love fun and be a Drupalist with a need for speed. Intermediate Drupal knowledge is a plus and some understanding of the LAMP stack would be helpful. Examples will be given for both GUI (user-interface) and CLI (command-line) junkies.
Comments
Looking forward to it
Kenny -- I'll have to see if I can scrounge up a Nerf gun, I think there are a few around here. :)
Definitely looking forward to it as I've done some work in this area...one thought for anyone looking to tune or investigate performance on a site is, you have to know your site. I found for one site that was having issues, the database was being written to over 90% of the time -- in most cases, 90% of the database ops are reads. That wasn't a problem, it was just a characteristic of how the site worked, there was a lot of data constantly being pulled in and old data being expired.
Every site is different and may have different solutions to its issues. You need to use the tools out there to profile the site and determine just what is going on. There are basic things you can do to improve performance on any Drupal site, but beyond that, you will probably need do some careful analysis and investigation to make the changes your specific site requires and get it to the level of performance you want.
Thanks Mike. You're
Thanks Mike. You're absolutely right. Knowledge of the site is first and foremost and I'll be talking about that briefly in the beginning. I'm so psyched you'll be there at DrupalCon. Drink on me. Been way too long. :)
Slides
Are you going to put slides up?
Thanks.
Comments
Add indexes to views that use joins: http://drupal.org/project/dbtuner This can switch you to InnoDB with a click of a button as well.
Stats Alt - Pixel Ping: http://groups.drupal.org/node/94609 Fork of boost's stats code using node.js
Cache get/set in your module - don't use the base "cache" table as this gets nuked on a generic cache clear all; only use "cache" table if you want this (cache clear all to clear this cache) to happen. Bottom of block_schema() has the code for adding in your own cache table to your modules db schema.
CSS/JS Aggregation - http://drupal.org/project/advagg check the readme.txt for more info; still being developed, but very awesome.
Experimental page flushing for reverse proxies - http://drupal.org/project/expire
hook_init doesn't run on a cache_page hit; aggressive or normal.
Biggest difference between Boost and Varnish (not speed in serving pages): Cache clears. Removing files is slow (boost), removing pages from memory is fast (varnish). For most small sites (under 10k nodes), this (varnish vs boost) doesn't matter.
+1 for memcache
Session Slides
Thanks to everyone for coming to the session. Get the slides as a PDF here, http://db.tt/ieNrR9N