midcom.services.cache
MidCOM provides a Caching Engine to help Midgard perform well on high-volume websites. It captures the HTML output, accociates it with the currently processed URL and uses this cached output if it detects a cache hit.
Since it is difficult to detect changes on the underlying data, the first stage of the caching engine will invalidate everything upon any change. The notice about this changes have to come from the components itself.
Basic Operation
The caching engine uses DBM-style databases as cache, where the URL serves as the key to the main index. Stored as values are serialized, accociative arrays which contain all neccessary cache-data. The cached output is stored as a plain html file on disk.
The caching engine will be started at MidCOM application start-up where it initializes and looks for a already cached page.
More interesting is the Post-Processing, which has to be enabled by calling a cleanup function after all output is complete. This has to be kept in mind if you use the exit() call.
MidCOM therefore introduces a couple of new functions to make your life here easier. These functions provide:
- Start of page processing
- HTTP header output (
midcom_application::header()) - End of page processing (
midcom_application::finish()) - Cache invalidation (
midcom_helper__cache::invalidate_all()) - No-Cache flagging (
midcom_helper__cache::no_cache()) - Expiration mechanism (
midcom_helper__cache::expire())
The caching engine captures the output using PHP's output buffering function. Caching starts with loading the main MidCOM file and will end upon the call to midcom_application::finish(). Caching is implicit in process, meaning that a second request with the same URL will automatically use the cached HTML output instead of launching the framework. The output will be written to a file (see below).
Calling the method midcom_helper__cache::no_cache() during the MidCOM run will prevent the current page from entering the Cache, which is very useful for truly interactive parts of a website.
A less restrictive variation of this is the method midcom\_helper\_\_cache::expire() which allows you to limit the time a cache page may live. This method takes a timestamp as an argument and compares it with the current time. If the expiration time is reached, the page in question is regenerated.
Forcing a cache invalidate
If you want to invalidate the MidCOM cache manually, you can access your website using the /midcom-cache-invalidate URL. This will invalidate the full output cache.
Cache structure
The cache consists of two parts:
The cache table is a simple DBM flat file databse which stores all neccessary information about any entry in the cache. The URL of the cached request serves as key here, with a serialized array as data. This array holds the filename of the cached data and some other information required for cache processing (expiration dates for example). Details about this data structure can be found in the documentation of the class midcom\_helper\_\_cache.
The cache directory is where the cached output is stored. The flat files consist of the complete output of the MidCOM run that is invoced if the URL in question is queried.
The default location for the output cache files is /var/cache/midgard/midcom/content/www.example.net\_80.db4.