As great as Drupal 7 core can be, it doesn't scale well for Web sites with a lot of content and/or a lot of users. To make it perform better under these scenarios, it's necessary to make use of several strategies, tools and techniques.
Although some of items mentioned here can simply be enabled on all Drupal sites to increase performance, I would instead recommend that folks target problematic areas that will be different for each and every situation. Take a holistic perspective, and whittle down problem areas to reach a specific performance target. Basically, it's essential to take measurements before and after making changes. Otherwise, you could be increasing complexity unnecessarily and targeting the wrong areas, thereby missing opportunities for larger gains.
I've split this article into several categories listed below. Click on any of these to jump directly to the respective section.
- Configuration Best Practices
- Views Caching
- System Administration
- Cache Replacements
- Cache and Optimize Specific Components
- External Caching
- Cache Warming / Priming
- Drupal-Specific Hosting
- Useful References
- Disable unused and non-essential modules. Loading additional code unnecessarily will consume additional server resources.
- Disable the Statistics module as it writes to the database on every hit. You're probably using Google Analytics anyway.
- Disable the Update Manager module on Production. As part of your DevOps process, after synchronizing your Development/Integration server with Staging or Production, enable it there. Your Production server doesn't need to spend time polling drupal.org.
- Enable site-wide caching over at Administer » Configuration » Development » Performance.
- Convert non-transparent images to JPGs (with some exceptions - see the first comment below).
As the Views module is the most popular contributed module, most of us are using it to display content is various ways. Views instances should be cached so that when accessed, a cached copy is returned instead of having to rebuild each view every time it's loaded. There are two (2) options here.
- Time-based caching for each view display (ships with Views)
- Views Content Cache: Update each view only when its constituent element have been updated.
If you've got a lot of content and are using Views paging, you may want to consider using Views Litepager. It will work around slow COUNT queries on InnoDB tables, those using the default table-engine type in MySQL.
- Alternative PHP Cache (APC) for PHP < 5.5. (This is part of core PHP in newer versions.)
- PHP-FPM (a FastCGI implementation) instead of mod_php.
- Nginx: An alternative to the ubiquitous Apache Web server.
- Syslog: OS-integrated logging: Send logs to your operating system instead of writing to your database.
- Solid state drives (SSDs): These cost more, but if you can afford it, use them instead of classic hard disk drives (HDDs) in your server hardware.
- Disable automatic cron & run a proper cron job: Ensure that users aren't running periodic tasks before they see content. It's usually not necessary to run it more than once per day, but if more granular control (over which tasks are run when) is necessary, one can set up the Elysia Cron module.
The default Drupal-site caching is not very efficient. As a result, alternative mechanisms have sprung up to fill the void.
If there are specific components of your site that need a performance boost, the following list will help you target certain areas in specific ways.
- Cache entities with Entity Cache.
- Cache entity view modes with Display Cache.
- Improve CSS/JS performance with Advanced CSS/JS Aggregation or Aggregate cache.
- Cache Panels content with Panels Content Cache or Panels Hash Cache.
- Load images only when needed with Image Lazyloader or similar modules.
- Minify JS files with Speedy.
- React to page-not-found errors quicker with Fast 404.
- Speed up your site by removing no-longer-available modules with Missing Module.
- Cache components with logged-in users via Authenticated User Page Caching (Authcache).
It's possible to place another application in front of yours that will serve cached copies of your Web pages. This is called "HTTP acceleration" or "reverse proxy caching". There's really only one game in town, but it has some helpful add-ons.
If you don't have access to Varnish (usually because of shared hosting), then you can run Boost instead.
If caching systems are used heavily (for a lot of content), it may take quite a while for cached data to get rebuilt whenever caches are cleared. If this is the case, it's worth considering a tool to rebuild these after any clearing happens. Otherwise, the first users hitting the site afterwards will experience slow page-load times.
There are several services that can be used in conjunction with your Drupal site to monitor and/or increase performance.
- Content delivery networks (CDNs) such as CloudFlare
- ProjectPAAS along with its connector module: Drupal-specific performance service.
- New Relic: General performance monitoring that supports Drupal. Works nicely with Pantheon.
- BlazeMeter Module for Load and Performance Testing: General service that works with a plug-in module.
There are some fine folks out there that will manage the infrastructure for you. If you don't need to be managing your own software stack, it's probably best to let others do it. The options over at Drupal-specific hosting: Choose a provider from those offering comprehensive platforms generally include infrastructural features mentioned in this post.
There are several tools available for tracking your performance.
- The Performance and Scalability Checklist module
- The Performance Logging and Monitoring module
- Slow query logging with the Devel module
- The XHProf PHP profiler
Some great tips can be found at the following links.