Testing your Boost configuration
Now we're going to test out our Boost configuration and make sure everything is working with our initial basic settings and the .htaccess configuration that we're running. Log out of your website in your current browser or open up another web browser so that you can browse around your site as an anonymous user.
The main thing we want to check on is that our static HTML type files (our Drupal pages or nodes) are being cached and stored in the cache directory we have specified in the module configuration. If we chose to use a GZIP compression, we will want to check to make sure the ZIP files are being generated and stored.
Also, run your Status report and view your log entries to check to see if any errors related to the module configuration are being thrown.
You should start noticing a performance boost on your site immediately, as you browse around your site. Start clicking around and opening different nodes on your site and admire the faster performance! You should notice it.
If we check the cache directory on our site, we should notice that the Boost module has started writing HTML files to our cache directory. In the directory you should now see the following folders:
Boost has automatically created a new folder called /node where it will store the cached HTML versions of the Drupal pages it loads. For example, if we look into our /node directory, we should see a bunch of HTML files that have been cached while we've browsed anonymously on our site. You can almost see this happen in real time if you browse to a page and then immediately refresh your remote server/ site window in your FTP client (while in the /node folder). I see the following files corresponding to their Drupal nodes:
These correspond to:
Also, at the root of our /fire directory, we should see any non-node pages (for example, pages created using Drupal Views module). In our case, our main Photo gallery View page has been cached: photo_gallery.html. This page corresponds to our photo_gallery View page.
You can immediately see the power and flexibility of this module by inspecting your cache directory.
You should notice a performance increase on all of these cached pages because the pages that are loading are now your Boost-powered HTML pages. So, multiple clicking on one Drupal node should demonstrate how quickly your pages are now loading.
The module has created another folder in your /fire/cache directory called perm. The /perm folder contains your CSS and JS files as they are cached. If you look in this folder, you'll see paths to the following folders:
Another method of checking the module is working correctly is to view source on your pages (by viewing source in your web browser) and see if the following code is being added to your HTML output:
<!-- Page cached by Boost @ 2009-10-23 13:56:03,
expires @ 2009-10-23 14:56:03 -->
So the actual HTML source in the web browser will tell you that you are viewing a cached version of the page rather than a dynamically generated version of the page. It also tells you when this cached page version will expire—based on our configuration, basically one hour after it's been loaded depending on our Boost module settings.
Everything appears to be working fine with our initial Boost installation and configuration. Sit back and behold the power of Boost!
Boost and Poormanscron
Checking our Status report will show us that we're running an incorrect version of Poormanscron. Boost is optimized to work with the latest dev or 2.0 branch of Poormanscron. So let's go ahead and install the latest version so that our cron runs will work correctly with Boost.
Visit the Poormanscron project page and download the 6.x.-2.0-beta1 release and extract and upload it to our /sites/all/modules directory. Then run your Status report again to check to make sure the Boost warning has disappeared. You may need to run your update.php script, as this module update will make changes to your database schema. Run update.php and then refresh your Status report.
In your Status report, you should now see the Boost row state: Boost Installed correctly, should be working if properly configured.
The updated 2.x-beta1 version of Poormanscron is the precursor module to the eventual Drupal 7 core cron functionality. In Drupal 7, the functionality of the Poormanscron module will be part of the default core processes. For this reason the beta1 version does not give you a module configuration page. It will just run cron automatically, based on a setting on your Site information page. Go here to see that setting: Site configuration | Site information. Now you have an automatically run cron setting that you can select from. We'll use the default 1 hour cron run. This is a nice preview of some of the new built-in functionality of Drupal 7 core.
Clearing the Boost cache
If you want to clear your Boost cache at any time and see how this affects the /cache folder on your site, go to the Boost cache configuration page at Performance | Boost Settings and click on the Clear ALL Boost cached data button and the Clear Boost expired data button. Since you started caching, these buttons will tell you how many pages they are caching respectively. This is another good example of the flexibility of this module.
Once you have cleared cached data from Boost, you will receive messages telling you that the Boost: Static page cache cleared and/or a message stating Boost: Expired stale files from static page cache. To see the results, check your /cache directories and you should see that all the previously cached HTML pages are now deleted. Through FTP you may need to run your F5 function key to refresh the / node directory. The HTML files will be deleted. If you refresh your /node directory, it should now be empty. This is a method of clearing the cache manually instead of waiting for it to clear based on the minimum cache lifetime you set as per cron runs. Again, this is a very flexible functionality allowing you both manual control and auto control of your page caching.
Boost admin and stats blocks
The Boost module provides you with three blocks that you can enable and use on the administrative side of the site. Go to Site building | Blocks and look for the following blocks:
- Boost: AJAX core statistics
- Boost: Pages cache configuration
- Boost: Pages cache status
Enable all three of these blocks to show in the right sidebar of your site. You can configure each block and choose to show it only on specific pages of your site and for specific roles as well, such as site admin, if you prefer. Configure each block and then enable in your right sidebar. I'm also going to make sure my two new blocks are showing at the top of the right sidebar area above any other blocks I may have configured. I'll put the status block first and the cache configuration block second in weight order.
Now, in your right sidebar on each page, when you are logged in as an admin user you should see both the Pages cache configuration block and the Pages cache status block. In another browser (if you haven't already), browse around your website as an anonymous user. Now load those same pages as an authenticated admin user and view the blocks and the information they are showing you about each page.
Boost: Pages cache status block
This is what the Boost: Pages cache status block should look like (or similar to) in your site. Here I'm on node/203 of our site and the block looks like this:
The status block tells us whether the site is being served to anonymous users as a static cached HTML page or whether it's still being served 'live' as a dynamic Drupal page. This is very helpful if you have thousands of pages on your site and you're trying to determine if the page is being served static or live. You can then determine quickly if you need to enable caching on that specific page (if you have a more complex Boost configuration where you're only using Boost to serve specific pages).
This block also tells us how many seconds it takes to generate the cached page. Here, on node/203, it takes 2.186 seconds to serve the HTML version of the page. Additionally, the status block tells us when the cached copy of the page is set to expire (based on our minimum cache lifetime settings).
You can also click on the Flush Page button and this will clear the Drupal page from the Boost cache entirely. Again, this is a very nice functionality to have if you are setting up a more complex Boost cache configuration.
Load some other pages both as an anonymous user and as your admin user, and check the status blocks for Status reports on the caching for that specific page.
Boost: Pages cache configuration block
This block allows you to configure your basic Boost settings for a specific Drupal page while you're administering the page itself. So go ahead and launch a node on your site and you'll see the block in the right sidebar. It will look similar to this:
This block allows you to set and adjust the minimum cache lifetime (1 hour, 3 hours, and so on), the preemptive cache and whether it's enabled, as well as the scope of the Drupal page you are viewing. Scope will tell you the page ID of the node and what type of content the node is built from—in this case we're looking at a Photo content type node. The type of container (node, block, or otherwise) is also noted here. You can tweak the configuration settings here and save a new configuration. You can also delete your configuration here.
If you choose to set a new configuration here, for example, changing your page cache minimum cache lifetime to 3 hours versus 1 hour, the cache will be fl ushed and reset to your new 3 hour lifetime. So your status block will show that the page is being served live again on the site until you visit that page as an anonymous user. When the Drupal node is being served live, this is what the status block looks like:
Summary of Boost's basic configuration
The one thing to remember when using the Boost module is that only your anonymous site visitors will be served static HTML page versions of your Drupal dynamic data. It will be business as usual for your authenticated site visitors. When they login, they will continue to receive the dynamic live version of the Drupal node. You will want to keep this in mind when you decide whether you will use this module on your site. If your site is heavily traffi cked by anonymous users, then you'll want to try out Boost. If you have a community portal site that depends on authenticated user comments and forum activity, you may not want to use the Boost module or at least be aware of its limitations when it comes to how it works on that type of site.
Additionally, the Boost module only works on web servers running Apache server software. Much more about Boost is available on its Drupal module project page.
Here, we looked in detail at two contributed modules—DB Maintenance and Boost, which help to both maintain and speed up performance of our website. Specifically, we did the following:
- Installed and configured the DB Maintenance contributed module in order to optimize, repair, and back up our MySQL database.
- Installed and configured the Boost module in order to set up basic static HTML page cached versions of our Drupal nodes.
- Tweaked our HTACCESS file to enable the Boost settings through the Boost htaccess rules generator functionality.
- Enabled the following Boost module blocks: Pages cache status, Pages cache configuration, and AJAX core configuration.
If you have read this article you may be interested to view :
- Drupal 6 Performance Optimization Using DB Maintenance and Boost: Part 1
- Drupal 6 Performance Optimization Using Views and Panels Caching
- Drupal 6 Performance Optimization Using Throttle and Devel Module