{eac}ObjectCache Extension

Description

The {eac}ObjectCache is a light-weight and very efficient drop-in persistent object cache that uses a fast SQLite database and even faster APCu shared memory to cache WordPress objects.

See The WordPress Object Cache

The WordPress Object Cache is used to save on trips to the database. The Object Cache stores all of the cache data to memory and makes the cache contents available by using a key, which is used to name and later retrieve the cache contents.

By default, the object cache is non-persistent. This means that data stored in the cache resides in memory only and only for the duration of the request. Cached data will not be stored persistently across page loads unless you install a persistent caching plugin.

Here, an object is any piece of data - a number, text, a set of database records, an API response, etc. - that can be referenced by a name or key. Objects are categorized by a group name. Groups help identify what an object is and how it is used.

{eac}ObjectCache replaces the default WordPress object cache to not only store data in process memory but to also store data persistently, across requests, in APCu shared memory and/or in a SQLite database, increasing the likelihood of cache hits and decreasing the need for costly computations, complex MySQL database queries, and remote API requests.

SQLite is a fast, small, single-file relational database engine. By using SQLite to store objects, {eac}ObjectCache is able to manage a relatively large amount of data (groups, keys, and values) in a very efficient and fast data-store.

APCu is a shared, in-memory, persistent cache available only when the APCu PECL Extension is installed. {eac}ObjectCache uses APCu as an intermediate cache between the L1 memory cache and the L2 SQLite database cache providing extremely fast object retrieval,

{eac}ObjectCache always uses per-request, in-memory caching and may operate with either APCu memory caching or SQLite database caching - or both. APCu memory caching uses a single block of memory shared by all PHP requests and is persistent until and unless the cache is cleared or the server is rebooted (or PHP restarted). SQLite database caching is persistent until and unless the cache is deliberately cleared.

Features

• Lightweight, efficient, and fast!
• L1 (in-process memory) and L2 (APCu & SQLite) caching.
• Supports Write-Back (delayed transactions) or Write-Through SQL caching.
• Caching by object group name.
  • Preserves uniqueness of keys.
  • Manage keys by group name.
  • Supports group name attributes (:sitewide, :nocaching, :permanent, :prefetch)
• Pre-fetch object groups from L2 to L1 cache.
• Caches and pre-fetches L2 misses (known to not exist in L2 cache).
  • Prevents repeated, unnecessary L2 cache reads across requests.
• Multisite / Network support:
  • Cache/flush/switch by blog id.
• Caching statistics:
  • Cache hits (typically above 90%).
  • Overall and L1/APCu/L2 hits, misses, & ratio.
  • L1 hits by object groups.
  • Number of APCu and SQLite keys stored.
  • L2 select/update/delete/commit counts.
• Supports an enhanced superset of WP Object Cache functions.
• Easily enabled or disabled from {eac}Doojigger administrator page.
  • Imports existing MySQL transients.
  • Exports cached transients to MySQL when disabled.
• Automatically cleans and optimizes SQLite database.
• Optionally schedule periodic cache invalidation and rebuild.
• Uses the PHP Data Objects (PDO) extension included with PHP.

While {eac}ObjectCache does support multiple installations on a single server it does not support multiple servers per installation. SQLite and APCu work only on a single server, not in a clustered or load-balanced environment.

Configuration Alternatives

Assuming you have SQLite and APCu installed, what are your best options?

1. Fastest Caching

   • Disable SQLite. [^1]
     • define( 'EAC_OBJECT_CACHE_USE_DB', false );
   • Uses in-process memory and APCu shared memory.
   • Advantage
     • Fast memory-only access.
   • Disadvantage
     • APCu may invalidate data under memory constraint.
     • APCu cache is lost on system or PHP restart.

2. Less memory (almost as fast)

   • Disable SQLite. [^1]
     • define( 'EAC_OBJECT_CACHE_USE_DB', false );
   • Optimize memory use. [^1]
     • define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );
   • Uses in-process memory and APCu shared memory.
   • Advantage
     • Fast memory-only access.
     • Conserves per-request memory by not pushing APCu hits to in-process memory.
   • Disadvantage
     • Slightly slower to access APCu memory over in-process memory.
     • APCu may invalidate data under memory constraint.
     • APCu cache is lost on system or PHP restart.

3. Most resilient (and still fast)

   • Do nothing, this is the default.
   • Uses in-process memory, APCu shared memory, and SQLite database.
   • Advantage
     • Most cache hits will come from in-process and APCu memory.
     • SQLite retains cache data after restart.
   • Disadvantage
     • Must keep SQLite database (on disk) updated.

4. Resilient, efficient, and fast (recommended)

   • Optimize memory use. [^1]
     • define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );
   • Uses in-process memory, APCu shared memory, and SQLite database.
   • Advantage
     • Most cache hits will come from in-process and APCu memory.
     • Conserves per-request memory by not pushing APCu hits to in-process memory.
     • SQLite retains cache data after restart.
   • Disadvantage
     • Slightly slower to access APCu memory over in-process memory.
     • Must keep SQLite database (on disk) updated.

5. Least efficient (default when APCu is not installed)

   • Disable APCu. [^1]
     • define( 'EAC_OBJECT_CACHE_USE_APCU', false );
   • Uses in-process memory and SQLite database.
   • Advantage
     • Saves resources by not taking up APCu reserves.
     • SQLite retains cache data after restart.
   • Disadvantage
     • All cached data read from disk.
     • Must keep SQLite database (on disk) updated.

[^1]: These options may be set from the {eac}Doojigger administration screen.

When using SQLite, delayed writes (see below) dramatically improves efficiency by only writing updates at the end of the script process.

Inside The Numbers

• When a request results in a L2 SQL miss, the key is added to the L1 memory or L2 APCu cache as a miss so that additional requests for the same key do not result in additional SQL selects. This is known as a negative hit and still counted as a cache miss.