Time to revisit the different types of Drupal sites to see where gains can be made. What type of site do you have? This quick reference recaps the previous articles and lists the areas where different types of Drupal sites can improve performance.

All Sites

• Get the best server for your budget and requirements.
• Enable CSS and JS optimization in Drupal
• Enable compression in Drupal
• Enable Drupal page cache and consider Boost
• Install APC if available
• Ensure no slow queries from rouge modules
• Tune MySQL for decent query cache and key buffer
• Optimize file size where possible

Server: Low resources

• Boost stops PHP load and Bootstrap
• Sensible module selection
• Avoid node load in views lists
• Smaller JVMs possibly if running Solr
• Nginx smaller than Apache
• mod_fcgid has smaller footprint over mod_php

Server: Farm

• Split off Solr
• Split off DB server, watch the latency
• With Cache Router select Memcache over APC for shared pools
• Master + slaves for DB
• Load balancing across web servers

Size: Many Nodes

• Buy more RAM for database indexes
• Index columns, especially for views
• Thoroughly check slow queries
• Warm up database
• Swap in Solr for search
• Solr to handle taxonomy pages

Activity: Many requests

• Boost or
• Pressflow and Varnish
• Nginx over Apache
• InnoDB on cache tables

Users: Mainly logged in

• View/Block caching
• CacheRouter (APC or Memcache)

Contention: Many Writes

• InnoDB
• Watchdog to file

Content: Heavy

• Optimized files
• Well positioned server
• CDN

Functionality: Rich

• Well behaved modules
• Not too many modules
• View/Block caching

Page browsing: Dispersed

• Boost over Varnish if RAM is tight

Audience: Dispersed

• CDN

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.

The time for a page to render in a user’s browser is comprised of two factors. The first is the time it takes to build a page on the server. The second is the time it takes to send and render the page with all the contained components. This guide has mainly been concerned with the former – how to get the most from your server, however, it is estimated that 80% to 90% of page rendering time is taken up during the rendering phase.

It’s no good to serve a cached page in the blink of an eye if there are countless included files which need to be requested and many large images which need to be transported across the globe. Optimizing page rendering time can make a noticeable difference to the user and is the cream on the cake of a well optimized site. It is therefore important to consider and optimize this final leg of the journey.

Improving Drupal’s page loading performance

Wim Leers covers all the bases on how to improve loading performance.

High Performance Web Sites: Essential Knowledge for Front-End Engineers

Steve Souders, Chief Performance Yahoo! and author of YSlow extension, covers the Yahoo recommedations in this book.

High Even Faster Web Sites: Performance Best Practices for Web Developers

Another Steve Souders book covering Javascript (AJAX), Network (Image compression, chuncked encoding) and browser (CSS selectors, etc).

It is worthwhile reviewing Yahoo’s YSlow recommendations to see all of the optimizations which are possible. We cover selected areas where the default Drupal install can be improved upon.

Minimize HTTP Requests

Combined Files

The Out of The Box section covered the inbuilt CSS and JS aggregation and file compression. The use of “combined files” is a significant factor in Drupal’s relatively good score in the YSlow tests. Make sure you have this enabled.

All sites: Enable CSS and JS aggregation.

CSS Sprites

CSS Image Sprites are another method of cutting down the number of requests. This approach combines a number of smaller images into one large one which is then selectively displayed to the user through the use of background offset in CSS. It is a useful approach for thing such as small icons which can have a relatively large amount of HTTP overhead for each request. Something for the theme designers to consider.

Custom designs: Use CSS sprites if appropriate.

CSS Sprites: Image Slicing’s Kiss of Death

Overview of how CSS sprites work and how they can be used.

A lesson in the usefulness of CSS sprite generators

Covers commonly used spite generators.

Use a Content Delivery Network (CDN)

This is the number two recommended best practice.

A content delivery network (CDN) is a collection of web servers distributed across multiple locations to deliver content more efficiently to users. The server selected for delivering content to a specific user is typically based on a measure of network proximity. For example, the server with the fewest network hops or the server with the quickest response time is chosen.
http://developer.yahoo.com/performance/rules.html#cdn

Of all the CDN web services SimpleCDN seems to be getting positive press amongst Drupal folks as it is simple and cheap. It offers the “origin pull” Mirror Buckets service which will serve content from 3.9 cents to 1.9 cents per GB. At this price you will probably be saving money on your bandwidth costs as well as serving content faster.

The CDN integration module is the recommended module to use for integration with content delivery networks as it supports “origin pull” as well as push methods. It supports content delivery for a all CSS, JS, and image files (including ImageCache).

High traffic, geographically dispersed: use CDN

CDN integration module

Wim Leers’ fully featured module which integrates with a wide range of CDN servers.

SimpleCDN module

Simple CDN re-writes the URL of certain website elements (which can be extended using plugins) for use with a CDN Mirror service.

Drupal CDN integration: easier, more flexible and faster!

Slides covering advantages of CDNs and possible implementations.

mod_cdn

Apache2 module which shows some promise but not much info available for it with regards to Drupal.

Best Drupal CDN module?

Drupal Groups discussion.

On a related note many sites can benefit from judicial placement of the server if traffic tends to come from one place and no CDN is being used. Sites based out of the US may find the proximity of a site hosted in their area worth the extra cost of hosting.

Add Expires Headers

When a file is served by a web server an “Expires” header can be sent back to the client telling it that the content being sent will expire at a certain date in the future and that the content may be cached until that time. This speeds up page rendering because the client doesn’t have to send a GET request to see if the file has been modified.

By default the .htaccess file in the root of Drupal contains rules which sets a two week expiry for all files (CSS, JS, PNG, JPG, GIF) except for HTML which are considered to be dynamic and therefore not cachable.


# Requires mod_expires to be enabled.

# Enable expirations.
ExpiresActive On
# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600
# Do not cache dynamically generated pages.
ExpiresByType text/html A1



The Expires header will not be generated unless you have mod_expires enabled in Apache. To make sure it is enabled in Apache2 run the following as admin.


# a2enmod expires
# /etc/init.d/apache2 restart


Ensuring this is enabled will elevate your YSlow score by about 10 points or so.

All sites: Configue Apache correctly for fewer requests.

Gzip components

You can Gzip by enabling compression in the performance area of admin. Alternatively you could configure Apache to do it.

All Sites: Enable Gzip compression

Optimize Images

Binary files do not shrink significantly after Gzip compression. Gains can be made by ensuring that rich media such as images, audio and video are (i) targeted for the correct display resolution and (ii) have an appropriate amount of lossy compression applied. Since these files will generally only be downloaded once they do not benefit from caching in the client and so care must be taken to ensure that they are as small as reasonably possible.

All Sites: Compress binary files

Pngcrush

Pngcrush is an optimizer for PNG (Portable Network Graphics) files. It can be run from a commandline in an MSDOS window, or from a UNIX or LINUX commandline.

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.

Benchmarking a system is a reliable way to compare one setup with another and is particularly helpful when comparing different server configurations. We cover a few simple ways to benchmark a Drupal website.

A performant system is not just one which is fast for a single request. You also need to consider how the system performs under stress (many requests) and how stable the system is (memory). Bechmarking with tools such as ab allows you to stress the server with many concurrent requests to replicate traffic when a site is being slashdotted. With a more customised setup they can also be used in more sophisticated ways to mimic traffic across a whole site.

Benchmarking and profiling Drupal

Documentation which covers tools of the trade including Apache Bench (ab) and SIEGE.

Apache Bench (ab)

ab is the most commonly used benchmarking tool in the community. It shows you have many requests per second your site is capable of serving. Concurrency can be set to 1 to get end to end speed results or increased to get a more realistic load for your site. Look to the “failed requests” and “request per second” results.

In order to test the speed of a single page, turn off page caching and run ab with concurrency of one to get a baseline.

ab -n 1000 -c 1 http://drupal6/node/1

To check scalability turn on the page cache and ramp up concurrent connections (10 to 50) to see how much the server can handle. You should also make sure keep alives are turned (-k) on as this leads to a more realistic result for a typical web browser. At higher concurrency levels making new connections can be a bottleneck. Also, set compression headers (-H) as most clients will support this feature.

ab -n 1000 -c 10 -k -H 'Accept-Encoding: gzip,deflate' http://drupal6/node/1

Drupal Performance Measurement & Benchmarking

Testing with ab and simple changes you can make within Drupal.

On Drupal Performance: Testing with Apache Benchmark

Covers server side tools and walks through ab options and use.

Benchmarking Authenticated Drupal Users with ApacheBench

Demonstrates how to pull out current session id and how to pass that to ab so that authenticated users can be tested.

Has anyone tried nginx caching with Drupal?

Illustrative discussion where different Drupal setups are benchmarked with ab.

JMeter

JMeter is a Java desktop app designed to test function and performance. It is the preferred testing tool of many administrators.

Drupal-Performance-Testing-Suite

Perl script which runs a JMeter test on Drupal and provides graphs.

jmeter scripts to test server performance

Some scripts to get you started testing with JMeter.

Thoughts on benchmarking

Benchmarking is essential if you wish to have an objective comparison between different setups. However, it is not the final measurement with regards to performance. Remember that page rendering times are what are important for users and that too needs to be optimized. Also, benchmarks tend to be artificial in the sense that they often measure unrealistic situations. Will all of your requests be for one anonymous page only? Maybe in the Slashdot situation but there are other considerations obviously. Finally, it is easy to focus intently on the number, especially when it comes to caching scores, and forget that minor differences may not make so much of a difference to real life scenarios. Don’t forget the logged in user.

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.

There are a couple of projects which have made it easy to achieve performance gains by making slight amendments to core or packaging up the code in a helpful manner. Pressflow makes it possible to use a reverse proxy such as Varnish, amongst other things. Mercury packages Pressflow up as a Amazon EC2 image. The development of both these projects is the sign of a maturing ecosystem where serious deployments can easily be rolled out.

Pressflow

Pressflow is a distribution which attempts to bring many of the improvements discussed above (SQL improvements, Varnish) into a single package. Pressflow is a standard Drupal install which has had its core modified to fix bottlenecks and facilitate the use of advanced caching features. FourKitchens don’t regard Pressflow as a fork since many of the initiatives found in Pressflow are contributed back into the development of the head of Drupal.

So long as you haven’t hacked core yourself then using Pressflow is a simple matter of swapping out core drupal and replacing it with Pressflow.

In a nutshell Pressflow allows the following:

• Support for database replication
• Support for Squid and Varnish reverse proxy caching
• Optimization for MySQL
• Optimization for PHP 5

High Traffic, Varnish required: Easy setup.

Pressflow makes Drupal scale

Announcement covering the advantages and features of Pressflow.

Project Mercury

Project Mercury is an innovative project from Chapter Three which wraps up a tricked out PressFlow installation in to a preconfigured Amazon Machine Image (AMI) for use on Amazon EC2 instances.

The Pantheon Project Blazes Ahead

Hot of the press: Mercury will also be available for deployment on other servers, not just EC2. Further there will be a Mercury On Demand service at Rackspace.

The goal of this project is to make Drupal as fast as possible for as many people as possible. To that end, we are developing a pre-built Amazon Machine Image (AMI) which will allow anyone with an Amazon Web Services account to spin up an EC2 instance and see how all this works in real-time. The ultimate goal is a production-ready release that can be used for deploying real websites.

If you want to get started using the image all you need to do is signup to Amazon Web Services and then start up an instance of your choosing. You know are in control of a fully configured, scalable server. This sounds easy in practice, however, if you are considering going down this path there are a couple of considerations:

• Amazon is not the cheapest provider of bandwidth, RAM and storage. Other virtual servers have better deals. You are paying for the ability to spawn servers on the fly
• Persistent storage is an issue which needs to be overcome and managed if scaling out your web server.
• There a bit of a learning curve with some of the tricks of the trade when managing the servers.

Project Mercury and EC2 is a worthy combination if you really need the ability to serve massive amounts of traffic and also have the ability to temporarily scale out during peak times.

Project Mercury Benchmarks: 2000+ Requests Per Second!

Drupal is fast with APC + Page Cache. It is very fast with PressFlow and Varnish. NB. It would have been interesting to see how Boost went against Varnish for this test.

The configuration chosen by the project is interesting because it shows how other sites might go about setting up a scalable server. in brief the setup is as follows:

• Ubuntu 32 or 64 bit
• Pressflow
• APC for opcode cache
• CacheRouter and APC/Memcached for No SQL caches
• Varnish as reverse proxy

High Traffic, Varnish required, EC2 required: Easy setup considering.

Step-by-step: Setting up Varnish, Apache, APC and Solr Project Mercury Style

Step by step instructions for setting up Project Mercury on a Ubuntu server. Very helpful for admins wishing to install manually on their own server.

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.

Several advanced options exist to take caching to the next level in Drupal. With advanced caching Drupal is able to scale to levels required by the most demanding of sites.

We have already discussed (i) page and block caching and (ii) other caches which come baked into the core of Drupal in the Out of the Box section. Whilst big gains can be made through enabling simple config options it is possible to make several more improvements to the way Drupal caches and serves data, making Drupal a system which can scale to serve 1000s of requests a second if the need arises.

Page Caching

The Bootstrap

Every time Drupal code needs to be run either through a web page or script, Drupal must undertake the boostrap process which has a certain amount of overhead. Generally this process cannot be avoided – you need to run code after all. However, there are a couple of cases where it is possible. Firstly, Normal Page caching avoids much of the bootstrap save for hook_boot() and hook_exit() hooks which are used by the statistics and throttle modules. Secondly, Aggressive Page Caching allows for all of the bootstrap to be avoided when serving content. Finally, contributed modules such as Boost and Varnish allow for the avoidance of PHP and bootstrap since they are operating at a stage before PHP is invoked. This is the main reason Boost and Varnish are so attractive as a page cache.

Boost

Boost is a page cache which works in a similar way to aggressive page caching in that it attempts to serve cached data without running the bootstrap. However, it is able to go one step further and avoid PHP being run as the redirect takes place in rewrite rules located in .htaccess. If the static file exists then it is served as the response. The end result is super fast response without running PHP or the bootstrap. This frees up the server to handle more requests from logged in users.

Boost is an attractive module because it is easy to install, has a lot of configuration options which give good control over cache building and invalidation. It is highly recommended.

One aspect of Boost which may be forgotten is that it isn’t an entirely a file based solution. If the operating system file cache is working well then there is a good chance that the “file” will come out of RAM rather than off disk. This makes Boost a competitive option when compared to other more complicated reverse proxy setups such as Squid or Varnish.

Because Boost is file based it is able to potentially cache a lot more data than a RAM based solution. If you have thousands or millions of pages to cache putting them all in RAM is probably not optimal. Best to put them on disk and save the RAM for DB indexes or possibly a CacheRouter cache.

All sites, especially big, infrequently changing, high traffic: Big gains. Easy setup.

Varnish

The Varnish HTTP Accelerator Integration module integrates Drupal with Varnish, a reverse proxy which sits in front of Apache, PHP and Drupal. Varnish stores cached content in RAM and avoids the overhead of Apache and the Drupal bootstrap. As such it offers very high performance for anonymous users on cached pages and is the preferred option for many sites where scaling is paramount.

Varnish requires either a patch to core to add HTTP headers, PressFlow or Drupal 7. Most people are therefore running Varnish in conjunction with PressFlow.

High Traffic: Big gains when performance critical.

Squid

Squid is a reverse proxy similar to Varnish and is in use on drupal.org. It doesn’t seem to be such a commonly deployed solution probably because PressFlow has been altered to work with Varnish which is higher performing apparently.

Varnish preferred over Squid.

Varnish vs Boost

A popular thread High Performance Drupal group is for the perfect recipe for page caching – whether to use Varnish or Boost. Varnish has the edge in speed over Apache+Boost as well as Nginx+Boost. Look at results published by brianmercer.

Varnish may have the edge in speed but it is more complex to install and requires a patched core. Some people may not want to run a non standard Drupal installation. Varnish also requires RAM to store the cached material – something which may be better spent elsewhere (database or max clients). Boost offers similar performance, is easy to install and has good control of cache invalidation and warmup. Boost is also able to serve files from RAM if the OS has cached them.

It is certainly up to you to decide which avenue to take. This guide is attracted to the relative simplicity of Drupal + Nginx + Boost over Pressflow + Varnish + Apache/Nginx. Nginx brings better performance to the web server as a whole, ie. pages not in the cache, and RAM savings if it is needed elsewhere. It must be stressed that each site has a different profile and the ultimate decision is up to you.

Has anyone tried nginx caching with Drupal?

Drupal Groups thread with lots of benchmarking. Final conclusion seems to be that Varnish vs Boost+Nginx is a pretty close thing.

Project Mercury: A pre-configured Drupal+Varnish EC2 AMI

Josh Konig of Chapter Three claims that Varnish is faster than Boost but gives no numbers.

Quick Drupal Cacherouter and Boost benchmarks

Dylan Tack likes Boost: “Response times are all close enough that it doesn’t really matter what caching backend you choose… The only factor that’s really relevant is how good your system’s cache expiration and regeneration logic is… it seems like Boost is the clear winner here as well.”

What’ recipe should i choose for best performance?

Discussion with participants split between Varnish and Boost depending on circumstances. Nginx+Boost seems pretty equal with Varnish.

Caching: Modules that make Drupal scale

Table of modules, performance gains and features.

Cache Router

Cache Router is a module which enables you to cache the Drupal cache tables (including views, blocks, menus, variables, and filters) in RAM. Drupal no longer has to hit the database to pull out this content – a big win for logged in users who might not be able to enjoy the advantages of a page cache. Cache Router therefore fills an important niche in your caching strategy.

Cache Router is able to do this via a number of backends including APC or Memcache. APC should be considered if you are running Drupal on a single node and only need the single local store. According to Josh Konig, APC “is less error-prone, more secure, and allegedly as fast (if not faster) than running memcached according to the folks at Facebook.” Memcache can be used to share cached data between or across multiple servers.

High Traffic, Logged in: Massive gains when page cache not hit.

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.

Sometimes your installation will be slow for no apparent reason. Time to grab your toolkit and get started on finding and eliminating the problem. Here are some of the common problems faced by developers.

Database Queries

The database is generally the first place you look when trying to identify problems on a page. It is possible to identify problems through MySQl’s slow query log or through the query log of the Devel module.

High Performance MySQL: Optimization, Backups, Replication, and More

Must have book for anyone serious about getting the most from MySQL.

Views and indexes

The Views module makes building queries easy and sometimes a crucial part of the query will rely on a CCK column with no index. This tends to happen with sorting or filtering. Queries can run slow in these cases. The solution is to place an index on the column in question.

Large Sites: CCK need index

Views and Left Joins

The Views module will often design queries with LEFT JOIN rather than INNER JOIN, especially when joining from the node table to a content type CCK table. In many cases you might only want an inner join, especially when the node table is very big. In these cases it is possible to rewrite the query by hacking the query in hook_views_pre_execute.

Large Sites: Some View SQL inefficient

Ability to INNER JOIN to node for a specific field

Discussion of Views SQL for joining between node and content type tables.

Inefficient schema

The database design of some modules could possibly be improved. It is up to you the developer/administrator to ensure that you are happy with the internal design of contributed modules. If you find an inefficiency then submit an issue to the module, provide a patch or remove the module from your site.

Composite indexes

MySQL is limited to using one index per table when sorting and filtering. This can make it tricky when you wish to use multiple AND clauses or involve a sort and a filter at the same time. In these cases adding a composite index can get you out of trouble.

Problems in Core

In a number of cases there are problems in core of Drupal where queries are very slow on very big Drupal installations with millions of nodes. The author has experienced problems with:

• Inability to browse content in Admin section due to join from member to user table
• Inability to edit nodes with many CCK fields. Massive RAM usage when loading nodes.
• Taxonomy pages take a very long time to display
• Search system unable to index content

These problems can be avoided partly by swapping Solr in for search and having it override the taxonomy pages. The other problems you just have to live with

Drupal with millions of nodes

Some good research from Wesley Tanaka into problems with many nodes. Attitude from some here seems a little dismissive of the issues.

Slow Modules

Modules can also be badly written leading to poor performance in certain circumstances. Generally this happens when the module’s creator did not test the module against (i) large installations with many nodes (ii) complex installations with heavy nodes or detailed taxonomies. You generally will only run into these problems if your site is large. In some cases you can fix the module by creating more indexes in the DB. In others you just have to remove the module from your installation…. or submit a patch.

Some known offenders for large sites include:

• XML Sitemap
• Node access
• Taxonomy Browser
• Fivestar

How Drupal’s node_access table can negatively impact site performance

Scalability of the Taxonomy Browser module: Restricting number of terms

“Query from hell” with many joins leading to queries which never finish.

XML Sitemap 6.x-2.x: How Drupal modules can overload a site during cron, with solutions

XML Sitemap module needs to be configured correctly

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.

Bad performance can be down to decisions you have made during development because you haven’t been aware of natural limitations of the system or the way Drupal works. The more you poke about the more you will understand. Here’s a grab bag of things which may bite you.

Search

The search which comes inbuilt with Drupal has long been regraded as unsatisfactory for larger sites:

• failure to index large sites efficiently
• slow at returning results
• relatively limited feature set compared to dedicated search solutions

Part of the problem lies with the fact that standard relational databases such as MySQL and interpreted languages such as PHP are not well suited to handle the large indexes and filtering required for big datasets. Search can also be an intensive process if the corpus is large and the traffic high. Being able to move search off the main box will give more resources to Drupal to do other things. Both of the following solutions can help solve these issues.

Solr

Enter the Apache Lucene project and Apache Solr.

Welcome to Lucene!

Lucene “provides Java-based indexing and search technology, as well as spellchecking, hit highlighting and advanced analysis/tokenization capabilities.”

Welcome to Solr

“Solr is the popular, blazing fast open source enterprise search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search, dynamic clustering, database integration, and rich document (e.g., Word, PDF) handling. Solr is highly scalable, providing distributed search and index replication, and it powers the search and navigation features of many of the world’s largest internet sites”

The Apache Solr Search Integration module integrates Solr with Drupal. Installation requires a setup of a JVM and a container such as Tomcat or Jetty – something which is a little outside the usual LAMP configuration. Installation is not so difficult with some good documentation available. If this is beyond you then it may be worth checking out the Acquia Search hosted solution.

The beauty of Solr is that it is able to index massive datasets, millions if not 100s of millions of nodes, and return results surprisingly quickly. The faceted search (taxonomy, language, CCK, Author, Content Type) is its main selling point which will be sure to impress users. It really is a product which will take your site to the next level if search is important to you. More importantly Solr solves crippling scaling problems with core search as well as viewing taxonomy terms with many nodes.

Check out the following search for “Madonna” filtered by “Artistic Works” type and “English” language. Alternatively, here is Madonna filtered by “Person” type and “Italian” language. Italians do it better.

Solr is a natural fit for installation on another server because it runs as a web service over HTTP. This is a very easy way to take load of your main server, especially if search is a big part of your site. The disk requirements of the index and Java memory requirements for Solr can be significant on big sites so moving it off the main server may well be a necessity. My experience on Uriverse (a large amount of smallish nodes) would suggest that each node takes around 200 bytes of RAM in the JVM. Your requirements could vary dramatically from this but this may be helpful as a rough guide for those wanting to know about RAM consumption.

Large sites: Core search fails. Solr shines.

SolrPerformanceFactors

Solr documentation including optimization.

Scaling Lucene and Solr

Some very good notes on scaling Solr. File system cache is important as well as JVM and need 2+GB on top of JVM for big index.

how to reduce solr memory usage?

Smaller documents, less facets, no sorting.

How much disk space does optimize really take

Be careful of optimize – required disk space can double.

Google Custom Search

Another option for those users looking to switch away from the in-built search is Google Custom Search – a search service offered by Google where Google indexes your data and stores the results on their servers. You are able to search the data via a simple form on your site. Google Custom Search is free for individuals, who don’t mind ads with their results, with a business version starting at $100 pa. The Google Custom Search Module integrates it into Drupal by providing a block with the form.

Module bloat

Every module you add to a Drupal site leads to the consumption of more RAM reducing the number of simultaneous clients you can server. Modules also consume extra CPU. As a site designer you need to be aware that all modules added will have some cost on the performance of your site. Is the extra functionality worth the performance cost?

Server indigestion: The Drupal contributed modules “open buffet binge” syndrome

Minimal install of Drupal has Apache process around 17MB-33M. A bloated system has 93M bloating to 100MB after a few requests. This means fewer requests can be handled due to RAM consumption.

Feature rich sites: RAM wasted. Low max clients.

Node load

The loading of a node in Drupal can be a very quick/light or very slow/heavy process depending on the circumstances. It all comes down to (i) how much data is in the node and (ii) how fast that data comes back out of the database. If you have nodes with many CCK fields sitting in a database which hasn’t been able to cache all of the necessary indexes, a node load is something which you really want to avoid. Instead of lazily loading data when required a node load loads it all in at once! In extreme cases a node could take seconds to load.

This become a problem when you want to handle many nodes at once, such as when you want to display node teasers in a View for example. If you notice your page slowing down when displaying 50 teasers on a view then it is a good bet that the DB is getting hammered trying to load in all that data just to display the title, description and url_alias! In these cases skip the teaser and just do it with fields. You should notice a big improvement.

Similarly, performing massive (millions of nodes) imports for new/updated nodes can be prohibitive as well. In these rare cases you need to skip the API and execute SQL on the DB directly.

Many Nodes, Big Nodes: Speed and RAM suffers

CCK design

It’s important to know how to work within the confines of a system to get the most out of it so it is well worth investigating how data is stored in the backend for nodes and CCK fields. Smart, sensible design of CCK fields should ensure that database access is kept to a sensible level. Whilst this guide recommends designing a data model first and then worrying about data access times second, it is worth knowing the consequences of your decisions.

In a nutshell, CCK will create another table in the backend for multi fields and fields which are shared between content types. There’s no avoiding the first reason but in the case of shared fields, a separate DB query will need to be run for each shared property. This can be an issue on very large sites on nodes with a lot of properties when you want to keep DB queries to a minimum.

A couple of rules of thumb would be:

• Try to keep the properties of a content type encapsulated to that particular content type. eg. you might be tempted to share book.author and film.screenwriter in a single CCK field. Unless you are going to be doing queries across both then it makes sense to store the properties separately with their content types.
• If you are going to share properties between content types, then the more sharing that can be done the better. eg. a ‘geo-location’, ‘country’, ‘intended-audience’ are all possible candidates for stretching across several content types. This design is views friendly, aiding efficient queries across multiple content types.
• It is probably better to lean towards designing content types which use taxonomy types and have some null properties instead of creating too many ’sub-class’ content types to do the job. eg. lets say you have two possible types, ‘it-employee’ and ‘accounts-employee’, which share some properties (birthday, address) but not others (preferred-os). It probably would be better to add an employee-type taxonomy to do the sub-classing and have the unshared preferred-os property as optional. This ensures easy filtering using taxonomy and allows for fast employee retrieval from a single table.

Complex Data Model: Inefficient data

Module development

When designing your own modules you should have an eye to efficient design and use caching the Drupal way. Using the Drupal cache mechanism means that the custom caches are available to Cache Router to store in RAM (if appropriate).

It is also possible to use the “static” variable keyword to cache the variable for that particular script.

A beginner’s guide to caching data

Steps module developers can take to cache data the PHP/Drupal way.

Custom Modules: cache data the Drupal way

Keep up to date!

From time to time different point releases are made to Drupal core. Keeping up to date with these patches will not only help you stay secure it may also speed up your site. If you take a look at the SQL patches many of them are ALTER statements which add indexes to the database which could help slow queries on big sites. Further, code inefficiences may be removed through better coding techniques.

Drupal Core updates: Better performance (especially for big sites) and stability.

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.

Getting the most from your Drupal site means getting the most from your server – optimizing the various layers of the the LAMP stack. This includes the filesystem, database, web server, PHP, RAM and CPU. Tuning the LAMP stack is a major subject requiring a lot of study and practice to become proficient. It’s something you will probably never completely master Try Googling lamp performance tune for a few articles to whet your appetite. For now, we’ll cover a few of the major considerations for Drupal, although most of this advice would apply to any PHP web app running on Linux.

Server tuning considerations

Drupal documentation covering the basics.

Tuning LAMP systems, Part 1: Understanding the LAMP architecture

Intermediate article covering LAMP.

Tuning LAMP systems, Part 2: Optimizing Apache and PHP

Intermediate article covering Apache and PHP.

Tuning LAMP systems, Part 3: Tuning your MySQL server

Intermediate article covering MySQL.

Opcode cache

Opcode caches cache the compiled form of a PHP script in shared memory to avoid the overhead of parsing and compiling the code every time the script runs. This saves RAM and reduces script execution time.

Quite a bit of benchmarking has been done in the Drupal and PHP communities between APC, eAccelerator and XCache. eAccelerator may have the edge in raw performance, but it appears that APC is the preferred opcode cache in the Drupal community because it is well maintained and less buggy.

All sites: faster and less RAM. Moderate install.

Drupal web server configurations compared

APC gives 2x to 4x increase in throughput under load. PHP5 is around 10% slower.

PHP op-code caches / accelerators: Drupal large site case study

Op-code caches are a must for large sites serving many pages.

Benchmarking APC vs. eAccelerator using Drupal

eAccelerator is faster and smaller than APC. Both offer around 6x – 7x times speedup over PHP.

High PHP execution times for Drupal, and tuning APC for include_once() performance

Make sure apc.shm_size can fit the whole page else there will be no caching.

Database

There are a number of choices to be made when tuning your MySQL database server. The MySQLTuner script can be helpful for identifying outstanding issues you may be unaware of. It can be run on a functioning production server to see how your database is performing in the wild. It’s possible to take a best guess at config options on your dev machine but you aren’t going to know how things are going to shape up until real users start hitting the DB.

MySQLTuner

Perl script which is able to report on the operation of your MySQL installation and offer suggestions as to what can be fixed.

Tuning MySQL Performance with MySQLTuner

Helpful tutorial.

Storage Engine: InnoDB vs MyISAM

A default install of Drupal 6 installs the DB tables as MyISAM. This will change in Drupal 7 with the default set to InnoDB. A Drupal 6 installation may well have some InnoDB tables as modules may create new tables in the InnoBD engine. Your installation may therefore be a mix between the two engines.

In many places on the web you will read statements such as ‘All high performance Drupal sites run InnoDB”. This is not necessarily so as there are some cases where MyISAM may still be preferred although with recent changes to Drupal core the pendulum has swung to InnoDB as a sensible default.

A list of the main difference between the engines is as follows:/p>

• InnoDB is transactional (better integrity), MyISAM isn’t
• InnoDB more reliable (better recovery), MyISAM can be repaired
• InnoDB has row level locking (better concurrency), MyISAM locks tables
• InnoDB uses clustered indexes (faster access to data), MyISAM indexes just the keys
• InnoDB has a bigger memory footprint

In general, you would consider sticking with MyISAM if

• Memory footprint was an issue. If you have very big indexes which might only just fit into the key buffer then MyISAM could offer faster lookups.
• Most activity is read only.

InnoDB tables definitely should be used for all of the Drupal cache tables since this is where most contention is likely to occur.

Finally, it must be noted that Drupal was written based on the MyISAM engine and as such many queries were not optimized for InnoDB. The SELECT COUNT(*) is particularly slow in InnoDB because it must scan all rows to calculate the count. Many of these shortcomings have been removed in the PressFlow distribution and have since made their way back into core.

All sites: InnoDB for less contention on cache
Most sites: InnoDB for everything else
Big unchanging sites: MyISAM faster reads less RAM

MySQL Engines: MyISAM vs. InnoDB

InnoDB is a good fit for many cases and “in most cases, InnoDB is the correct choice for a Drupal site”. Very good comparison between the two engines.

MySQL InnoDB: performance gains as well as some pitfalls

InnoDB does row level locking but lookup is slower for some slow queries. NB. Pressflow distribution fixes some slow InnoDB queries.

InnoDB vs MyISAM vs Falcon benchmarks – part 1

Myth that MyISAM is faster than InnoDB in all cases.

Which Tables can be converted to InnoDB

High Performance discussion emphasizing that InnoDB should definitely be used for cache tables and complex joins in CCK if memory allows.

MySQL Configuration

There are a number of MySQL config variables which must be tweaked to suit your data. It is impossible to specify one set of options to suit all sites. A few rules of thumb are offered below.

Optimizing the mysqld variables

Clear article with some good rules of thumb for MySQL variables.

Key buffer

If you are running MyISAM tables then the key buffer is a very important variable to set. The key buffer stores table indexes in memory, allowing for fast lookups and joins. For large node, node_version and url_alias tables it is a must to have enough room to fit these tables into memory, otherwise your site will very slow on the most basic of operations: looking up nodes, titles and paths.

One rule of thumb is to set this buffer to somewhere between 25% and 50% of the memory on the server. To determine the best value up front sum the size of all the .MYI files.

MyISAM sites: most queries faster. Essential.

key_buffer_size

Documentation on the use of key_buffer_size.

Query cache

MySQL has a query cache which stores results up to a certain size in memory. The cache is very handy for quickly returning commonly accessed data when all other forms of caching (reverse proxies, page cache, Drupal caches) have not been invoked. Queries which may take sometime return almost instantly.

MySQL’s Query Cache

Covers config and operation of the query cache.

During the development and testing of a site the query cache can catch developers out since a query may appear to be performing quite well the second and subsequent times through. To really test a query you need to fire up mysql client (or phpmyadmin) and add the SQL_NO_CACHE option to the query to see the real time it takes. Don’t be fooled!

Query Cache SELECT Options

Documentation on the use of SQL_NO_CACHE.

The query cache is destroyed if any row in the table is changed and so it cannot be relied upon if tables are changing frequently. The cache shines when the are big tables which don’t change that often. Unless your site has such characteristics it is best to limit it so that it fits small unchanging tables and then some for the most popular queries. Examination of cache hit rates will show you if it needs to be extended or reduced.

query_cache_size

Documentation on the use of query_cache_size.

All sites: common queries faster

InnoDB Buffer Pool Size

If you are running InnoDB tables then it is essential to optimize the InnoDB Buffer Pool Size, increasing the memory to reduce query time. InnoDB is more memory intensive and so the pool will be larger than that used for MyISAM tables. MySQL documentation suggests that the size can be upped to 80% of physical memory. Anymore could lead to swap issues.

InnoDBsites: most queries faster. Essential.

innodb_buffer_pool_size

Documentation on the use of innodb_buffer_pool_size.

Other variables

Other variables worth tweaking include the following. See Optimizing the mysqld variables for more.

• table cache
• sort buffer
• read_rnd_buffer_size
• tmp_table_size

Database Warmup

A warm database will perform much better than a recently started one because its caches and buffers will be primed with keys and data. It therefore makes sense to warm up a DB every time the database is restarted. The best way to do this is to load in the indexes of commonly used tables. This guide recommends loading in node, node_revisions and url_alias. Taxonomy information could be good candidates as well.


USE drupal6;
LOAD INDEX INTO CACHE node;
LOAD INDEX INTO CACHE node_revisions;
LOAD INDEX INTO CACHE url_alias;
LOAD INDEX INTO CACHE term_data;
LOAD INDEX INTO CACHE term_node;


This SQL code can then be put in a script and run when MySQL restarts. It is possible to configure the init_file variable in my.cnf to tell mysql where to find the startup SQL.

init-file = /etc/mysql/init-file.sql

Many nodes: Most queries where index relied upon.

Index Preloading

How to use LOAD INDEX INTO CACHE t1.

init_file

How to use init_file variable to specify startup SQL.

Database Indexes

Indexes on columns can dramatically speed up queries if the columns are used for filtering, sorting or joining. Generally, Drupal has most of the indexes you need covered, however, there are some areas where standard tables can benefit from an additional index. It is recommended that you profile your queries to see where things are slow before adding indexes in a scattergun approach because adding indexes can harm performance if they are not being used properly. You can use MySQL’s slow query log for queries with no index to identify areas for improvement.

mikeytown2 has come up with a list of tables which could do with an index:

• All CCK fields that you use in a view. File Field: create an index on the fid; date: index on date; index on value; etc…
• access: type, mask, status
• comments: timestamp
• node_comment_statistics: comment_count
• menu_links: external, updated, customized, depth
• users: pass, status
• menu_custom: title
• date_format_types: title
• filter_formats: roles
• content_group: weight, type_name, group_name
• term_data: name
• system: name
• imagecache_preset: presetname
• blocks: module, delta
• system: status, type
• content_node_field: type, widget_type

Web server

Apache + MPM Prefork + mod_php is the default web server configuration in the LAMP stack. This combination does consume large amounts of RAM which can be a problem for handling many requests. It can also be quite heavy and slow for serving static content. Many administrators have looked to replace it with other combinations including multithreaded processes (MPM Worker) and external PHP (mod_fcgid) as well as swapping it out completely for another server such as Nginx. This guide has adopted the position that Apache problems can be ameliorated somewhat by removing unneeded modules, running fcgid to connect with PHP and using MPM Worker to enable multithreading per process. However, in some cases this won’t be enough and Nginx is a must.

Apache vs Nginx

Other Drupal users have replaced Apache with faster more lightweight (RAM and CPU) web servers such as Nginx and Lighttpd. Nginx is generally preferred over Lighttpd because of memory leaks in the latter. It is currently possible to run Nginx without losing any functionality in Drupal. Boost, a module based on .htaccess rules, now supports Nginx so it is feasible to run Nginx as the main web server. If you are constrained by CPU or have high loads then this certainly is an option worth considering.

Setting up Nginx is not trivial but it is reasonably straight forward if you are comfortable with compiling and patching. There are some good tutorials on the Web for user who want to do this.

Low resources, High Traffic, Many logged in: Possible to get more for less with Nginx.

Apache vs Nginx : Web Server Performance Deathmatch

“Nginx seems to compete pretty well with Apache and there doesn’t seem like there is a good reason not to use it especially in CPU usage constrained situations (ie. huge traffic, slow machines and etc).”

In reply to kbahey: apache vs nginx

Discussion and results over the pros and cons of Nginx vs various Apache setups.

How to get Drupal working with Nginx

Simple guide for installing and configuring Nginx on a server with only 256MB RAM. Uses FastCGI which may not be preferred method.

NGINX + PHP-FPM + APC = Awesome

“The following guide will walk you through setting up possibly the fastest way to serve PHP known to man…In this article, we’ll be installing nginx http server, PHP with the PHP-FPM patches, as well as APC.”

PHP-FPM – A simple and robust FastCGI Process Manager for PHP

Preferred way of connecting Nginx with PHP. Currently in PHP core for 5.3.2+ but not yet released. Requires patch to PHP 5.2.

Apache: Unneeded modules

It is possible to turn off unneeded modules in Apache to reduce memory footprint. The modules you require depends very much on your setup.

The traditional way of controlling modules in Apache has been through the LoadModule directive in httpd.conf. Ubuntu and Debian do it differently with the /etc.apache2/mods-available directory and the a2enmod command. To list all modules to enable try:


$ sudo a2enmod

$ sudo /etc/init.d/apache2 force-reload


And to see what you have enabled you can do $ sudo a2dismod.

All sites: Good savings in RAM

What Apache2 modules can be disabled?

Lists of modules which should be enabled in Apache2.

Apache threading: MPM Worker (multi threaded) MPM Prefork

The use of MPM Worker allows for the handling of more requests due to multithreading in each process. It has a smaller memory footprint than Prefork and is faster. According to docs, Apache must be compiled with the --with-mpm argument in order to install Worker as “prefork” is the default on Unix systems.

RAM limited: Worker preferable to Prefork.

Compile-Time Configuration Issues

“Choosing an MPM” section covers differences between the two models.

Multi-Processing Modules (MPMs)

Apache documentation on installation.

Installing Apache2 and PHP5 using mod_fcgid

Hey, you don’t have to recompile Apache. Tutorial on how to install MPM Worker using apt-get with Apache2 on Ubuntu. Just the ticket.

mpm-worker versus mpm-prefork, and mod_php versus fastcgi

PreFork and FastCGI is still a win if you find that Worker is unstable due to long downloads as this person did.

Connectors: mod_php, FastCGI, mod_fcgid

The use of mod_php with Apache is the most common setup for calling PHP. mod_php works by embedding PHP into every Apache process. This has the disadvantage of a large memory footprint for each Apache process. FastCGI and mod_fcgid overcomes this problem and reduces resource utilization with no gains in performance.

kbahey lists the disadvantages of mod_php as follows:

• All PHP loaded into the process
• Heavy process even if flat file
• Many processes will hog RAM

Use mod_fcgid for lower memory and DB/Network connections

Drupal webserver configurations compared

The most common, Apache+mod_php is the slowest. Tests conducted with FastCGI which is faster. NB: FastCGI has subsequently suffered from stability issues.

Apache with fcgid: acceptable performance and better resource utilization

Informative article which comes out in favor of mod_fcgid over FastCGI and mod_php. This is the must read article if you wish to attempt fcgid.

Configure Apache for high performance on drupal 6

Some solid comments from kbahey from 2bits regarding stable setup: Apache, MPM Worker, fcgid, APC (code cache), memcache No SQL.

Apache MaxClients

The MaxClients parameter controls how many simultaneous clients Apache is able to serve. If it is set to high RAM will be chewed up and the Machine will go into swap. If it is set to low then your site will be unnecessarily limited by the number of clients it can serve. The setting of this value should be determined after consideration of (i) how much spare RAM is available on the server and (ii) how much RAM each Apache process consumes. Obviously you will want to maximize available RAM through frugal allocation of RAM to MySQL, JVM, etc and minimize the size of Apache process through techniques described above.

2bits provide the following formula:

MaxClients = (Total Memory - Operating System Memory - MySQL memory) / Size Per Apache process.

The only addition this guide would make is that it is important to leave some RAM free for the OS file buffer to allow efficient operation of the OS.

Tuning the Apache MaxClients parameter

How to set MaxClients param.

.htaccess

If you are running Apache then it is possible to either use .htaccess or the apache conf file to specify directives such as rewrite rules, etc. If you use .htaccess then Apache must look for .htaccess rules in the directory hierarchy for every request. This can take some time even if no rules are found. You may consider putting the rules in httpd.conf/apache2.conf if you are looking to eek out the most performance from your site.

.htaccess can slow down site if performance is crucial.

.htaccess vs httpd.conf

Evidence that .htaccess can slow a site by 6.6%.

RAM: A precious resource

Given the above, serious thought should be given to how the RAM on your box is to be divided up. In a nutshell we have the following apps contesting for their fair share:

• The JVM if you are running Solr
• MySQL query cache and key buffers
• Apache processes for client requests
• PHP if it runs outside Apache
• Memcached for holding Drupal caches
• The file system cache

Consider the following when deciding how to divide up your box:

• The JVM needs a certain amount or else Solr will crash.
• MySQL really should have indexes buffered for MyISAM and InnoDB. Use MySQLTuner. If they can’t fit then buy more RAM or (i) reduce max clients and (ii) forget about CacheRouter.
• Apache MaxClients should be set to consume available RAM.
• The file system cache needs to be big enough to allow smooth running of system.

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.

Drupal has a number of features which allow for performance to be improved without the addition of external modules or for complicated configuration by administrators. A slow system can easily be turned into one which performs well under heavy loads.

Firstly, Drupal shortcuts the execution of unneeded code by using an internal caching system which stores results of expensive routines. Secondly, Drupal improves page rendering time by allowing for the aggregation static JS and CSS files. Thirdly, page output can be compressed saving download time. Fourthly, Drupal allows for manual configuration of the caching of Blocks and Pages which can improve performance significantly.

Drupal Core caching system

Drupal comes with a number of in-built caches which store the results of expensive calculations (strings) in the database so that they can be retrieved quickly later on. There are six caches enabled by default: cache, cache_block, cache_menu, cache_filter, cache_form and cache_page. Contributed modules are able to create their own caches for storing data which is handy for module designers. This default cache system provides improved performance across the whole app.

The caching system is pluggable and allows for custom storage engines to be substituted in for the default database implementation. Later in this guide you will see how the Cache Router module is able to swap in memory based storage in place of the database, making the retrieval of cached content that much faster.

All sites: Improved performance across the app. No config.

Aggregate and compress JS and CSS

Drupal’s modular system means that pages can have a large number of CSS and JS includes which results in a lot of client server communication – slowing the page draw time down. The problem can be alleviated by merging the files and then compressing them. This results in less includes and faster downloads. Up to 90% of download time can be attributed to downloading CSS, JS and images so it makes sense to aggregate and compress if possible.

During development it is advisable to keep this option turned off so that CSS and JS errors can be troubleshooted.

All users: Lower render times. One click config.

Minimize HTTP Requests

Yahoo place this at the top of their list for ways to reduce download time. 40%-6-% of users are first time users so client side caching is no help to them. Fewer HTTP requests are.

Page Cache for anonymous users

Pages for anonymous users can be cached, meaning that a full build of the page isn’t necessary for each new request which comes in, providing you with savings in CPU and DB load as well as giving the user much faster response times. This is a massive win for your website, especially if the majority of your page requests are from anonymous users. Basically it can help you survive a Slashdotting. Drupal offers “aggressive” and “normal” options – normal page caching is recommended for most websites. Other options for Page Caching are discussed below.

During development it is advisable to keep this option turned off so that any changes to logic or design can be troubleshooted.

Anonymous users: Big wins in speed and CPU. One click config.

Drupal vs Joomla: performance

An older article comparing Joomla and Drupal. Joomla faster on non-cached pages but caching makes Drupal win.

Block Cache

Enabling the block cache allows finer grained control over cached content. Caching blocks which don’t change frequently will enable speedups for logged in users who need a dynamic page built for them each request.

Logged in users: Moderate wins. Easy to implement.

Drupal guide to caching

Covers the various database tables which store data for Drupal’s caching system.

Page Compression

It is also possible to enable page compression for the pages sent. This will reduce the page size by 50% or more depending on the page. Users requesting big pages on slower connections will love this.

Slow connections: Massive win. Easy to implement.

How to make Drupal run 8.5x faster in 5 minutes…

Page cache provides a 3x speedup.

How I Survived a 2300% Traffic Increase With Drupal

Demonstrates that these out of the box techniques can be very effective even for sites on shared hosting.

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.

Sometimes the server environment must be taken as a given and we must work within the bounds of what has been provided. Moving servers can be a time consuming process and not something you wish to do if it can be avoided. It’s best to make the right decisions up front ensuring you have room to grow if needed. Opting for a shared hosting plan can limit the resources available, the control you have as well as ability to grow.

Shared Hosting

Shared hosting plans are cheap ($5 per month and up) and it is possible to run small to moderate Drupal sites on them successfully if you take a few precautions. However, they do come with limitations which can make performance optimization difficult.

RAM and CPU throttled

Drupal is a system which can be heavy on system resources, especially RAM, and so running it on shared hosting can be a challenge in some situations. In many cases a relatively minimal Drupal install will exceed maximum limits enforced by your hosting company. In these cases you will receive a polite letter telling you to fix your site or else you can upgrade to a dedicated server. Don’t worry. See Out of the box for some quick and easy wins on shared hosting plans.

Servers set up like this often have oversold the box you are hosted on and you will be at the mercy of other users who might be exceeding their allotment. Your performance will be adversely affected in these cases. YMMV.

Limited control

The major downside of shared servers is the limited control you have over the hosting environment, leaving you with relatively few options to improve performance. Luckily Drupal has some handy features built in which make it possible to improve speed, memory and CPU. These are dealt with in more detail below.

It is possible to find good virtual hosting plans for around $20 to $30 a month and it is recommended to give these a try if you desire more control over your installation. You must be comfortable with server admin to do this though so it isn’t everyone’s cup of tea: partitioning, installation, configuration, security, certificates, SVN, backup, mail, monitoring, etc. Linode (contains affiliate id) is well respected in the Drupal community and is often recommended for virtualized servers.

Dedicated and Virtual Hosting

Obviously a lot of options are opened up when you move across from shared hosting to a dedicated or virtual setup. Full access to the server means that you are able to implement all of the options discussed in this guide. You all so have the freedom to implement systems which scale out allowing a number of different configurations, including load balancers, multiple web servers, master-slave databases, memory sharing for caches, etc..

scaling drupal – an open-source infrastructure for high-traffic drupal sites

Incremental recipes for scaling a Drupal server out by adding more hardware: basic install on a single box, splitting off the DB, load balanced multi web servers, redundant load balancers with multi web servers, database clustering.

This guide doesn’t examine these techniques in any detail as it is mostly focused on getting the most performance possible out of a single box. Many Virtual hosts allow your to scale up to a new plan, unlocking more memory, disk and processor without any other system changes.

Comparison of Major VPS Providers

Linode comes out on top again. RAM looks to be the limiting factor here though.

Slicehost vs Linode

Linode comes out ahead in memory/bandwidth/cpu/storage per $.

Another option for those looking to scale their hardware with virtual servers is to go with a service such as Amazon Elastic Compute Cloud (Amazon EC2).

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.

The main difference between EC2 and other virtual solutions such as SliceHost and Linode, is that EC2 is able to scale out to new servers when demand requires it. This could be an attractive option for admins who expect large and fluctuating flows of traffic. Project Mercury is a Pressflow image for deployments to EC2 and is discussed later.

Hosted Drupal

Hosted Drupal is a final option for those who want a great setup with quality management without the maintenance hassles for a monthly fee. As the Drupal community matures hosting solutions are beginning to appear. Hosted plans should offer you a range of scaling options without any further setup required.(If your company isn’t listed here please let me know.)

Acquia Hosting

Acquia offer a highly tuned environment for your apps: cloud based hosting (EC2) with load balancing, redundancy, opcode cache, LAMP tuning and Varnish for high performance and scalability. Starts at $500 per month.

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.