Boost Installation & Settings

Last updated March 5, 2012. Created by dbeall on August 11, 2009.
Edited by Shane Birley, patrickharris, mikeytown2. Log in to edit this page.

This page is a walk-through of the steps and the 6.x-1.17 UI pages, so everything will be familiar. This might look a little overwhelming, but It's easy with a few selections during setup. Boost has advanced help support if you install and enable the module. The readme file is viewable with core help.

The Smart Defaults provided with the install will work fine in most cases.
Notes and Settings Tips included on this page to help with:
• Domain Access • i18n • Multi-site • Logged-in performance • General help

Contents

• Installation
• Performance /Boost Settings
• Boost file or static page cache
• Boost cacheability settings
• Directories and file extensions
• Boost advanced settings
• Boost crawler settings
• Apache htaccess Rules Generator
• Prepare htaccess for Boost
• Prepare robots.txt for search engines
• Prepare settings.php for cron
• Drupal /Performance Settings
• System check, verify functions
• Administrative blocks

Steps to install

1. Download Boost, Transliteration, Globalredirect and unzip the modules on your computer.
Note: Globalredirect and Transliteration are not required, but are suggested or recommended.
2. FTP or upload the module folders with all their contents(as is) to sites/all/modules
3. Goto: Administer > Site configuration > Clean URLs
   system path admin/settings/clean-urls
   Ensure that Drupal's clean URLs are enabled and working correctly.
4. Goto: Administer > Site building > Modules
   system path admin/build/modules/list
   Enable the Boost module in the Caching section, Transliteration, Globalredirect and Poormanscron if used.
5. Save the settings to install (updates the database)
   After saving the settings, there will be a link at the top of the module page directing you to the (Performance/Boost settings) UI page.
After the module has been enabled, a notice will display
(Drupal's standard page caching disabled by Boost.).
6. Configure the settings on the (Performance/Boost settings) page.
   Goto: Administer > Site configuration > Performance > Boost settings
   system path admin/settings/performance/boost
7. Configure the settings on the (Performance) page.
   Goto: Administer > Site configuration > Performance
   system path admin/settings/performance
8. Copy the custom rules from (Boost htaccess rules generation) page to the Drupal htaccess file.
   Goto: Administer > Site configuration > Performance > Boost htaccess rules generation
   system path admin/settings/performance/boost-rules
9. Add one entry in the robots.txt file for search engines in your Drupal root. see: Prepare robots.txt for search engines
10. Check the Drupal Status Report for any issues.
    Goto: Administer > Reports > Status report

Back to top

Performance /Boost Settings [tab]

• Goto: Administer > Site configuration > Performance > Boost
  system path admin/settings/performance/boost

Boost File cache

Static page caching is a mechanism that stores dynamically generated web pages as HTML files in a special cache directory located under the Drupal installation directory. By caching a web page in this manner, the web server can serve it out in the fastest possible manner, without invoking PHP or Drupal at all. While this does provide a significant performance and scalability boost, you should note that it could have negative usability side-effects unless your site is targeted at an audience consisting mostly of "anonymous" visitors.

• Boost - Static page cache: Choose Enabled for Boost to work.
  (  ) Disabled
  (x) Enabled
  (  ) (Not Recommended) Set Boost & Core (if enabled) cache for each page
• Gzip page compression (Boost & Core): Radio buttons
  (  ) Disabled
  (x) Enabled (Default)
By default, Drupal compresses the pages it caches in order to save bandwidth and improve download times. This option should be disabled when using a web server that performs compression.
• Boost - HTML - Default maximum cache lifetime:
  [1 Hour] (select)
Default is 1 hour and can be increased for sites that do not change very much. The maximum cache lifetime is the maximum amount of time that will elapse before the cache is emptied. Cache lifetime gets checked on cron runs. Flushing the content before it is expired can happen, for example when a node is edited.
• Boost - XML - Default maximum cache lifetime:
  [1 hour] (select)
The maximum cache lifetime is the maximum amount of time that will elapse before the cache is emptied. Cache lifetime gets checked on cron runs.
• Boost - JSON - Default maximum cache lifetime:
  [1 hour] (select)
The maximum cache lifetime is the maximum amount of time that will elapse before the cache is emptied. Cache lifetime gets checked on cron runs.

[Clear ALL Boost cached data: (20) pages] (button)

Clears the cache of all pages currently in the cache files. Great for seeing current changes when working on the site or after adding content. Visitors will see changes immediately without waiting on a cron run to clean the cache and regenerate the pages. Because it flushes all content, the cached css & js get flushed as well.

[Clear Boost expired data: (15) pages] (button)

Clears all pages that are past the cache lifetime. It's kinda like a manual cron run.

Back to top

Boost cacheability settings

• [x] Cache pages that contain URL Variables
Boost will cache pages that end with ?page=1 among others. (anything with a "?" in the url)
• [x] Cache html documents/pages
Boost will cache most Drupal pages.
• [  ] Cache .xml & /feed
Boost will cache .xml and /feed urls as xml data.
• [  ] Cache ajax/json
Boost will cache ajax/json responses.
• [x] Cache .css
Boost will cache CSS files.
• [x] Cache .js
Boost will cache javascript files.
• [x] Only allow ASCII characters in path
Only allowing ACSII characters is a safe way to cache pages. It severely limits i18n support so this can be turned off. Fair warning, disabling this may cause "page not found" errors depending on your url structure (spaces are bad, etc...). If you follow RFC 3986 you should be ok.
• Convert the filename to this encoding:
  [text field]
Use iconv to change the filename before its saved to disk. Odds are you will not need to set this. Example: CP1255 http://php.net/iconv
• [ ] Enable PHP error cacheability checking
Checked - Do not cache the page if there are PHP errors. Unchecked - Cache pages even if it might contain errors.
• Do not cache if a message is on the page
Selected - Do not cache the page if there are Drupal messages. Not Selected - Cache pages even if it might contain a Drupal message.
• Statically cache specific pages: (radio buttons).
  (x) Cache every page except the listed pages
  ( ) Cache only the listed pages
  ( ) Cache pages for which the following PHP code returns TRUE (PHP-mode, experts only).
  Pages:
  [ text box ] This is a standard Drupal type of setting.
Enter one page per line as Drupal paths. The '*' character is a wild-card. Example paths are 'blog' for the blog page and blog/* for every personal blog, <front> is the front page. If the PHP-mode is chosen, enter PHP code between <?php and ?>. Note that executing incorrect PHP-code can severely break your Drupal site.

Back to top

Boost directories and file extensions

• Cache Dir: *
  [ cache ]
This is the default directory that will hold the cached files or pages.
• [x] Do not store the cache file path in the database
Settings Tip i18n: Enable this for an i18n site.
Settings Tip Multi-site: Enabling will allow for correct multi-site caching, in cases where different content is served from the same Drupal installation, based on domain.
Examples: Multi-site with a single/shared database, site translation detection based on domain, and the Domain Access module.

Generated output storage (HTML, XML, AJAX) -expandable section-

• Dir for non compressed files:
  [ normal ]
Leave blank to not use a subdir
• Dir for compressed files:
  [ normal ]
Leave blank to not use a subdir
• Character used to replace "?": *
  [ _       ]
Best to leave at _
• Cache html file extension: *
  [ .html  ]
The file extension to append to the file name of the generated cache files.
Note: This setting is of no relevance to any public URLs, and it is strongly recommended to leave this as the default '.html' unless you know what you are doing. If you change this, you must also change the URL rewrite rules in your web server configuration (.htaccess for Apache, lighttpd.conf for Lighttpd), or caching will not work.

Static storage (CSS, JS) -expandable section-

• Dir for more permanent files (css/js):
  [ perm   ]
Leave blank to not use a subdir
• Dir for compressed more permanent files (css/js):
  [ perm   ]
Leave blank to not use a subdir
• Character used to replace "?" in the permanent dir: *
  [ _       ]
Best to leave at _
• Cache css file extension: *
  [ .css    ]
The file extension to append to the file name of the generated cache files.
Note: This setting is of no relevance to any public URLs, and it is strongly recommended to leave this as the default '.css' unless you know what you are doing. If you change this, you must also change the URL rewrite rules in your web server configuration (.htaccess for Apache, lighttpd.conf for Lighttpd), or caching will not work.
• Cache javascript file extension: *
  [ .js     ]
The file extension to append to the file name of the generated cache files.
Note: This setting is of no relevance to any public URLs, and it is strongly recommended to leave this as the default '.js' unless you know what you are doing. If you change this, you must also change the URL rewrite rules in your web server configuration (.htaccess for Apache, lighttpd.conf for Lighttpd), or caching will not work.

Back to top

Boost advanced settings

• Clear expired pages on cron runs: (radio buttons).
  (  ) Disabled
  (x) Enabled
Caution - If disabled you will need some other method of clearing cached pages. If disabled, files have to be manually deleted from server or cleared using the administrative interface (Enable the Boost: Pages cache status block).
• [  ] Check database timestamps for any site changes. Only if there's been a change will boost flush the expired content on cron. (this helps to reduce server load by keeping cached pages that have not changed)
• Pre-process function:
  [ < c o d e > ]
The name of a PHP function used to pre-process the contents of each page before writing them out to static files. The function is called with the contents of the page passed as a string argument, and its return value is used as the data written out to the disk. (It is rare that anyone will need this)
• [x] Only allow ASCII characters in path.
Settings Tip i18n: Disable this for an i18n site.
Only allowing ACSII characters is a safe way to cache pages. Fair warning, disabling this may cause "page not found" errors depending on your url structure (spaces are bad, ect...). If you follow RFC 3986 you should be ok.

• [  ] Flush all sites caches in this database (singe db, multi-site).
Settings Tip i18n: Enable this setting.
This will flush/expire all cached files stored in this database, instead of only being specific to this site. Useful for i18n sites. You need to setup a separate cron call for each database (in your multisite install) either way though. This covers shared database usage; or place the boost tables into the a shared database, to have this setting work in a multiple database environment.
• [x] Asynchronous Operation: output HTML, close connection, then store static file.
Run php in the background. When a cached page is generated, this will allow for faster page generation; downside is the headers are not the standard ones outputted by Drupal; sends "Connection: close" instead of "Connection: Keep-Alive".
• [  ] Clear all empty folders from cache.
Disable this if you have to set settings for each dir/subdir, due to the way your server operates (permissions, etc...).
Note: This is not fully functional yet, but should not be a problem.
• [x] Clear all cached pages referenced via CCK with a node on insert/update/delete
The Node Referrer module is recommended.
Note: If a node is referenced in another node, and either one is updated or deleted then both nodes get cleared from the boost cache. On node creation if you reference a node, that referenced node gets cleared. Allows for very long node cache lifetimes.
• [x] Clear all cached terms pages associated with a node on insert/update/delete
Works with view's taxonomy/term/% path as well as core.
Note: When a node belongs to term/1 and it gets created/updated/deleted, the cached page(s) for term/1 will be cleared.
• Clear all cached pages in a menu on an insert/update/delete operation:
  (x) Disabled
  ( ) Only Flush Menu Parrents, Siblings & Children
  ( ) Flushes Entire Menu Tree
This can flush a lot of pages depending on your menu structure.
• [x] Clear all cached views pages associated with a node on update/delete
• [x] Clear all cached views pages associated with a node on insert
WARNING: This can be very slow, all views get run to find out where this node lives.
• [  ] Clear Boosts cache when site goes offline.
Under site maintenance when the status is set to offline, boost clears it's cache. If you do not want this to happen, clear this checkbox. Pages that are not cached will still send out a Site off-line message, so be smart if turning this off.
• [  ] Overwrite the cached file if it already exists.
This is useful if crawling a site before it goes live.
Note: Required if using the "Do not flush expired content on cron run, instead re-crawl and overwrite it" functionality.
• [  ] Do not cache if PHP error on page.
Selected - Do not cache the page if there are PHP errors.
Not Selected - Cache pages even if it might contain errors.
Note: Enabling this can get quite annoying because there's a lot of code out there that may throws errors.
• [x] Do not cache if a message is on the page
Selected - Do not cache the page if there are Drupal messages.
Not Selected - Cache pages even if it might contain a Drupal message.
• [  ] Turn off clean URLs for logged in users.
Settings Tip: Enabling this can give the logged in user a performance boost.
Drupal will output non clean URLs for non anonymous users. This allows for the browser to cache the page and still have logging in work. This is more on the extreme side of tweaks.
Note: Recommended for sites that don't change much and have only administrator logins. Enabling requires you to update your htaccess file with new rules. Allows for users that hit the same page to not hit your server. Also allows for reverse proxies to cache the page.
• [x] Aggressive Gzip: Deliver gzipped content independent of the request header.
In order to deliver gzipped content independent of the header, this will test for gzip compression in a small iframe by sending it compressed content. This compressed content is javascript which creates a cookie with a note of gzip support. On the server side it checks for the cookie and then sends out gzipped content accordingly. See Website Performance - Activate Gzip. In short some firewalls/proxies mangle the gzip header; this gets around that. iframe is on non compressed version of the frontpage only.
• Files: Enter in a 4 digit number (octal) that will be used by chmod(). Example 0664:
  [ _______ ] (text box)
Sometimes because of funky servers you need it use a different file mode then the default.
• Directories: Enter in a 4 digit number (octal) that will be used by chmod(). Example 0775:
  [ _______ ] (text box)
Sometimes because of funky servers you need it use a different file mode then the default.
• [  ] Expire content in DB, do not flush file.
Instead of flushing the file ASAP this will set the database entry to expired. File will be flushed on next cron run. This is more on the extreme side of tweaks.
• Ignore cache flushing:
  (  ) Disabled
  (x) Only Ignore Clear Entire Cache Commands (Recommended if caching css/js files)
  (  ) Ignore Clear Entire Cache Commands & Cron Expiration
  (  ) Ignore All Delete Commands (Not Recommended)
Settings Tip Ignore Flushing: Make a selection to put your site into a static cached state. It is recommended to turn on CSS & JS caching if one of these are selected. If you want the cache cleared completely choose the first selection.

Watchdog Verbose Setting:

• [5 Record all errors to the db log] (select box)
  
  This sets the amount of errors recorded to watchdog(DbLog) when a static state is selected. Viewable at Administer > Reports > Recent log entries
• [x] Disable warning about reaching the ext3 file system subdir limit.
  
  Disable the warning on the status page about coming close to the file system directory limit. The warning is triggered when at 31,000 subdirectories. Boost will stop creating new subdirectories when 31,998 subdirectories have been created.
  Note: This can be a slow operation & might even timeout. If your status page will not load, Disable this warning.

Boost Retro Mode (no database) -expandable section-

• [  ] NOT RECOMMENDED. Do not use the database at all.
  
  Go 'old school' and don't use the database. Very extreme tweak & support for features in this mode is pretty much non existent.

Back to top

Boost crawler

Cron starts the crawler. Each thread will grab a set number of URLs with each operation. The crawler operations will continue to run until all pages that are in the cache or have been in the cache are regenerated to the cache file. This has been done with a custom batch API. Crawling new pages will be added in sometime soon.

Settings Tip: If you wish to use the cron crawler, enable these settings.
• Overwrite the cached file if it already exists.
• Expire content in DB, do not flush file.
• Enable the cron crawler.

• [  ] Enable the cron crawler
Pre-cache boosted URL's so they get cached before anyone accesses them. Enable the crawler first and save settings to use Preemptive Cache settings.
• [  ] Do not flush expired content on cron run, instead re-crawl and overwrite it.
The "Overwrite the cached file if it already exists" must be turned on in order to enable this.
Notes:
Enable for fast but potentially stale pages.
Disable for slow but always fresh pages.
Settings Tip: Enabled is very useful for shared hosting if used in conjunction with the "Check database timestamps for any site changes" setting. If your site takes a long time to generate a page (more then 3 seconds) then this is highly recommended. Updating your htaccess rules is required if turning this on.
• [  ] Preemptive Cache HTML
Enable caching of this content type with this checkbox.
• [  ] Preemptive Cache XML
Enable caching of this content type with this checkbox.
• [  ] Preemptive Cache AJAX/JSON
Enable caching of this content type with this checkbox.
• [  ] Crawl All URL's in the url_alias table.
Enable the crawler first to enable this checkbox.
Note: Recommended that you do not leave this turned on. Use it to kick start the boost cache on a new install.
• Number of URLs to grab at a time when loading up the crawler table:
  [10000]
You might need to adjust this (shrink) if you get mysql errors when starting the crawler. Increase if your trying load up the crawler with a lot of URLs, as this can make the operation be faster.
• Crawler Throttle:
  [ 0 ] (enter a number in micro seconds)
Wait X micro seconds in between hitting each url. 1000000 is 1 second.
• Crawler Batch Size:
  [ 12 ] (enter number of URLs)
Number of URL's each thread grabs per database operation.
• Number Of Threads:
  [ 2 ] (select box)
Be careful when choosing more then 2 threads.

Boost crawler - Live info -expandable section-

• Crawl Rate - Seconds Per Node (highly inaccurate):
  [0.01]
• Crawl ETA - highly inaccurate:
  [0 sec]

[Stop Crawler. xxx URL's left] (stop the crawler button)

[Reset Crawler & Cron Semaphore] (button)


Resets the crawler and clears the cron semaphore entry from the database (a clean slate).

Back to top

Boost Apache .htaccess Settings Generation

After settings on the entire page have been saved. Goto: Boost htaccess rules generation page, copy the rules and paste them into the Drupal htaccess file.
(see next section below: Prepare htaccess for Boost)
The default selections in this section should work for most sites.

• Servers URL or Name:
  (x) %{SERVER_NAME}
  (  ) %{HTTP_HOST}
  (  ) www .example.com
  Best to leave these as %{}, only try the last option(s) if boost is still not working.
• Document Root:
  (x) %{DOCUMENT_ROOT}
  (  ) /home/user-name/public_html
  Value of is recommended for this server. Please open an boost issue on drupal.org, since apache and php are not configured correctly.
• ETag Settings:
  (x) Do Nothing (default)
  (  ) Set FileETag 'None' - Do not send an etag
  (  ) Set FileETag 'All' - Default if enabled
  (  ) Set FileETag 'MTime Size' - Useful in server clusters
  Uses FileETag Directive to set ETags for the files cached by Boost.
  More info on this subject
• Boost Tags:
  (x) Inject boost tags at the bottom of the file (default)
  (  ) Set Header and bottom tags
  (  ) Only Set the header tag
  In order to identify that the page is being served from the cache Boost can: Set a comment at the bottom of the page, indicating that this page is cached by boost; It can also send out a header that will identify any files served from the boost cache; Or it can do both.

Important htaccess Notes: The htaccess rules will be automatically generated for the selections that are made on the entire Boost settings page. This is done to make Boost as fast as possible.
The boost/htaccess folder contains sample rules that can be used, however, the generated rules will make Boost faster!
(see next section below: Prepare htaccess for Boost)

Clear Boost's Database

[Reset boost database:(0) records] (button).

Warning: This gives you a clean slate for the boost database, use with caution.

[Save Configurations] (button) [Reset to Default] (button)

Back to top

Prepare .htaccess File for Boost

Required for cached pages to be served.

This is easy and anyone can do it without any trouble, follow along.

Save a copy of the .htaccess file from your Drupal folder for safe keeping.
It's easy to get a new one anytime if you need it, Drupal is always open.

Goto: Administer > Site configuration > Performance > Boost htaccess rules generation
system path admin/settings/performance/boost-rules

Right click anywhere in the iframe that displays the rules, Left click on Select All (highlights the text), Right click again, Left click on Copy (that puts the file on your clipboard).

Double click on the Drupal .htaccess file to open it. Look down through the file to see the part(shown below) It's 8 lines from the bottom.

# RewriteBase /
(Left click once between these 2 lines, Right click and choose Paste)
# Rewrite URLs of the form 'x' to the form 'index.php?q=x' .

Save the file. Put it back in with the rest of the Drupal files where it was.
All done, the pages should now be served by Boost after all the settings are completed.
Check the pages using the instructions in the (system check) section on this page. If they are not showing the html comment, try different selections in the htaccess generator on the performance/boost settings page.

Additional notes for htaccess:
The module package has 3 htaccess templates included in the Boost/htaccess folder (boosted1.txt, boosted2.txt and default.txt). These templates may be helpful in some cases and are good for reference. The default.txt shows the exact placement of the rules. The boosted1.txt relying on SERVER_NAME and boosted2.txt relying on HTTP_HOST. These templates are there if you should need them. It is always best to use the htaccess generated rules from the UI, as they will allow boost perform better and faster by providing custom htaccess rules tailored to your settings.

Back to top

Prepare robots.txt File for Search Engines

This is needed in order to prevent the output of this from accidently getting indexed by search engines. Locate and open the robots.txt file in the Drupal root with a text editor. Add Disallow: /boost_stats.php to the file as shown below. Save the change and put the file back in the Drupal root.

Back to top

Prepare Settings.php File for Cron

Settings Tip: This is not a required step for Boost to run. If cron is not clearing the cache as expected, you may need to set the base_url.

Back to top

Drupal Performance [tab]

• Goto: Administer > Site configuration > Performance
  system path admin/settings/performance

Anonymous page caching

Enabling the page cache will offer a significant performance boost. Drupal can store and send compressed cached pages requested by anonymous users. By caching the first request to the page, Drupal does not have to construct the page each time it is viewed. The page must first be visited by an anonymous user in order for the cache to work on subsequent requests for that page. Boost & Core caching do not work for logged in users

• Caching mode:
  (x) Disabled (boost will be the cache for anonymous users)
  (  ) Normal (recommended for production sites, no side effects)
  (  ) Aggressive (experts only, possible side effects)
• Minimum cache lifetime:
  [< none>] (select box) none is fine for small sites.
On high-traffic sites, it may be necessary to enforce a minimum cache lifetime. The minimum cache lifetime is the minimum amount of time that will elapse before the cache is emptied and recreated, and is applied to both page and block caches. A larger minimum cache lifetime offers better performance, but users will not see new content for a longer period of time.
• Gzip page compression (Boost & Core):
  (  ) Disabled
  ( x) Enabled
By default, Drupal compresses the pages it caches in order to save bandwidth and improve download times. This option should be disabled when using a webserver that performs compression.

[Clear core page cached data: (0) pages] (Button)

Block cache

Enabling the block cache can offer a performance increase for all users by preventing blocks from being reconstructed on each page load. If the page cache is also enabled, performance increases from enabling the block cache will mainly benefit authenticated users.

• Block cache:
  (  ) Disabled
  (x) Enabled (Recommended)
Note that block caching is inactive when modules defining content access restrictions are enabled.

Bandwidth optimizations

Drupal can automatically optimize external resources like CSS and JavaScript, which can reduce both the size and number of requests made to your website. CSS files can be aggregated and compressed into a single file, while JavaScript files are aggregated (but not compressed). These optional optimizations may reduce server load, bandwidth requirements, and page loading times.

These options are disabled if you have not set up your files directory, or if your download method is set to private.

• Optimize CSS files:
  (  ) Disabled
  (x) Enabled (Recommended)
This option can interfere with theme development and should only be enabled in a production environment.
• Optimize JavaScript files:
  (  ) Disabled
  (x) Enabled (Recommended)
This option can interfere with module development and should only be enabled in a production environment.

Clear cached data

Caching data improves performance, but may cause problems while troubleshooting new modules, themes, or translations, if outdated information has been cached. To refresh all cached data on your site, click the button below. Warning: high-traffic sites will experience performance slowdowns while cached data is rebuilt.

• [Clear cached data] (button)
Clears the database and the Boost cache.

[Save configuration] (button)   [Reset to Defaults] (button)

Back to top

System Check and Verify Boost Functions

• Check the status page
  Goto: Administer > Reports > Status report
  system path admin/reports/status
  Check for any errors or notices.
• Log out from Drupal (or use another browser) to browse around your site as an anonymous user. Ensure that static files are indeed being generated into the Boost cache directory specified. If you opted to use gzip, check that gzipped files are being generated in the directory you specified for gzip. The performance settings page shows how many pages are being cached by Boost, and (for pages Boost cannot cache) by Drupal core.

Check Pages to Insure Boost is Performing

To check whether you have a static or dynamic version of a page. Visit the page as an anonymous user, visit a second page, then back to the original page. Click view source in your browser and look at the very end of the HTML source code. You have the cached or static version produced by Boost if the last line looks like this:

Back to top

Boost Administrative and Stats Blocks

• There are 3 blocks that you can add to help, 2 for the administrative side (status, page configuration), and 1 block to support core stats.

Goto: (administer > Site building > Blocks > List) to place them.

• The visibility of blocks can also be configured by role and page.
On the Blocks list page, to the right of each block click 'configure'.

Status Block

This block shows the current status of the page as far as Boost is concerned. It will state if the page is served 'live' or by 'Boost', the expiration of the page and has a Flush Page button to clear the page from the cache manually. The block only appears if you're not user 0 and provides useful information about PHP errors on the page.

Page configuration Block

This block allows the administrator to set pages individually. Including setting for minimum cache lifetime(select box), preemptive cache(on or off), scope(page ID, content type or content container).

Stats Block

Drupal's core stats is supported. Configure the "Popular content" block, but then disable it. Place the "Boost: AJAX core statistics" in its place. If ajax stats are loading too slowly, copy stats/boost_stats.php to your webroot and enable "Cache Statistics Block". The cache gets updated on cron runs. This only shows up on pages that get cached and can be used to collect data and not display it.