Voting starts in March for the Drupal Association Board election.
This patch introduces an option for file-based caching. When enabled, a 'cache' subdirectory is created in the files/ directory, and cache data is written there. The best performance improvement will be seen when both the file cache is enabled and a minimum cache lifetime is set.
A few comments about the current design:
- The cache can be 'disabled', 'database', or 'file'
- The cache subdirectory is hardcoded to the name 'cache' within the directory_path as t() is unavailable during early bootstrapping. An additional configuration option could be provided to manually set the path to and the name of the cache directory, but I'm choosing to avoid this extra level of adminsitrative overhead.
- To come up with a unique name for each cache entry that is filesystem safe, I'm using a simple md5 of the cache key. Hash collisions are extremely unlikely, but if that was ever to become a problem cache_filename() could be enhanced.
- Cache garbage collection is less efficient at the filesystem level than at the database level, so a _cron hook is responsible for cleaning up old cache entries. Cache entries can still be expired, and expired entries are detected by looking at their creation date.
- This improves upon my earlier filecache efforts (for Drupal 4.0) in that everything is cached to the filesystem, not just pages.
- Nothing has been done to address potential cache-coherency issues when dealing with one database backend and multiple webserver frontends. Ideas, suggestions, and/or patches are welcome.
On my devel system the patch appears to work as intended. Additional testing would be greatly appreciated, as would benchmarking comparisons.
(I'll be offline January 20th through January 29th, but I'll pick this up again when I return if no-one else has run with it. The ultimate goal is to get support for file-based caching in core.)