Speed Up Your Drupal LAMP Stack


These are my notes from a talk at Drupalcamp NYC in December 2011 by Sam Kottler, @samkottler on twitter and skottler on drupal.org.

Let's make the LAMP stack go "Vroom!" This is going to be a really high-level overview of performance.

Benchmarking vs Profiling

When we benchmark something, we're setting a baseline to compare against in the future. We want to say "it was this fast this long ago, and here's how we improved." Whereas profiling is telling what is fast and what is slow.


Has a lot of parameters you can set; I'll cover some basic ones.

  • StartServers: When Apache starts, it runs in the background and manages threads. You set StartServers, and this how many servers it spins up.
  • MinSpareServers: Apache always checks to make sure it has this many servers waiting to start serving requests. A request is when a user clicks on something on your site and requests a new page. Where that request is handled depends on your stack; for example if some of your requests are intercepted by Varnish they will never hit Apache.
  • MaxSpareServers: The maximum number of servers which will be waiting.
  • MaxRequestsPerChild: A child of Apache lives this long and serves this many requests before Apache kills it off.
  • MaxClients: The maximum number of clients Apache can serve at one time.

In the Apache configuration file, prefork and worker are two options. Worker can serve a larger number of requests with a smaller memory footprint but there are some weird quirks.

Don't just set all the numbers really high. Your hardware won't be able to handle it.


There are lots of other options. Percona or MariaDB are two; MariaDB is a fork of MySQLwritten in C++. However, MySQL is still the de-facto standard.

InnoDB vs myISAM

This is a question, at the most basic level, of how long things get locked. myISAM is a database engine that is set per-table, and when it's doing an operation (Insert, update, delete) it locks the whole table. Imagine this on your session table or cache table. This can really back up requests. InnoDB will only block the specific row in the table. In Drupal 7, we are using InnoDB 100% of the time, theoretically.


This is a perl script that will go through your system. Don't do everything it tells you. It produces and output with some really great pointers for optimizing mySQL. It also produces a list of variables to adjust.

Profile your code

  • XHProf
    Run on staging, it profiles your code not your load
  • New Relic
    Say you're having some mySQL performance problems; it will show on a graph and a table the really big issues.

These tools are not really great if you've done this kind of stuff before, but they're great if you're getting started with profiling. New Relic just added server monitoring, so they'll now let you monitor the code running on the system that's backing your code.

Opcode Caching

Reading from the disk sucks. Opcode caches store compiled code in memory, which is faster than any disk operation. This is really important when you have a small PHP application, but it's even more important in a larger application with crazy dependencies like Drupal. You can see a substantial improvement in performance, especially under load.

It's really easy to install APC, you can just run pecl install apc. Drupal.org has an APC module which shows you stats.


Follow the Rabbits: Use memcached and Varnish. Memcache is very widely used by pretty much every hosting company. Varnish is a reverse proxy cache.

Did you enjoy this post? Please spread the word.