Home  /  RSS  /  RSS Comments  /  Enter

Caching System: Internals

7/31/08, by artyom ; Posted in: Cache; 0 comments

One of the latest implemented features of CppCMS is a caching system.

Each cached entry is stored using:

For example: main page that displays 5 recent posts may have a key main_page and triggers: post_123, post_124, ... , post_128. More then that, each time, during page build, when you fetch some cached data, like a sidebar or set of options, their sets of triggers are automatically added to the set of triggers of the page you build.

For example, when the page is created and sidebar block is fetched from cache all its triggers are automatically added: if sidebar depends of options, then trigger sidebar and options will be automatically added to triggers of main_page.

Thus, when certain trigger is risen, all pages that depends on it are automatically trashed. This makes a cache system quite powerful and easy to control correct data representation.

The developer is expected to create a rational model of data/triggers that represent the relations between parts of internal data and rise these triggers when committing changes to database.

There are 3 data types that can be stored in cache:

  1. Page: consists of a full html/xml output page and its gzip compressed copy.
  2. Partial HTML content: parts of page like "sidebar", "signature" or others that can be reused in many places. They are actually represented as std::string
  3. Any C++ Object that inherits serializable class and implements methods for storing and restoring itself. It is useful for caching of DB data or any suitable C++ object.

As in case of different worker/API modes, cache interface has several independent working models, more then that, it can be easily extended with new one.

There are 4 caching modules that will be shipped with CppCMS:

  1. None --- the cache is disabled --- default mode.
  2. Thread shared -- only different threads of same process has an access to the cache --- to be used with thread pool worker model.
  3. Fork shared1 -- different processes that were forked from the same parent can access the cache placed in shared memory --- to be used with mod prefork.
  4. Distributed2 -- client-server model similar to memcached but more powerful due to support of triggers. It should be used on distributed systems or with mod process.

If your cache implementation does not relay on triggers and uses timeouts only all cache modes can be mixed with all worker modes.

This blog runs using mod-prefork and uses fork shared cache.

Footnotes:

  1. Fork caching mode is actually thread cache placed almost as-is to shared memory segment.
  2. Distributed cache is not implemented yet. Will be done for next beta releases.

Add Comment:

 
 the email would not displayed
 

You can write your messages using Markdown syntax.

You must enable JavaScript in order to post comments.

Pages

Categories