I've spent a lot of time working on making sure my smaller Drupal sites (mostly run on shared hosts or very small VPSes) run lean and mean. This helps the pages load faster, users are happier, and my hosting providers don't have to shut down any of my sites, even when they're under pretty heavy load.
Here are my three recommendations for making your Drupal 7 website run great on a shared (or low-end VPS) host:
- Enable Boost. It's a life-saver.
Boost caches your pages as plain ol' HTML files, so Apache can serve them up almost as quickly as people can request them. This will greatly improve your site's performance if you serve mostly anonymous users. If you care about stats, don't bother with the Statistics or Tracker module (they don't play nice with caching/Boost). Instead, use Google Analytics or another JS-based service. Or use your server's built-in apache log stats (most shared hosts provide AWStats or something similar). - Enable all the performance options on the Configuration > Performance page.
Specifically, check the boxes next to "Cache pages for anonymous users," "Cache blocks," "Compress cached pages," "Aggregate and compress CSS files," and "Aggregate JavaScript files." - Add the rules below to your .htaccess file (if possible).
The rules don't do a ton, but they'll improve front-end performance a little, if your hosting company allows .htaccess overrides (most do). If you use the mod_deflate rule, you don't necessarily need to check the "Compress cached pages" checkbox on the Performance settings page.
Rules to be added to the .htaccess file (I add this little block of code to the top of the file, just under the "Apache/PHP/Drupal settings:" comments):
##### Midwestern Mac-recommended additions #####
# Use mod_deflate to gzip components
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/css application/x-javascript application/javascript text/plain text/html text/xml application/xml
</IfModule>
# Disable ETags (can help if you're using multiple servers, or use cloud hosting)
# see: http_://www.askapache.com/htaccess/apache-speed-etags.html for more info
FileETag None
################################################The last thing I'll mention is that you should definitely consider disabling any module that you're not actively using... and maybe even some that you are. If the module is not essential to your website's core purpose/functionality, consider whether it's more important for pages to load quickly, or for that module's functionality to be present. The less modules, the faster your site will go (and, often, the less cluttered it will be!).
Happy fast page-loading!
P.S. I'm working on a more authoritative Drupal Performance White Paper, on my personal website—I'll be compiling thoughts on performance and Drupal, from the perspective of a guy who maintains many Drupal sites, running on dedicated servers, VPSes, and the cheapest shared hosting available, with varying amounts of traffic/popularity. Check it out!
Comments
Just an FYI: I'm using Boost (and the other recommendations in this article) on this site, to great effect. I have 12 different websites, all with over 500 visitors/day, running on one shared host—a few sites are on Drupal 6, a few on Drupal 7. Boost truly works wonders, if you don't have the time/money to deal with squid caching, reverse proxy, etc...
Thanks for promoting the 7.x version of boost! Good reminder that we (the Drupal community) need to get an anonymous hit tracking working for page caches like boost.
I was simply waiting for the -dev release ;-)
Great job with this essential module! I keep meaning to send a little donation towards development, since it saves me tons of money in hosting costs!
The .htaccess suggestions will actually make your site slower. gzip compression was added to core in this issue:
http://drupal.org/node/101227
Using mod_deflate is slower, because Apache must re-compress each request.
The ETags are also beneficial and should not be disabled, unless you have multiple load-balanced web servers. This is rarely the case for shared hosting. (Although it's likely to become more prevalent in the future, as some providers offer low-priced "grid" or "cloud" based service.)
I often disable core's gzipping, simply because CPU is typically not the holdup in sending out files to end users (at least, not on most of the sites I run on shared hosting), and then enable mod_deflate. I'd rather let drupal/boost focus on generating the files, and leave the compression to Apache.
However, that's why I have a note in my post about leaving the 'compress pages' option unchecked if using mod_deflate.
ETags may or may not be beneficial—as you stated... so I'll put a comment in my code for that. (More reading on ETags here: http://www.askapache.com/htaccess/apache-speed-etags.html).
In terms of etags, yslow has given them a bad rep IMHO. Here is a patch for 7.x boost that needs a lot of testing; it rely's on etags to see if the page has changed. Means if the user comes back to a page that they have already visited and the page hasn't changed, it will then use the browser's cached version of it (304). If it has changed then get a new version of it (200). This should speed up larger pages as the page doesn't have to be downloaded again.
http://drupal.org/node/1070232
Apply the last patch to the 7.x-dev that will come out in 3 hours from now for testing purposes.
What percentage of Drupal performance does the presentation layer impose? In other words, if I were to use a separate MVC Javascript UI framework on the client and only access Drupal through a WebService interface, how would it change the scalability and performance of a Drupal website?
The presentation layer is actually pretty small, I should think. The biggest performance gains come from bypassing database access—and that happens no matter what front-end you use. Caching is very much your friend. APC on the PHP level, and Memcache, MySQL query caching, and HTML caching (varnish, boost, something similar).
We have shared hosting a Drupal 7 and dropped our time by about 50% with boost and other configuration changes. Any suggestion for a shared hosting provider that actually tunes their MySQL and server setup to handle D7 well? As the QA team points out, that is probably the biggest issue: http://qa.drupal.org/performance-tuning-tips-for-D7
Note that the suggestions on the qa.drupal.org post you link to are highly optimized for the testing infrastructure and don't apply to all Drupal site performance evaluations. Especially if you have larger databases, you probably can't just load the db in memory (especially on shared hosting!).
The host I run this site (as well as many others) on is Hot Drupal - they actually do tune their servers for Drupal 6 or 7, specifically.
Also, if you'd like to remove linebreaks (minify HTML) in your page output, replace
print $pagein html.tpl.php with:$output = str_replace(array("\r\n", "\r"), "\n", $page);$lines = explode("\n", $output);
$pageArr= array();
foreach ($lines as $i => $line) {
if(!empty($line))
$pageArr[] = trim($line);
}
print implode($pageArr);
I have used Drupal 7 on AWS through Cloudways platform with Apache, Varnish, Memcached, Nginx and MySQL stack. I am really loving the performance of my websites. Now I am thinking for switching to Drupal 8 for even better performance.
You will get a big performance improvement if you use a CDN.