CHAPTER 23 ■ OPTIMIZING DRUPAL

log messages, stale cache entries, and other statistical data that is otherwise regularly wiped from the system. It’s a good practice to configure cron early on as part of the normal install process. See step seven of Drupal’s INSTALL.txt file for more information on setting up cron.

■ Tip If you are in a critical situation where cron has never been run on a high-traffic site or it simply hasn’t been run often enough, you can perform some of what cron does manually. You can empty the cache tables (TRUNCATE TABLE 'cache', TRUNCATE TABLE 'cache_filter', and TRUNCATE TABLE 'cache_page') at any time, and they will be rebuilt automatically. Also, in a pinch, you can empty the watchdog and sessions tables to try to regain control of a runaway Drupal site. The implications of removing watchdog entries are that you’ll lose any error messages that might indicate problems with the site. If you are concerned about holding on to this data, you can do a database dump of the watchdog table before truncating it. Truncating the sessions table will log out currently logged-in users.

Architectures

The architectures available for Drupal are those of other LAMP-stack software, and the techniques used to scale are applicable to Drupal as well. Thus, we’ll concentrate on the Drupal-specific tips and gotchas for different architectures.

Single Server

This is the simplest architecture. The web server and the database run on the same server. The server may be a shared host or a dedicated host. Although many small Drupal sites run happily on shared hosting, serious web hosting that expects to scale should take place on a dedicated host.

With single-server architecture, configuration is simple, as everything is still done on one server. Likewise, communication between the web server and the database is fast, because there is no latency incurred by moving data over a network. Clearly, it’s advantageous to have a multi-core processor, so the web server and database don’t need to jockey as much for processor time.

Separate Database Server

If the database is your bottleneck, a separate and powerful database server may be what you need. Some performance will be lost because of the overhead of sending requests through a network, but scalability will improve.

■ Note Any time you are working with multiple servers, you’ll want to be sure that they are connected via a fast local network.

516

CHAPTER 23 ■ OPTIMIZING DRUPAL

Separate Database Server and a Web Server Cluster

Multiple web servers provide failover and can handle more traffic. The minimum number of computers needed for a cluster is two web servers. Additionally, you need a way to switch traffic between the machines. Should one of the machines stop responding, the rest of the cluster should be able to handle the load.

Load Balancing

Load balancers distribute web traffic among web servers. There are other kinds of load balancers for distributing other resources, such as hard disks and databases, but here, I’m just talking about distributing HTTP requests. In the case of multiple web servers, load balancers allow web services to continue in the face of one web server’s downtime or maintenance.

There are two broad categories of load balancers. Software load balancers are cheaper or even free but tend to have more ongoing maintenance and administrative costs than hardware load balancers. Linux Virtual Server (www.linuxvirtualserver.org/) is one of the most popular Linux load balancers. Hardware load balancers are expensive, since they contain more advanced server switching algorithms, and tend to be more reliable than software-based solutions.

In addition to load balancing, multiple web servers introduce several complications, primarily file uploading and keeping the code base consistent across servers.

File Uploads and Synchronization

When Drupal is run on a single web server, uploaded files are typically stored in Drupal’s files directory. The location is configurable at Configuration -> File system. With multiple web servers, the following scenario must be avoided:

1.A user uploads a file on web server A; the database is updated to reflect this.

2.A user views a page on web server B that references the new file. File not found!

Clearly, the answer is to make the file appear on web server B also. There are several approaches.

■ Tip Best practice is to use a distributed, replicating, high-availability file system like GlusterFS or AndrewFS. Rsync gets totally out of hand with more than two web servers and NFS is not high-availability, so both end up being poor recommendations for real production sites.

Using a Shared, Mounted File System

Rather than synchronize multiple web servers, you can deploy a shared, mounted file system, which stores files in a single location on a file server. The web servers can then mount the file server using a protocol like GFS, AFS, or NFS. The advantages of this approach are that cheap additional web servers can be easily added, and resources can be concentrated in a heavy-duty file server with a redundant storage system like RAID 5. The main disadvantage to this system is that there is a single point of failure;

517