(For more resources on Drupal, see here.)
Performance
Every once in a while, someone makes a site that becomes wildly popular. Having many people visiting all at once can put some serious strain on the server’s resources and cause all sorts of problems as the congestion builds.
If you are unsure about what resources are available on your site, check with the hosting service and find out what they provide in the way of disk space, monthly transfer, and transfer speed. Many hosting services will boast unlimited bandwidth, but won’t talk about connection speed. In other words, they don’t meter how much water you use because they only let you switch the hosepipe on half way.
It’s important to know the limitations of the hardware and network resources, but don’t fall into the trap of believing this is the most important thing to know.
Ensuring that there are facilities in place to handle a large amount of traffic will go some way in ensuring that your site scales well.
It’s a time-honored tradition in the corporate world to throw extra resources at computing problems—buying the latest, fastest servers to help speed up slow applications, upgrading network hardware to allow data to travel more freely, and so on. Invariably though, poorly designed software, or software that is poorly tuned for performance always finds a way to utilize all the resources one can throw at it and still want more.
More often than not, it is better to look at why software is chewing up resources and see what can be done to either stop it or at least alleviate the problem, so that the software utilizes its resources wisely. Drupal already has several strategies in place to help you, the site administrator, decide how and when to use resource-intensive modules and how to maximize the site’s efficiency.
Caching
This section provides several options to improve the performance of your site, and as nothing in this world is really free, you need to understand that, by and large, obtaining a performance boost comes at the expense of something else—namely, how up-to-date content is.
The following screenshot shows the performance page:
The first option, CLEAR CACHE, is useful while making modifications to a site because it helps to ensure that changes are definitely displayed and not held up while the site cache is still in operation. Having the ability to clear the cache in order to view precisely how pages are being built is useful, but comes at a price. Remember that if you have a large site with lots of content, then Drupal will have to do a lot of work to rebuild its cache, and it is possible that users may notice a slowdown during this time.
It is important to only enable caching on a live site, and not on the development machine, because changes to a page show up only when the cache expires—causing confusion if you are expecting something else during testing.
As you know, Drupal uses PHP to build web pages that are returned to a user’s browser. Most of the time, these pages are unchanged between requests, and Drupal ends up repeating the work of building the same page before sending it off to the other users who requested it. It makes sense to tell Drupal that if it has created a web page once, it should store a copy of this page and serve that copy instead of going through the trouble of recreating it.
The process of storing copies of web pages in order to reduce the amount of effort required to repeatedly create a page is known as caching.
The trade-off when using page caching is that any changes to a page are only shown to the users once that cached version has expired and been replaced. This makes caching a suitable method for boosting performance whenever content is not updated very often or when it is not important to have new content presented immediately.
You will need to decide how long you think it is suitable to go before any updates made to a page must be shown—the longer you leave a page cached, the less work Drupal has to do, but the longer it will take for new content to show on the site. If your site is a daily blog, then by all means set the cache for up to a day at a time. If your site is a super busy, breaking news portal, then clearly you would opt for a cache time in minutes.
Drupal also has the ability to cache the content of blocks, which can be a real performance boost for authenticated users (since page caching is only available for anonymous users). Blocks are constructed independently from the page as a whole, and often require expensive database requests or other operations in order to provide the information they contain.
Enabling block caching means that blocks no longer have to query the database (or whatever else it is they are doing) each time a page refreshes. Rather, they simply serve up the cached version and save on all that work.
Again, make sure you carefully weigh up the benefits between having fresh content and having high performance.
Bandwidth optimization
BANDWIDTH OPTIMIZATION, shown at the bottom of the page in the previous screenshot, deals with how to best transfer data from your server across the Internet to the users’ browsers. The way in which data is transferred plays a big role in optimizing performance. In general, the most important things to remember are:
- Keep files small
- Keep the number of files down
As shown, Drupal can aggregate and compress disparate CSS and JavaScript files in order to reduce the size and number of requests made to a server. Obviously, this has a huge number of benefits, especially if you are charged for bandwidth usage.
Again, don’t aggregate files during development. Turn this feature on only once the site has gone live, otherwise you are in for some serious frustration when changes to themes or scripts don’t show up or behave as expected.
Maintenance
I should make the following point very clear:
All major development or changes to a site should be performed on the development machine and thoroughly tested before being implemented or ported to the live site.
There will be times, however, when you simply have to make some changes directly to the live site—even if it is only to implement upgrades that have already been tested out on the development server. If this is the case, then rather than allow users to browse a site under maintenance, visit the Maintenance mode page in the Development section, and select Put site into maintenance mode, provide a Maintenance mode message to display if the default one is not suitable, and get on with your work.
Be very careful when working in maintenance mode because once you have logged out you are effectively locked out too. This is because, by default, only one user (that is the administrative user) can do anything on the site while it is offline. If you log off and try logging in again, you are no longer the administrative user; you are instead anonymous and are shown only the offline message:
This is not very helpful if you do happen to be the site administrator; so Drupal allows the login page to be accessed as normal. Navigate to http://localhost/ drupal/user, and you will be able to log in as the administrator and use the site without hindrance.
Make sure you know the administrator’s password before going into maintenance mode.
Everyone else is locked out until the site is no longer under maintenance.
Logging and errors
Go to Logging and errors in the DEVELOPMENT section of the Configuration overlay. This page provides a few options used to control how errors are displayed and logged:
Error messages to display allows you to decide whether to write errors to the screen or not. While you are busy building the site, it’s useful to view All messages in order to determine what has gone wrong and when. However, once it is time to go live you should change this to None for security reasons. Doing so prevents Drupal from displaying information to malicious users who might be able to use it in an attack on your site.
The final setting, Database log entries to keep, at least to begin with, is sensible. You may wish to increase or decrease the number of records stored on the system depending on how much work you have to do in order to maintain the site properly. Remember that Drupal can properly maintain the site’s event logs only if the cron jobs are being run regularly.
Having only one setting to make is not that exciting, but once the site is live and messages are no longer visible through the pages, you can check the logs in the Reports section. Doing this on a regular basis is a good strategy to ensure that the site continues to run smoothly. Error messages, warnings, and so on are effectively windows into the operations of the site, and are indispensable tools.
