Drupal performance tuning

I gave a talk about scalability at the last SF Drupal User’s Group meeting. Performance and scalability is an excellent topic for a user group meeting; everyone wants to know about scalability and there is enough material for hours. I did my talk in two parts: I spoke about the general process and demoed useful tools.

The overall priorities are

1. Solve easy problems. Small changes can have big results.
2. Buy hardware, when cheaper than developer time.
3. Solve hard problems.

Consider the whole stack, not just Drupal, both front‐end and back‐end. Each page request requires effort from Apache, PHP, MySQL and Drupal to be sent to a browser for rendering HTML, CSS and JavaScript.

The overall process is

1. Find the slowest part.
2. Make it faster.
3. Repeat until you reach your goal. Setting goals and measuring success are helpful.

Luckily, we are working with popular LAMP stack. There is a lot of excellent knowledge out there for solving the common issues. Buying hardware follows a common pattern

1. Start with everything on one server.
2. Get a good database server. Database clustering with multiple servers is a bit of a project, so buy more than what you immediately need or plan for upgrades.
3. Get more web servers. Start out with round‐robin DNS for load balancing.
4. Do fancier upgrades as needed. These include software or hardware load balancing, database clustering and reverse proxies.

The tools

Drupal is a good place to start, at Administer → Site configuration → Performance. Enable options while testing your site. Modern CMSs make a lot of database queries and Drupal is no exception; turn on the page cache to serve pages for anonymous visitors with only one query instead of 60 or more. The block cache was added in Drupal 6 to help reduce queries for logged‐in visitors; when coding custom blocks, read the cache options for hook_block(). CSS and JavaScript optimizations greatly reduce the number of files a browser needs to load.

MySQL improvements often have big results. The slow query log logs problem queries which mysqla parses and summarizes. EXPLAIN tells you how the server executes specific queries. Catch problem queries while building a site with the Devel module’s query log.

Slow queries are common and easily fixable because CCK and Views are table and query builders, but do not add indexes. Manually adding indexes on the right column(s) for the slowest queries has great results. MySQL’s default configuration is not right for your unique load and hardware. mysqlreport summarizes all status values and provides guidance for finding and correcting issues.

Fields shared between two or more content types are stored in separate tables and require joins; use a field in only one content type whenever possible. Watch for the same or similar queries being executed many times on a page with the Devel query log; try to roll up these queries into one more‐efficient query. Views within views are good at creating that situation.

PHP is a scripting language, code compilation happens on‐the‐fly. The compiled code, or opcodes, can be cached with APC, eAccelerator and others. 2bits has an excellent article on this subject.

Xdebug helps with PHP debugging, including memory usage and profiling. I rarely use this for performance work, but it invaluable for daily development.

The front‐end, the work a browser does, is taking an increasing amount of resources with new CSS and JavaScript techniques. Drupal often finishes within 200ms while the browser takes seconds to request and load the supporting files. Firebug and YSlow summarize HTTP requests, how long each takes and suggest how to reduce them. YSlow’s generic ranking may not be right for your site, you might not need a CDN, but the recommendations are usually good. Firebug has many tools, including a JavaScript profiler and tools for inspecting HTML and CSS.

The future

I am interested in ways to improve these tools to encourage developers to be aware of performance as part of the development process. You should not optimize from start, your valuable time might go into features or design. You should pay attention to what you are doing. The data is currently in too many different places and requires too much knowledge to interpret.