Failure to Launch: Drupal Performance Tuning

Time slot: 
March 9th, 2:15 PM - 3:15 PM
Sheraton 4 & 5
Implementation and Config

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

Intended audience: 

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.

Questions answered by this session
Question 1: 
Why should you care about the performance of your site? Real world examples.
Question 2: 
What is a cache? Exploring the many forms of caching in Drupal.
Question 3: 
What is Pressflow and Varnish? The perfect couple.
Question 4: 
How can I make the site faster right now? Front-end and other Drupal tunings you can do from your seat.
Question 5: 
How do I verify that my changes made a difference? Load testing for everyone.
Failure to Launch: Drupal Performance Tuning has been selected and voting is closed.


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 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. :)


Are you going to put slides up?



Add indexes to views that use joins: This can switch you to InnoDB with a click of a button as well.

Stats Alt - Pixel Ping: 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 - check the readme.txt for more info; still being developed, but very awesome.

Experimental page flushing for reverse proxies -

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,

Diamond Sponsors


Platinum sponsors


Gold Sponsors

Drupal Connect
Treehouse Agency
Chapter Three