This is the first in a 2 part post related to improving the performance of a Drupal site. We are going to walk through a number of items that can help improve the performance of your site. The list goes from the quickest and easiest to more advanced and difficult options. Many sites can benefit from the first few simple suggestions we will be covering today. Sites whose main traffic is authenticated users can benefit more from the items we will cover in part 2.
Before starting though, I want to state that it is crucial you have a performance testing framework in place before making any of these changes. Ideally, you want to know what your baseline performance is, what type of workload you are expecting or optimizing for, and what type of performance goals you are looking to achieve. If you reach your performance goals and all that was needed to get there was enable Drupal’s built in caching, congratulations, you are done :) In future posts we will go into detail about how to set up performance testing.
Lets get started.
Disable / Uninstall Unused Modules
This should be one of the first things you do when looking to improve the performance of your site. Having unneeded modules enabled can add to the number of SQL queries that are executed during a page load. Are there any modules enabled that are not being used? Are there any modules that can be removed?
Besides disabling unused modules, if the statistics module is enabled, its worth disabling it since it can generate a lot of traffic to your database. Another module to disable for this reason is the Database logging module. Instead of logging messages to a database table, enable the syslog module and have messages logged to a file instead.
The advagg module for advanced aggregation can be used for this purpose also.
Cache All the Things
Caching is very prominent in the Drupal world and for good reason. It can significantly improve your site’s performance. With that in mind, there is a myriad of caching options available to you.
Built In Caching
One of the first caches that can be enabled is the page cache. This will speed up page load times for anonymous users by caching the output of each page i.e. the entire HTML of each page is stored in the cache. Another simple cache to enable is the block cache. Note that when page caching is enabled, enabling block caching is not necessary since blocks are automatically cached if page caching is enabled.
Use Memcached or Redis
By default, all the caches mentioned previously store their cached information in tables created in the underlying database. Seems like there must be a better place to store all that cached goodness!
Traditionally, memcached was the goto option for this. Simply enable and configure the memcached module and your cached information will be stored in memcached as opposed to a database table.
Redis, while not exactly a brand spanking new project, is certainly much younger than memcached. It is rapidly gaining in popularity however. A module is available enabling Redis to be used as the caching system for Drupal.
APC is an opcode cache for PHP. The nice thing about APC is that you simply need to install and configure it on your system and there is not much else you need to do after that. Articles exist on optimizing APC for drupal that are worth becoming familiar with but if you are running in a Drupal hosted environment like Acquia, its likely you don't need to worry about this since opcode caching will already be enabled.
The boost module is another mechanism to provide static page caching. It caches pages as static HTML files in order to take PHP processing out of the equation when processing a page request. This strategy can greatly improve page loading times for anonymous users but it is of no benefit to any authenticated users.
Varnish is a reverse proxy that sits in front of a web server. Varnish does an amazing job caching static files and pages for anonymous users. It can provide major performance benefits to sites that receieve a lot of traffic from anonymous users since requests are served directly from Varnish and do not even reach the web server.
Many Drupal hosting providers already deploy Varnish in their environments. I am most familiar with Acquia and Varnish is already in use with a configuration Acquia recommends.
Views can generate some pretty complex SQL queries. We've seen this module generate some queries that have taken many many minutes to complete. If possible, caching views can make a big difference. it is possible to enable time-based caching on a per-view basis through the views UI.
In addition to the built-in caching that comes with Views, there is a module named Views Content Cache that adds content aware caching for views.
In Drupal 7, by default, each field associated with an entity is stored in its own SQL table. You can imagine that loading an entity with many fields could be quite expensive. Luckily, there is a simple caching solution to alleviate that pain - the entity cache module. Simply enable the module and entities will be cached upon loading.
The items covered in this post can help improve the performance of a site greatly. If your site has a lot of authenticated traffic through, the caching solutions discussed here may not provide as great a benefit as you would like. In our next post, we will cover items that can help improve the performance of a site with a lot of authenticated traffic.