Any system will slow down without regular maintenance and Drupal is no exception. Yes, there’s a lot you can do without touching Drupal at all. Your Drupal website is just one layer of an infrastructure that includes a database, webserver, and operating system, not to mention the hardware resources running all that software. However, there are some basic admin practices you can put in place to prevent Drupal from putting on excess weight.

Prune the error reporting log files

Drupal 7’s error reporting logs are stored in its database, in a table known in older versions of Drupal as watchdog. These logs are extremely useful for debugging and troubleshooting, as well as getting an overview of site activities. However, when you have logging turned on, the size of the table could affect performance. Sometimes when developers are working on a site, they will log all messages and forget to reset it for production use. Make sure this hasn’t happened. You just need to keep the most recent log messages for troubleshooting or activity tracking. The number of messages is up to you.

In Administration / Configuration / Development you can set both logging level and how many log entries to keep. 

The Drupal default is 10,000. Database cleanout of the log file will happen the next time cron runs.

NOTE: Cron is just a process that runs in the background which executes at specified intervals. You can manage your cron settings in Administration / Configuration / System. Make sure cron is set to run at least once a day.

This should be sufficient for most small to medium-size businesses (SMBs), but in high-volume situations you could find that logging drags down performance because Drupal writes to the database every time it logs an action. If you’re running a high performance site and you want to log at a detailed level and/or you want to keep a million log entries, Drupal provides the option of sending log messages to the systems logging service, syslog, instead of the database. Syslog writes log entries to a file, which requires much less overhead.  

To do this, enable the syslog module and disable database logging. Once you’ve done this, the logging and errors settings will look like this: 

The main thing to remember is that syslog output will be different on different servers. Also, unless you’re the system administrator, do not use syslog if you’re in a shared hosting environment.  

Prune the sessions table

User session information lets Drupal keep track of users over some specified period of time. Drupal stores this session information in its database. Sites with tens of thousands of visitors a day can build up a lot of session information in the database very quickly. Drupal looks up session information whenever a user visits the website, creating overhead that affects performance. To control how long Drupal keeps session information, you can edit the settings.php file to manage (a) when sessions expire, and (b) how often to run the ‘garbage collection system’ that cleans out old data from the sessions table. The lines to look for are:

1. Session expiration setting. The Drupal default is 200,000 seconds, or 55 hours. To set to 24 hours:

ini_set('session.gc_maxlifetime', 86400);// 24 hours in seconds

2. Garbage collection system setting (you may need to add this line):

   ini_set('session.cache_expire', 1440);// 24 hours (in minutes)

Drupal recommends using the same value in for both settings. Note that one is set in seconds and the other in minutes, but both are set to 24 hours.  

If you prefer to use the Admin interface to control how long sessions last and keep down the size of your sessions table, the Session Expire module is a popular solution. Setting options include: how often to clean up, age of sessions to expire, whether to expire only anonymous sessions or both anonymous and authenticated sessions.

Prune session cookies

You know that you can improve performance by caching pages for anonymous users. You can also improve performance by reducing the length of time that authenticated users stay logged in. 

The default setting in Drupal for keeping session cookies alive is three weeks (2,000,000 seconds). For three weeks after a user logs in, Drupal treats that user as authenticated. This means even if the user returns to your website just to look at some static pages, Drupal will build those pages from scratch instead of serving up generic cached pages. If this is the case, you could be running up overheads by keeping session cookies alive for a long time -- even though most authenticated (logged in) users don't need user-specific content very often. If your website contains a lot of static pages, you may want to let session cookies expire sooner or have them expire when the browser closes. That way, on the user’s next visit, Drupal will serve up cached versions of those generic pages and save on resources – until the user explicitly logs in again. Do this by editing this line in settings.php:

a) To expire the cookie in 24 hours:

  ini_set('session.cookie_lifetime', 86400); // 24 hours in seconds

b) Or, to expire the cookie when the browser closes:

If you prefer to use the Admin interface to manage logout session cookies, the Automated Logout module lets you set timeouts for users based on role as well as time. The module also provides some nice options such as setting a redirect URL at logout, and also an optional warning message for session expiry.

One of the benefits of pruning your Drupal website regularly is that when you run into performance problems, you can troubleshoot knowing that excess weight isn’t part of the problem. If you’re a small to medium business (SMB) you can probably run with those settings until there’s some drastic change in your traffic pattern. For busier websites, you will want to revisit those settings now and then to do some tuning. 

Finally, remember that your Drupal website is part of a total webserver infrastructure. Network and server resources could be significant factors when it comes to performance. If you lack the resources or skills to audit your IT infrastructure, get some IT consulting help. They have the tools and do this every day.