CHAPTER 23 ■ OPTIMIZING DRUPAL

Disabling Unused Apache Modules

Comment out any Apache LoadModules if it is certain they’re not needed. Such candidates include mod_cgi, mod_dav, and mod_ldap.

Using Nginx Instead of Apache

The more adventurous LAMP admins are substituting Apache with Nginx. Nginx is an excellent generalpurpose server with massive scalability. However, Nginx does not support mod_php—rather, you’re limited to using Fastcgi (php-cgi) to serve PHP requests, which is not a bad choice, just different. Also Nginx does not comprehend Apache htaccess files, so you’ll have to translate any htaccess-specific directives in your Drupal code base, such as Boost cache, into equivalent Nginx configuration directives.

As for which is faster, many would argue in favor of Nginx. But the real bottleneck in any Drupal stack is going to be the PHP or database layer rather than the choice of web server. Nonetheless, Nginx’s strengths make it a good fit as a load balancer (see its http upstream module) and static content server.

Using Pressflow

Pressflow is a drop-in replacement of the standard Drupal core, including many performance enhancements over and above Drupal core. Otherwise, from all outward appearances, Pressflow is entirely the same as Drupal. Many of Pressflow’s features continue to make their way into the Drupal core; however, the folks at Four Kitchens continue to push the envelope when it comes to optimizing Drupal. At the time this book was written, there wasn’t an official release of Pressflow for Drupal 7. For up-to-date information on the features and functionality incorporated into Pressflow, visit www.pressflow.org.

Varnish

Varnish is becoming the darling proxy cache server of the Drupal community. Varnish is a fast and powerful HTTP reverse proxy cache server. A typical Drupal app server may be capable of delivering hundreds of dynamic Drupal pages per minute. Varnish offers the ability to deliver thousands of cached Drupal pages per second! And furthermore, requests served from Varnish generate no load on your backend servers because the cache-delivered requests never reach your back-end servers.

In a typical setup, Varnish is installed to listen on port 80 (the standard web server listening port) so that all web content requests hit Varnish first. Varnish decides whether to serve the request directly from its own cache or echo the request back to back-end web servers. The cache and delivery policies are expressed in the local VCL (Varnish Configuration Language) configuration file.

VCL offers Varnish admins the ability to set very specific cache policies using conditional expressions resembling Javascript. VCL also offers the ability to load balance requests across many backend servers, rewrite requests, change the content of requests, and block requests. Furthermore, VCL language offers the ability to include inline C language for those wanting to manipulate the request delivery process at the lowest levels possible.

Note that Varnish does not support SSL (HTTPS requests) and does not offer separate virtual host configurations in a shared hosting environment; however, in Varnish VCL expressions can be bracketed inside a conditional based on the target host of the request.

506

CHAPTER 23 ■ OPTIMIZING DRUPAL

It’s also worth noting that Varnish is an HTTP write-through cache and not a generic key/value store, and so it’s not a substitute for memcached nor does it offer a direct API for storing and fetching arbitrary data from cache.

Other HTTP proxy cache alternatives include Squid, Apache with mod_cache, and Nginx’s http proxy cache module; however, these options don’t offer the richness of Varnish’s VCL language.

Worth noting is that Varnish is multithreaded, so its scalability is limited to how many Varnish server threads your server can juggle at once. A moderately busy Varnish server may have a few hundred threads running, and a very busy Varnish can peak at just over a thousand threads. If your Varnish is not able to spawn more threads, then additional requests to your web site will be met with “Connection reset” errors.

To allow Varnish to spawn more threads, edit the Varnish startup scripts to adjust the -w options (worker thread pool options) passed to the Varnish start command. The second parameter passed into the -w option is the maximum number of threads Varnish can spawn. Increase that setting to at least 4000.

Secondly, on Linux systems, each thread is allocated 8MB of virtual memory by default, which is far more than any Varnish thread will require. So in your Varnish startup script, you’ll want to add the command “ulimit -s 512” to decrease the default stack space per thread to 512KB.

Normalizing incoming requests for better Varnish hits

The key to achieving good Varnish cache hits rates is to normalize the incoming HTTP requests so that all anonymous requests for the same URL get the same cache hit from Varnish.

To understand Varnish cache coherency you must first understand how Varnish stores cache entries for each URL. Varnish combines the following incoming request attributes into a hash key which it uses to store and lookup its cache entries:

request URL

incoming Host header

incoming Cookie header

incoming Accept-Encoding header

The issue here is that the Cookie header and the Accept-Encoding header vary from browser to browser. For example, it is highly likely that the variety of browsers hitting your web site have different cookies and thus different Cookie headers. To address the variance of incoming Cookie headers you'll want to (at best) remove the entire incoming Cookie header during the vcl_recv phase of your Varnish config, like so:

sub vcl_recv {

#Remove the incoming Cookie header from anonymous requests if (req.http.Cookie !~ "(^|;\s*)SESS") {

unset req.http.Cookie;

}

#... other vcl_recv rules here ...

#Don't serve cached content to logged-in users if(req.http.cookie ~ "SESS") {

return(pass);

}

507

p