C H A P T E R 2 3

■ ■ ■

Optimizing Drupal

Drupal’s core architecture is lean and written for flexibility. However, the flexibility comes at a price. As the number of modules increases, the complexity of serving a request increases. That means the server has to work harder, and strategies must be implemented to keep Drupal’s legendary snappiness while a site increases in popularity. Properly configured, Drupal can easily survive a spike in visitors. In this chapter, we’ll talk about both performance and scalability. Performance is how quickly your site responds to a request. Scalability has to do with how many simultaneous requests your system can handle and is usually measured in requests per second.

This chapter is divided into two general sections, implementing tools and techniques that will help improve the performance of your site, followed by troubleshooting a slow-performing site. I’ll start with the things that you should do before you get into a situation where your site is performing poorly.

■ Note Thanks to Kurt Gray and the team at Aquia for their valuable input for this chapter

Caching Is the Key to Drupal Performance

The three secrets to optimal Drupal performance are cache, cache, and more cache. Every layer of the Drupal server stack offers its own caching options, and you should familiarize yourself with how to take advantage of all of them. Here’s a list of key areas to consider as you look for opportunities to improve the performance of your site:

PHP opcode cache: Opcode caching is critical and its importance can be understated. There is no good reason for not having an opcode cache other than if you happen to prefer having high server loads and slow page load times. For PHP opcode caches, your choices include APC, XCache, eAccelerator, etc., any of which can easily be installed into your PHP environment. The best practice for opcode cache is APC (drupal.org/project/apc). See Figure 23-1 for an example of a report generated by APC.

Reverse proxy cache: A reverse proxy cache takes a tremendous amount of load off your web servers. A proxy cache is a fast web server that sits in front of your back-end web servers, caching any cacheable content passing through it (as a write-through cache) so that subsequent web requests are served directly from

499

CHAPTER 23 ■ OPTIMIZING DRUPAL

the proxy cache rather than from your back-end servers. I’ll talk about Varnish in a bit, the preferred solution for reverse proxy caching.

Database caches: MySQL has its own built-in caches, particularly the query cache (query_cache_size) and file system I/O cache (innodb_buffer_pool_size), which ought to be increased as high as your database server has the memory available to do so.

Drupal caches: Drupal has its own caches for pages, blocks, and Views. Visit the

Drupal performance page in your Drupal admin interface, and turn them all on.

I’ll also talk about Pressflow, an optimized version of Drupal that improves on

Drupal’s own internal caching mechanisms.

Download from Wow! eBook <www.wowebook.com>

Figure 23-1. Alternative PHP Cache (APC) comes with an interface that displays memory allocation and the files currently within the cache.

500