staticCacheControl is a plugin that caches (and optionally gzips) Zenphoto pages on the file system to minimize PHP execution, making your dynamic image gallery run as fast and light on resources as a static website.
This is a beta release. staticCacheControl has been tested on my private Zenphoto installation but not on a “live” site. Please send me any feedback, suggestions, improvements, criticisms.
No matter how well you optimize PHP processing through code optimizations, opcode and database query caching, a dynamic PHP application still can’t beat the performance (speed/time, CPU/memory usage) of a website with the same content displayed using static HTML files. However, good luck updating thousands of static HTML pages by hand. 
With staticCacheControl, you can have the best of both worlds.
staticCacheControl automates the process of generating static HTML copies of your Zenphoto pages, redirecting visitors to these cached pages when possible, and also the validating/refreshing of the static cache when your Zenphoto pages change. Thus, you can enjoy the performance of static pages without the hassle of updating them manually.
This plugin is designed for use in the album.php, albumarchive.php, image.php, index.php of your theme. It can be used in conjunction with (after) httpCacheControl for optimal results.
Example usage:
Place static_cache_control.php in your theme directory, like “/themes/default“. Insert one of the following chunks of code at the top of your theme’s index.php, like “/themes/default/index.php” (but after httpCacheControl() if present)
include_once('static_cache_control.php');
staticCacheControl(__FILE__);Or, enable gzip compression
staticCacheControl(__FILE__, 0, true);
If you got $mtime from elsewhere, like
$mtime = httpCacheControl(__FILE__);
then pass $mtime
staticCacheControl(__FILE__, $mtime, true);
The first required parameter is the path to the file that should be used to calculate Last Modified date, usually “__FILE__”.
The second optional parameter is the Last Modified date of this page. If another function, like httpCacheControl(), already calculated the Last Modified date, be sure to pass the value using this second parameter to avoid redundant calculations. If omitted or set to 0, staticCacheControl will attempt to calculate the Last Modified date, so httpCacheControl is not required.
The third optional parameter specifies whether staticCacheControl should gzip compress cached pages. If omitted, gzip files will not be created.
Read on for .htaccess code to minimize PHP execution further.
How it works:
staticCacheControl generates static HTML caches of Zenphoto pages, optionally applies gzip compression, and stores them on the file system for future retrieval with minimal PHP processing. Static cached pages are stored in the “/ZENPHOTO/cache/static” directory where “ZENPHOTO” is your installation directory. The directory structure in the static cache mirrors the URLs used to access Zenphoto pages. For example, the page
/ZENPHOTO/album/img.jpg/suffix
is cached to
/ZENPHOTO/cache/static/album/img.jpg/suffix/index.html(.gz)
When a Zenphoto page is requested, staticCacheControl automatically redirects the client to the static cache if the cache is fresh; the gzipped cache file is used if gzip is enabled and the client accepts gzip. If the cache is does not exist or is stale, staticCacheControl creates/updates the static cache file. This plugin uses the same logic as httpCacheControl to determine if a cache is stale. Please see this page for details.
PHP processing can be further minimized by using .htaccess directives such that the web server handles the redirection automatically and transparently. Insert the following code after the “RewriteBase” line and before other “RewriteCond” and “RewriteRule” lines in Zenphoto’s .htaccess.
# BEGIN staticCacheControl redirection
# Redirect if current second is greater than 10
# Visits during seconds 1-10 (i.e. 1 in 6 visits on average) will execute PHP to validate cache
# 0-58: the larger the number, the more likely PHP will be executed to validate cache
# Comment out if you have some other method to periodically validate/freshen your static cache
RewriteCond %{TIME_SEC} >10
# Redirect if user isn't an admin or hasn't left a comment, signified by lack of a zenphoto cookie
RewriteCond %{HTTP_COOKIE} !^.*zenphoto.*$
RewriteCond %{HTTP:Accept-Encoding} gzip
# Check if the cache file exists
# !! Replace 4 instances of ZENPHOTO below with your installation directory !!
RewriteCond %{DOCUMENT_ROOT}/ZENPHOTO/cache/static/$1/index.html.gz -f
# Redirect any URL starting with "RewriteBase" and ending with a "/" or not
# Don't save the trailing slash
RewriteRule ^(.*)/?$ /ZENPHOTO/cache/static/$1/index.html.gz [L]
RewriteCond %{TIME_SEC} >10
RewriteCond %{HTTP_COOKIE} !^.*zenphoto.*$
RewriteCond %{DOCUMENT_ROOT}/ZENPHOTO/cache/static/$1/index.html -f
RewriteRule ^(.*)/?$ /ZENPHOTO/cache/static/$1/index.html [L]
# END staticCacheControl redirectionThe problem with bypassing PHP execution is that you still must somehow validate or refresh your cache periodically. Thus, the above directives do not bypass PHP execution all the time. The code
RewriteCond %{TIME_SEC} >10forces ~1 in 6 visitors, on average, to execute the PHP code to validate the cache. (Visitors from the 0th to 10th second of each minute execute PHP code and trigger cache validation; visitors from the 11th to 59th second of each minute are transparently redirected to the static cache.) Admins and visitors who leave comments also execute PHP to validate the cache. If you have a more elegant method of validation, please share!
Ideas:
- Use a cron job to periodically delete the entire “/ZENPHOTO/cache/static” directory and redirect ALL visitors to static cache 100% of the time?
- Invalidate more than just the currently viewed page (ex. the entire album) if a cached page is stale?
- Execute PHP to validate cache for a longer chunk of time during off-peak hours (ex. 1AM-6AM) instead of doing that for a few seconds every minute?
Performance:
From my rudimentary profiling, execution of staticCacheControl takes from less than 10 milliseconds to a few dozen milliseconds on my shared hosting service. Thus, in the case where PHP is executed and the static cache is fresh, this plugin cuts your page’s execution time down from hundreds of milliseconds to ~10-50ms. In the case where the web server transparently redirects you to the static cache, 0ms is spent on PHP execution. In the case where the static cache is stale or doesn’t exist, your page takes an extra ~10-50ms to load. Also remember that time is not the only resource saved.
Note that benchmarks were performed in a PHP5 environment. PHP4-compatible functions are included but not tested (yet).
Download:
zenphoto_static_cache_control.zip
FAQ:
Q: Why aren’t the .htaccess directives working? I am visibly redirected to the cache file URL every time.
A: Are you an admin or have left a comment on the site? If so, you have a *zenphoto* cookie, and you will execute PHP code instead of getting redirected by the web server. Try clearing your cookies, using a different browser or computer.
Known issues:
- Redirection by PHP (rather than web server URL rewriting) is visible to the user as the URL of the page changes to the URL of the static cached file. Page navigation is unaffected; it’s just inelegant. I don’t believe it is possible to redirect in PHP transparently, is it?
- Static cache validation/refreshing is inelegant. PHP execution is required to validate a cache file; the more often we bypass PHP execution, the higher the likelihood of stale cache files not getting invalidated. To-Do: actions performed in Admin pages should trigger cache validations, but this would require modifying zp-core files.
- /etc/mime.types on some servers, like Red Hat and CentOS, have (erroneously?) an entry for gzip, causing *.html.gz files to be sent with a “Content-Type: application/x-gzip” header. Browsers will barf unless gzip compressed files are sent with a “Content-Type: text/html” header. Work around this by creating a .htaccess file in “/ZENPHOTO/cache” with the following directives:
AddEncoding x-gzip .gz
AddType text/html .gz
Changelog:
December 02, 2007
- added support for comments; last modified time calculations include the date of the most recent comment
- comments can also be submitted from a static cache page
November 30, 2007
Credits:
Inspired by Donncha O Caoimh’s WP Super Cache. Workaround for gzip Content-Type by Dennis.
