DrupalCon London 2011: DAMN QUICK DRUPAL: HOW TO MAKE DRUPAL PERFORM
Presented by
Michael Cooper
I've often heard folks complain that Drupal doesn't scale well and has issues with performance. You'll hear people saying it isn't suited for large sites, or that it is bloated and too slow. A year ago, after a Drupal site failed abysmally under load (in less than 60 seconds) I was wondering if all of those statements and predictions were true.
As it turned out, I was wrong and oh-so happy to be wrong. To a certain degree Drupal has been a victim of it's own success. The ease with which it can be extended has caused many coders to treat the inner workings as though they were a black box--an attitude that can bring about pain when it comes to light that code added to Drupal doesn't make proper use of all the advanced caching and tuning methods available.
This session is designed to both show how to enhance Drupal's performance drastically, with simple steps and tweaks; as well as provide you with the knowledge about how you can examine what your Drupal site is doing and extend these tweaks and best practices.
I will show you how to serve pages right out of Drupal (no Varnish or other reverse-proxy involved) at under 100ms per page with as many as 100 concurrent users. This course will show you how to make a Drupal site that can serve millions of monthly page-views off just two servers (web and mysql/cache). We'll discuss how to do this on fully anonymous sites as well as sites with high levels of authenticated users.
You'll learn how to make Drupal damn quick.
Intended audience
Coders and system administrators who want to make their Drupal site perform like it is just running core. How to make busy sites run really well on even a single server.
Questions answered by this session
How do I run a busy site with fast page load times
What is the difference between things like APC, memcache, memcached, authcache, boost, etc?
What exactly will pressflow do for my site--both for authenticated and anonymous users
How can I find out what I need to cache most
What are the trade-offs and caveats
Michael Cooper
I've often heard folks complain that Drupal doesn't scale well and has issues with performance. You'll hear people saying it isn't suited for large sites, or that it is bloated and too slow. A year ago, after a Drupal site failed abysmally under load (in less than 60 seconds) I was wondering if all of those statements and predictions were true.
As it turned out, I was wrong and oh-so happy to be wrong. To a certain degree Drupal has been a victim of it's own success. The ease with which it can be extended has caused many coders to treat the inner workings as though they were a black box--an attitude that can bring about pain when it comes to light that code added to Drupal doesn't make proper use of all the advanced caching and tuning methods available.
This session is designed to both show how to enhance Drupal's performance drastically, with simple steps and tweaks; as well as provide you with the knowledge about how you can examine what your Drupal site is doing and extend these tweaks and best practices.
I will show you how to serve pages right out of Drupal (no Varnish or other reverse-proxy involved) at under 100ms per page with as many as 100 concurrent users. This course will show you how to make a Drupal site that can serve millions of monthly page-views off just two servers (web and mysql/cache). We'll discuss how to do this on fully anonymous sites as well as sites with high levels of authenticated users.
You'll learn how to make Drupal damn quick.
Intended audience
Coders and system administrators who want to make their Drupal site perform like it is just running core. How to make busy sites run really well on even a single server.
Questions answered by this session
How do I run a busy site with fast page load times
What is the difference between things like APC, memcache, memcached, authcache, boost, etc?
What exactly will pressflow do for my site--both for authenticated and anonymous users
How can I find out what I need to cache most
What are the trade-offs and caveats