Three Drupal Performance Enhancers for Site Admins
One of the big reasons why companies pick Drupal is because it’s designed to handle large amounts of web traffic. Drupal 7 put a lot of effort into improving scalability and performance, but as always: it depends. It depends on your website and the type of traffic you handle. It depends on your settings, database, code, modules, and server architecture. They all work together to contribute to performance. Performance is a multi-dimensional problem. (Related article: Why You Need to Understand the Differences Between Drupal and WordPress)
Here are three simple thing a Drupal admin can do to improve performance without diving into code:
Enable Page Cache
Some site administrators hesitate to change Drupal settings. When it comes to caching, however, it’s hard to come up with a scenario where this wouldn’t improve performance and at the very least, it can’t hurt. Page caching works.
Go to: /admin/config/development/performance
Then enable site-wide caching by ticking the box beside “Cache pages for anonymous users.”
There is a big difference between the amount of RAM needed to render a page request versus deliver a cached page. As an example, a Drupal site with around 25 modules might use 40 – 50 MB of memory to serve a page request. On the other hand, a cached page takes 2 – 4 MB of memory; this leaves more resources for other tasks and also significantly accelerates page response time.
When Drupal caches a page, it takes the entire rendered output of a page and stores it in the database. The next time the user needs that page, Drupal just serves it up without having to render it again. Drupal only caches pages for anonymous traffic. Users with session cookies don’t get their pages cached because they could be specific to a user and not valid for anonymous users. If your site contains a lot of static pages, you will really notice the difference once you enable caching.
Tip: use the devel module to see how much time and memory it took to render each of your page requests.
Disable Non-essential Modules
Modules are one of Drupal’s big attractions. The Drupal community’s contributions of tested and maintained code make life easier for developers. However, the more modules you load up, the more server resources Drupal uses, and the more impact on site performance. Go through your modules and disable the ones that are non-essential or unused.
For example, if you’re using Google Analytics, you can disable the Statistics module. This writes to the database to log every hit to your site. If your site is Production-only, you can disable the Update Manager. This polls Drupal.org for updates, but in practice you would not be updating your production server this way; you would be updating your development or staging server and then synchronizing your production site against a tested staging server.
Send Your Logs to the Operating System
Dblog used to be ‘watchdog’ in Drupal 6; this was Drupal’s database logging module. Database logging slows down server performance. If your database is already overloaded, try the Syslog module or Advanced Syslog instead. These use the operating system’s logging facility. In addition to performance, the added benefit is convenience: you can go to one place – the OS report log – for all your logs instead of checking a separate database log for Drupal.
Finally, remember that although there are many, many tactics for improving Drupal performance, you are essentially operating a webserver environment. Your system architecture, server resources and configuration, database server and even network bandwidth may have more impact on Drupal performance than anything you can do within Drupal. An IT infrastructure audit will identify performance bottlenecks and help you create a roadmap for scalability.
It’s worth making the effort because website performance matters more than ever these days. Response time (as measured by page load time) is one of the user experience factors that Google uses to rank websites. Performance is an ongoing challenge because resource usage changes when your user mix changes or when you add new features and apps to your website. There is never a “one right way” to fix performance problems, only performance goals that you aim for by using a mix of tactics.