OllieJones

A <a href="https://developer.wordpress.org/reference/classes/wp_object_cache/#persistent-cache-plugins" rel="nofollow ugc">persistent object cache</a> helps your site perform well. This one uses the widely available <a href="https://www.php.net/manual/en/book.sqlite3.php" rel="nofollow ugc">SQLite3</a> extension, and optionally the <a href="https://www.php.net/manual/en/intro.igbinary.php" rel="nofollow ugc">igbinary</a> and <a href="https://www.php.net/manual/en/book.apcu.php" rel="nofollow ugc">APCu</a> extensions to php. Many hosting services offer those extensions, and they are easy to install on a server you control.
<h4>What is this about?</h4>
It’s about making your site’s web server perform better. An object cache does that by reducing the workload on your MariaDB or MySQL database. This is not a <a href="https://developer.wordpress.org/advanced-administration/performance/cache/" rel="nofollow ugc">page cache</a>; these persistent objects go into a different kind of cache. These objects aren’t chunks of web pages ready for people to view in their browsers, they are data objects for use by the WordPress software.
<a href="https://en.wikipedia.org/wiki/Cache_(computing)" rel="nofollow ugc">Caches</a> are ubiquitous in computing, and WordPress has its own caching subsystem. Caches contain short-term copies of the results of expensive database lookups or computations, and allow software to use the copy rather than repeating the expensive operation. This plugin (like other object-caching plugins) extends WordPress’s caching subsystem to save those short-term copies from page view to page view. WordPress’s cache happens to be a <a href="https://en.wikipedia.org/wiki/Cache_(computing)#Memoization" rel="nofollow ugc">memoization</a> cache.
Without a persistent object cache, every WordPress page view must use your MariaDB or MySQL database server to retrieve everything about your site. When a user requests a page, WordPress starts from scratch and loads everything it needs from your database server. Only then can it deliver content to your user. With a persistent object cache, WordPress immediately loads much of the information it needs. This lightens the load on your database server and delivers content to your users faster.
<h4>Who should use this?</h4>
If your site runs on a single web server machine, and that server provides the <a href="https://www.php.net/manual/en/book.sqlite3.php" rel="nofollow ugc">SQLite3</a> and <a href="https://www.php.net/manual/en/intro.igbinary.php" rel="nofollow ugc">igbinary</a> extensions to php, this plugin will almost certainly make your site work faster. And if that server provides the <a href="https://www.php.net/manual/en/book.apcu.php" rel="nofollow ugc">APCu</a> extension, this plugin uses it too.
Some hosting providers offer <a href="https://redis.io/" rel="nofollow ugc">redis</a> cache servers. If your provider offers redis, it may be a good choice. You can use it via the <a href="https://wordpress.org/plugins/redis-cache/" rel="ugc">Redis Object Cache</a> plugin. Sites using redis have one SQL database and another non-SQL storage server: redis. Other hosting providers offer <a href="https://memcached.org/" rel="nofollow ugc">memcached</a>, which has the <a href="https://wordpress.org/plugins/memcached/" rel="ugc">Memcached Object Cache</a> plugin. And some large multipurpose cache plugins, such as the <a href="https://wordpress.org/plugins/litespeed-cache/" rel="ugc">LiteSpeed Cache</a>, also offer object caching based on one of those cache server software packages.
The cache-server approach to object caching comes into its own when you have multiple load-balanced web server machines handling your site. SQLite doesn’t work correctly in a multiple-web-server environment.
But, for single-server site configurations, SQLite, possibly assisted by APCu, performs well. And the vast majority of sites are single-server.
<h4>APCu</h4>
<a href="https://www.php.net/manual/en/book.apcu.php" rel="nofollow ugc">APCu</a> is an in-memory storage medium. It lets php programs, like WordPress, store data in shared memory so it’s very fast to retrieve when needed. If APCu is available on your host server, you can configure this plugin to use it. It reduces the typical cache lookup time to one-fifth or less of the SQLite lookup time, which is itself a few tens of microseconds. Performance counts, especially on busy web sites.
Please look at <a href="https://wordpress.org/plugins/sqlite-object-cache/#installation" rel="ugc">Installation</a> to learn how to configure this plugin to use APCu. The plugin works fast without it, and faster with it.
WP-CLI: Even if APCu is in use, caching with SQLite is necessary when your web site uses WP-CLI, because WP-CLI programs do not have access to the APCu cache. This plugin writes all cached data both to APCu and to SQLite and makes sure the two are synchronized.
<h4>WP-CLI</h4>
You can control this plugin via WP-CLI once you activate it. Please type this command into your shell for details.
<pre><code>wp help sqlite-object-cache
</code></pre>
<h4>Credits</h4>
Thanks to <a href="https://profiles.wordpress.org/tillkruess/" rel="nofollow ugc">Till Krüss</a>. His <a href="https://wordpress.org/plugins/redis-cache/" rel="ugc">Redis Object Cache</a> plugin serves as a model for this one. And thanks to <a href="https://profiles.wordpress.org/aristath/" rel="nofollow ugc">Ari Stathopoulos</a> and <a href="https://profiles.wordpress.org/spacedmonkey/" rel="nofollow ugc">Jonny Harris</a> for reviewing this. Props to Matt Jones for finding and fixing a bug that appeared on a heavily loaded system. Thanks to <a href="https://speedable.net/about-us/" rel="nofollow ugc">Massimo Villa</a> for testing help, and to <a href="https://github.com/nickchomey" rel="nofollow ugc">nickchomey</a> for a comprehensive code review. All defects are, of course, entirely the author’s responsibility.
And thanks to Jetbrains for the use of their software development tools, especially <a href="https://www.jetbrains.com/phpstorm/" rel="nofollow ugc">PhpStorm</a>. It’s hard to imagine how a plugin like this one could be developed without PhpStorm’s tools for exploring epic code bases like WordPress’s.
<h4>How can I learn more about making my WordPress site more efficient?</h4>
We offer several plugins to help with your site’s database efficiency. You can <a href="https://www.plumislandmedia.net/wordpress/performance/optimizing-wordpress-database-servers/" rel="nofollow ugc">read about them here</a>.

SQLite Object Cache


This is the plugin, the community of shared-hosting users have waited for without even knowing it.



Thanks to @ollijones the plugin author for making this possible and also for tagging it a community-plugin and doing friendly support here on the forum as well.



Great!


Great Plugin & friendly and fast support


Thanks Ollie for this great plugin!



I use this in conjunction with your other plugin Index WP MySQL For Speed and have installed these on quite a lot of websites with great success. Each and every one has increased speed.



It is faster and it feels faster and that's all the client cares about 🎉


5 star plugin. Speed increasement does not go unnoticed.


Honestly I was skeptical at first because of the low number of installs, but given the lack of options for object caching on a lot of shared hosting services that I cant control with a lot of client sites I decided to give it a shot on a few.  



This plugin is amazing, it helped turn a 15 second load on back end page edits into 3-4 seconds on a plugin heavy site running on an overpopulated shared host that I wont name here, but it was honestly awful, one of the worst I've ever used and a surprisingly big name.  I was brought in to try and optimize a monster on this occasion and it helped me turn it into some form of a workhorse again for my client, with almost no setup, toggled a checkbox or two and clicked save.   



This plugin needs more downloads, there are so many sites running on garbage hosting that could use this to make the back end a working environment again.



I will be using this on any site where I do not have redis or memcache available from here on out, cheers to the developer, you are an true WP Wizard.


Absolutely Brilliant


When no Memcached, no Redis available, this is the obvious solution.


Just what I was looking for

Amazing

great project!

A fast persistent object cache backend for the rest of us, powered by SQLite and accelerated by APCu

Kevin Burkholder

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 <a href="https://developer.wordpress.org/reference/classes/wp_object_cache/" rel="nofollow ugc">The WordPress Object Cache</a>
<blockquote>
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.
</blockquote>
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.
<a href="https://www.php.net/manual/en/book.apcu.php" rel="nofollow ugc">APCu</a> is a shared, in-memory, persistent cache available only when the <a href="https://www.php.net/manual/en/apcu.setup.php" rel="nofollow ugc">APCu PECL Extension</a> 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.
<h4>Features</h4>
<ul>
<li>Lightweight, efficient, and fast!</li>
<li>L1 (in-process memory) and L2 (APCu & SQLite) caching.</li>
<li>Supports Write-Back (delayed transactions) or Write-Through SQL caching.</li>
<li>Caching by object group name.
<ul>
<li>Preserves uniqueness of keys.</li>
<li>Manage keys by group name.</li>
<li>Supports group name attributes (:sitewide, :nocaching, :permanent, :prefetch)</li>
</ul>
</li>
<li>Pre-fetch object groups from L2 to L1 cache.</li>
<li>Caches and pre-fetches L2 misses (known to not exist in L2 cache).
<ul>
<li>Prevents repeated, unnecessary L2 cache reads across requests.</li>
</ul>
</li>
<li>Multisite / Network support:
<ul>
<li>Cache/flush/switch by blog id.</li>
</ul>
</li>
<li>Caching statistics:
<ul>
<li>Cache hits (typically above 90%).</li>
<li>Overall and L1/L2 hits, misses, & ratio.</li>
<li>Cache hits by object groups.</li>
<li>Number of APCu and SQLite keys stored.</li>
<li>SQLite select/update/delete/commit counts.</li>
</ul>
</li>
<li>Supports an enhanced superset of WP Object Cache functions.</li>
<li>Easily enabled or disabled from {eac}Doojigger administrator page.
<ul>
<li>Imports existing MySQL transients.</li>
<li>Exports cached transients to MySQL when disabled.</li>
</ul>
</li>
<li>Automatically cleans and optimizes SQLite database.</li>
<li>Optionally schedule periodic cache invalidation and rebuild.</li>
<li>Uses the PHP Data Objects (PDO) extension included with PHP.</li>
</ul>
While {eac}ObjectCache does support multiple WordPress 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.
<h4>Configuration Alternatives</h4>
Assuming you have SQLite and APCu installed, what are your best options?
<ol>
<li>
Fastest Caching – Uses in-process memory and APCu shared memory.
<ul>
<li>Disable SQLite. *
<ul>
<li><code>define( 'EAC_OBJECT_CACHE_USE_DB', false );</code></li>
</ul>
</li>
<li>Advantage
<ul>
<li>Fast memory-only access.</li>
<li>Handles concurrent updates through APCu cache.</li>
</ul>
</li>
<li>Disadvantage
<ul>
<li>APCu may invalidate data under memory constraint.</li>
<li>APCu cache is not shared with CLI.</li>
<li>APCu cache is lost on system or PHP restart.</li>
</ul>
</li>
</ul>
</li>
<li>
Less memory (almost as fast) – Uses in-process memory and APCu shared memory.
<ul>
<li>Disable SQLite. *
<ul>
<li><code>define( 'EAC_OBJECT_CACHE_USE_DB', false );</code></li>
</ul>
</li>
<li>Optimize memory use. *
<ul>
<li><code>define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );</code></li>
</ul>
</li>
<li>Advantage
<ul>
<li>Fast memory-only access.</li>
<li>Handles concurrent updates through APCu cache.</li>
<li>Conserves per-request memory by not pushing APCu hits to in-process memory.</li>
</ul>
</li>
<li>Disadvantage
<ul>
<li>Slightly slower to access APCu memory over in-process memory.</li>
<li>APCu may invalidate data under memory constraint.</li>
<li>APCu cache is not shared with CLI.</li>
<li>APCu cache is lost on system or PHP restart.</li>
</ul>
</li>
</ul>
</li>
<li>
Most resilient (and still fast) – Uses in-process memory, APCu shared memory, and SQLite database.
<ul>
<li>Do nothing, this is the default.</li>
<li>Advantage
<ul>
<li>Most cache hits will come from in-process and APCu memory.</li>
<li>SQLite retains cache data after restart.</li>
</ul>
</li>
<li>Disadvantage
<ul>
<li>Must keep SQLite database (on disk) updated.</li>
<li>Potential concurrency issues on high-volume site.</li>
</ul>
</li>
</ul>
</li>
<li>
Resilient, efficient, and fast (recommended) – Uses in-process memory, APCu shared memory, and SQLite database.
<ul>
<li>Optimize memory use. *
<ul>
<li><code>define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );</code></li>
</ul>
</li>
<li>Advantage
<ul>
<li>Most cache hits will come from in-process and APCu memory.</li>
<li>Handles concurrent updates better through APCu cache.</li>
<li>Conserves per-request memory by not pushing APCu hits to in-process memory.</li>
<li>SQLite retains cache data after restart.</li>
</ul>
</li>
<li>Disadvantage
<ul>
<li>Slightly slower to access APCu memory over in-process memory.</li>
<li>Must keep SQLite database (on disk) updated.</li>
</ul>
</li>
</ul>
</li>
<li>
Least efficient (default when APCu is not installed) – Uses in-process memory and SQLite database.
<ul>
<li>Disable APCu. *
<ul>
<li><code>define( 'EAC_OBJECT_CACHE_USE_APCU', false );</code></li>
</ul>
</li>
<li>Advantage
<ul>
<li>Saves resources by not taking up APCu reserves.</li>
<li>More secure by not using shared memory.</li>
<li>SQLite retains cache data after restart.</li>
</ul>
</li>
<li>Disadvantage
<ul>
<li>All cached data initially read from disk.</li>
<li>Must keep SQLite database (on disk) updated.</li>
<li>Potential concurrency issues on high-volume site.</li>
</ul>
</li>
</ul>
</li>
<li>
For high-volume sites – reduces or eliminates potential race conditions
<ul>
<li>Optimize memory use. *
<ul>
<li><code>define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );</code></li>
</ul>
</li>
<li>Disable delayed writes. *
<ul>
<li><code>define( 'EAC_OBJECT_CACHE_DELAYED_WRITES', false );</code></li>
</ul>
</li>
<li>Disable use of <code>alloptions</code> array.
<ul>
<li><code>define( 'EAC_OBJECT_CACHE_DISABLE_ALLOPTIONS', true );</code></li>
</ul>
</li>
<li>Advantage
<ul>
<li>Most cache hits will come from in-process and APCu memory.</li>
<li>Conserves per-request memory by not pushing APCu hits to in-process memory.</li>
<li>Updates SQLite data immediately.</li>
<li>Conserves per-request memory by elimination large <code>alloptions</code> array(s).</li>
</ul>
</li>
<li>Disadvantage
<ul>
<li>Slightly slower to access APCu memory over in-process memory.</li>
<li>Multiple single-row SQLite update transactions.</li>
<li>Slightly slower to access individual options from cache rather than <code>alloptions</code> array.</li>
</ul>
</li>
</ul>
</li>
</ol>
* These options may be set from the {eac}Doojigger administration screen.
When using SQLite, <code>delayed writes</code> (see below) dramatically improves efficiency by only writing updates at the end of the script process.
When using APCu shared memory, data is accessable by other PHP processes that may run on the server.
<h4>Inside The Numbers</h4>

 Label         
 Value
 cache hits 
 The total number of requests that returned a cached value.
 cache misses 
 The total number of requests that did not return a cached value. This number includes L1 cache (-), L2 non-persistent, L2 APCu (-), and L2 SQL misses.
 L1 cache hits 
 The number of requests that were found in the L1 memory cache.
 L1 cache (+) 
 Request found in the L1 memory cache with data (positive hits).
 L1 cache (-) 
 Request found in the L1 memory cache with no data (negative hits).
 L1 cache misses 
 The number of requests not found in the L1 memory cache.
 L2 non-persistent 
 L1 cache misses in a non-persistent group (not in L2 cache).
 L2 APCu hits 
 The number of L1 cache misses (minus L2 non-persistent) that were found in the L2 APCu cache.
 L2 APCu (+) 
 Request found in the L2 APCu cache with data (positive hits).
 L2 APCu (-) 
 Request found in the L2 APCu cache with no data (negative hits).
 L2 APCu misses 
 The number of requests not found in the L2 APCu cache.
 L2 SQL hits 
 The number of L2 APCu misses (or L1 cache misses) that were found in the L2 SQLite cache.
 L2 SQL misses 
 The number of requests not found in the L2 SQLite cache.
 L2 APCu updates 
 The number of APCu keys updated.
 L2 APCu deletes 
 The number of APCu keys deleted.
 L2 SQL selects 
 The number of SQLite select statements executed.
 L2 SQL updates 
 The number of SQLite records updated.
 L2 SQL deletes 
 The number of SQLite records deleted.
 L2 SQL commits 
 The number of SQLite transactions executed to update and delete records.
<ul>
<li>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 making the cache hit ratio (93.10%) understated.</li>
</ul>
Object cache statistics may be found:
<ul>
<li>In the WP Object Cache dashboard panel.
<ul>
<li>Uses <code>$wp_object_cache->showDashboardStats()</code></li>
</ul>
</li>
<li>In the Debug Bar > Object Cache panel.
<ul>
<li>Uses <code>$wp_object_cache->stats()</code></li>
</ul>
</li>
<li>In the Query Monitor > Logs > Info panel.
<ul>
<li>Uses <code>$wp_object_cache->getCurrentStats()</code></li>
</ul>
</li>
<li>In a wp_admin_notice block when display_stats is set for sampling.
<ul>
<li>Uses <code>$wp_object_cache->htmlStats()</code></li>
</ul>
</li>
</ul>
<h3>Settings</h3>
Several cache settings can be modified by adding defined constants to the <code>wp-config.php</code> file. The default settings are recommended and optimal in most cases but individual settings may need to be adjusted based on traffic volume, specific requirements, or unique circumstances. Most of these settings can be adjusted in the {eac}Doojigger administrator screen.
<ul>
<li>
To disable use of the SQLite Database (default: true):
<code>define( 'EAC_OBJECT_CACHE_USE_DB', false );</code>
</li>
</ul>
{eac}ObjectCache will still operate as an in-memory cache without the persistent database. If using APCu memory caching, persistence is maintained as long as the cache is not flushed, manually or by restarting PHP.
<ul>
<li>
To disable use of the APCu memory cache (default: true if APCu is enabled):
<code>define( 'EAC_OBJECT_CACHE_USE_APCU', false );</code>
</li>
</ul>
APCu memory caching is used, by default, only if the <a href="https://www.php.net/manual/en/apcu.installation.php" rel="nofollow ugc">APCu PECL extension</a> is installed.
<ul>
<li>
To optimize memory use when using APCu (default: false):
<code>define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );</code>
</li>
</ul>
When using APCu memory caching, optimize internal memory by not storing APCu data in the L1 memory cache. This may slightly (negligibly) increase processing time as cache hits will come through APCu but will reduce the per-process memory usage. This may also be advantageous on high-volume sites where a single object may be updated by simultaneous processes.
<ul>
<li>
To disable use of the <code>alloptions</code> array in WordPress (default: false):
<code>define( 'EAC_OBJECT_CACHE_DISABLE_ALLOPTIONS', true );</code>
</li>
</ul>
By default, WordPress pre-fetches many of the option values from the wp-options table on startup. This facilitates faster access to oft-used options. However, this also creates 1) a potential race condition on high-volume sites, and 2) a sometimes very large array of data in memory that may also be duplicated in the L1 and L2 caches. Disabling this forces WordPress to get individual options from the cache rather than from the array, eliminates the race condition, eliminates the large array(s), and reduces much of the logic used to maintain the array(s). This may be particularly advantageous when using APCu since the option values should already be in shared memory.
* Once enabled, the caches should be cleared to eliminate previously cached <code>alloptions</code> arrays. 
* Uses filters <code>pre_wp_load_alloptions</code> (introduced in WP 6.2.0) and <code>wp_autoload_values_to_autoload</code> (introduced in WP 6.6.0).
<ul>
<li>
To set the location of the SQLite database (default: ../wp-content/cache):
<code>define( 'EAC_OBJECT_CACHE_DIR', '/full/path/to/folder' );</code>
</li>
</ul>
This folder can be outside of the web-accessable folders of your site – i.e. above the document root (htdocs, www, etc.) – provided that PHP can access (read/write) the folder (see the PHP open_basedir directive).
This folder should not be on a network share or other remote media. We’re caching data for quick access, the cache folder should be on fast, local media.
<ul>
<li>
To set the name of the SQLite database (default: ‘.eac_object_cache.sqlite’):
<code>define( 'EAC_OBJECT_CACHE_FILE', 'filename.sqlite' );</code>
</li>
</ul>
In addition to the database file, SQLite may also create temporary files using the same file name with a ‘-shm’ and ‘-wal’ suffix.
<ul>
<li>
To set SQLite journal mode (default: ‘WAL’):
<code>define( 'EAC_OBJECT_CACHE_JOURNAL_MODE', journal_mode )</code>
</li>
</ul>
journal_mode can be one of ‘DELETE’, ‘TRUNCATE’, ‘PERSIST’, ‘MEMORY’, ‘WAL’, or ‘OFF’. 
See <a href="https://www.sqlite.org/pragma.html#pragma_journal_mode" rel="nofollow ugc">SQLite journal mode</a>
<ul>
<li>
To set SQLite Mapped Memory I/O (default: 0):
<code>define( 'EAC_OBJECT_CACHE_MMAP_SIZE', int );</code>
</li>
</ul>
Sets the maximum number of bytes that are set aside for memory-mapped I/O. 
See <a href="https://www.sqlite.org/pragma.html#pragma_mmap_size" rel="nofollow ugc">SQLite memory-mapped I/O</a>
<ul>
<li>
To set SQLite Page Size (default: 4096):
<code>define( 'EAC_OBJECT_CACHE_PAGE_SIZE', int );</code>
</li>
</ul>
Sets the SQLite page size for the database. 
See <a href="https://www.sqlite.org/pragma.html#pragma_page_size" rel="nofollow ugc">SQLite page size</a>
<ul>
<li>
To set SQLite Cache Size (default: -2000 [2,048,000]):
<code>define( 'EAC_OBJECT_CACHE_CACHE_SIZE', int );</code>
</li>
</ul>
Sets the maximum number of database disk pages that SQLite will hold in memory or the maximum amount of memory to use for page caching. 
See <a href="https://www.sqlite.org/pragma.html#pragma_cache_size" rel="nofollow ugc">SQLite cache size</a>
<ul>
<li>
To set SQLite timeout (default: 3):
<code>define( 'EAC_OBJECT_CACHE_TIMEOUT', int );</code>
</li>
</ul>
Sets the number of seconds before a SQLite transaction may timeout in error.
<ul>
<li>
To set SQLite retries (default: 3):
<code>define( 'EAC_OBJECT_CACHE_MAX_RETRIES', int );</code>
</li>
</ul>
Sets the maximum number of retries to attempt on critical actions.
<ul>
<li>
To set delayed writes (default: 32):
<code>define( 'EAC_OBJECT_CACHE_DELAYED_WRITES', true|false|int );</code>
</li>
</ul>
{eac}ObjectCache caches all objects in memory and writes new, updated, or deleted objects to the L2 (SQLite) cache. delayed writes simply holds objects in memory until the number of objects reaches a specified threshold, then writes them, in a single transaction, to the L2 cache (a.k.a. write-back caching). Setting delayed writes to false turns this functionality off (a.k.a. write-through caching). Setting to true writes all records only at the end of the script process/page request. Setting this to a number sets the object pending threshold to that number of objects.
<ul>
<li>
To set the default expiration time (in seconds) (default: 0 [never]):
<code>define( 'EAC_OBJECT_CACHE_DEFAULT_EXPIRE', -1|0|int );</code>
</li>
</ul>
When using the default WordPress object cache, object expiration isn’t very important because the entire cache expires at the end of the script process/page request. With a persistent cache, this isn’t the case. When an object is cached, the developer has the option of specifying an expiration time for that object. Since we don’t know …

{eac}ObjectCache – a persistent object cache using SQLite & APCu to cache WordPress objects.

{eac}ObjectCache is a persistent object cache using APCu & SQLite to cache WordPress objects; A drop-in replacement to the WP Object Cache used by …

SQLite Object Cache vs {eac}ObjectCache – a persistent object cache using SQLite & APCu to cache WordPress objects.