[WordPress] 外掛分享： {eac}ObjectCache – a persistent object cache using SQLite & APCu to cache WordPress objects.

內容目錄

1 前言介紹
2 外掛協作開發者
3 外掛標籤
4 內容簡介
5 原文外掛簡介
6 各版本下載點
7 延伸相關外掛（你可能也想知道）

前言介紹

這款 WordPress 外掛「{eac}ObjectCache – a persistent object cache using SQLite & APCu to cache WordPress objects.」是 2024-04-02 上架。
目前有 10 個安裝啟用數。
上一次更新是 2025-10-25，距離現在已有 123 天。
外掛最低要求 WordPress 5.8 以上版本才可以安裝。
外掛要求網站主機運作至少需要 PHP 版本 8.1 以上。
有 2 人給過評分。
還沒有人在論壇上發問，可能目前使用數不多，還沒有什麼大問題。

外掛協作開發者

kevinburkholder |

外掛標籤

內容簡介

<article>
<h2>對象快取外掛介紹</h2>
<p>{eac}Doojigger Object Cache ({eac}ObjectCache) 是一個輕量且非常高效的持久性對象快取，使用快速的 SQLite 資料庫來對 WordPress 的對象進行快取。</p>
</article>

<h3>問題與答案：</h3>
<ul>
<li>
<h4>什麼是 WordPress 對象快取？</h4>
<p>WordPress 對象快取用於節省對資料庫的訪問次數。預設情況下，對象快取是非持久性的，這表示快取中的資料僅在記憶體中存儲，並僅在請求期間保持。</p>
</li>
<li>
<h4>{eac}ObjectCache 有哪些特點？</h4>
<p>{eac}ObjectCache 取代了 WordPress 的預設對象快取，不僅將資料存儲在記憶體中，還將資料持久化存儲在 SQLite 資料庫中，增加了快取命中率，減少了昂貴的計算、複雜的 MySQL 資料庫查詢和遠程 API 請求的需求。同時，它支援 L1 (內存) 和 L2 (SQLite) 快取，以及延遲交易或通過快取進行寫回。</p>
</li>
<li>
<h4>如何調整 SQLite 資料庫的位置？</h4>
<p>您可以透過在 wp-config.php 檔案中添加定義的常數來調整 SQLite 資料庫的位置。默認情況下，建議使用默認設置，但基於流量量、具體需求或特定情況，可能需要調整單獨的設置。</p>
</li>
</ul>

原文外掛簡介

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/L2 hits, misses, & ratio.
Cache hits by object groups.
Number of APCu and SQLite keys stored.
SQLite 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 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.
Configuration Alternatives
Assuming you have SQLite and APCu installed, what are your best options?

Fastest Caching – Uses in-process memory and APCu shared memory.

Disable SQLite. *

define( 'EAC_OBJECT_CACHE_USE_DB', false );

Advantage

Fast memory-only access.
Handles concurrent updates through APCu cache.

Disadvantage

APCu may invalidate data under memory constraint.
APCu cache is not shared with CLI.
APCu cache is lost on system or PHP restart.

Less memory (almost as fast) – Uses in-process memory and APCu shared memory.

Disable SQLite. *

define( 'EAC_OBJECT_CACHE_USE_DB', false );

Optimize memory use. *

define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );

Advantage

Fast memory-only access.
Handles concurrent updates through APCu cache.
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 not shared with CLI.
APCu cache is lost on system or PHP restart.

Most resilient (and still fast) – Uses in-process memory, APCu shared memory, and SQLite database.

Do nothing, this is the default.
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.
Potential concurrency issues on high-volume site.

Resilient, efficient, and fast (recommended) – Uses in-process memory, APCu shared memory, and SQLite database.

Optimize memory use. *

define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );

Advantage

Most cache hits will come from in-process and APCu memory.
Handles concurrent updates better through APCu cache.
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.

Least efficient (default when APCu is not installed) – Uses in-process memory and SQLite database.

Disable APCu. *

define( 'EAC_OBJECT_CACHE_USE_APCU', false );

Advantage

Saves resources by not taking up APCu reserves.
More secure by not using shared memory.
SQLite retains cache data after restart.

Disadvantage

All cached data initially read from disk.
Must keep SQLite database (on disk) updated.
Potential concurrency issues on high-volume site.

For high-volume sites – reduces or eliminates potential race conditions

Optimize memory use. *

define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );

Disable delayed writes. *

define( 'EAC_OBJECT_CACHE_DELAYED_WRITES', false );

Disable use of alloptions array.

define( 'EAC_OBJECT_CACHE_DISABLE_ALLOPTIONS', true );

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.
Updates SQLite data immediately.
Conserves per-request memory by elimination large alloptions array(s).

Disadvantage

Slightly slower to access APCu memory over in-process memory.
Multiple single-row SQLite update transactions.
Slightly slower to access individual options from cache rather than alloptions array.

* 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.
When using APCu shared memory, data is accessable by other PHP processes that may run on the server.
Inside The Numbers

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.

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.

Object cache statistics may be found:

In the WP Object Cache dashboard panel.

Uses $wp_object_cache->showDashboardStats()

In the Debug Bar > Object Cache panel.

Uses $wp_object_cache->stats()

In the Query Monitor > Logs > Info panel.

Uses $wp_object_cache->getCurrentStats()

In a wp_admin_notice block when display_stats is set for sampling.

Uses $wp_object_cache->htmlStats()

Settings
Several cache settings can be modified by adding defined constants to the wp-config.php 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.

To disable use of the SQLite Database (default: true):
define( 'EAC_OBJECT_CACHE_USE_DB', false );

{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.

To disable use of the APCu memory cache (default: true if APCu is enabled):
define( 'EAC_OBJECT_CACHE_USE_APCU', false );

APCu memory caching is used, by default, only if the APCu PECL extension is installed.

To optimize memory use when using APCu (default: false):
define( 'EAC_OBJECT_CACHE_OPTIMIZE_MEMORY', true );

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.

To disable use of the alloptions array in WordPress (default: false):
define( 'EAC_OBJECT_CACHE_DISABLE_ALLOPTIONS', true );

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 alloptions arrays.
* Uses filters pre_wp_load_alloptions (introduced in WP 6.2.0) and wp_autoload_values_to_autoload (introduced in WP 6.6.0).

To set the location of the SQLite database (default: ../wp-content/cache):
define( 'EAC_OBJECT_CACHE_DIR', '/full/path/to/folder' );

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.

To set the name of the SQLite database (default: ‘.eac_object_cache.sqlite’):
define( 'EAC_OBJECT_CACHE_FILE', 'filename.sqlite' );

In addition to the database file, SQLite may also create temporary files using the same file name with a ‘-shm’ and ‘-wal’ suffix.

To set SQLite journal mode (default: ‘WAL’):
define( 'EAC_OBJECT_CACHE_JOURNAL_MODE', journal_mode )

journal_mode can be one of ‘DELETE’, ‘TRUNCATE’, ‘PERSIST’, ‘MEMORY’, ‘WAL’, or ‘OFF’.
See SQLite journal mode

To set SQLite Mapped Memory I/O (default: 0):
define( 'EAC_OBJECT_CACHE_MMAP_SIZE', int );

Sets the maximum number of bytes that are set aside for memory-mapped I/O.
See SQLite memory-mapped I/O

To set SQLite Page Size (default: 4096):
define( 'EAC_OBJECT_CACHE_PAGE_SIZE', int );

Sets the SQLite page size for the database.
See SQLite page size

To set SQLite Cache Size (default: -2000 [2,048,000]):
define( 'EAC_OBJECT_CACHE_CACHE_SIZE', int );

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 SQLite cache size

To set SQLite timeout (default: 3):
define( 'EAC_OBJECT_CACHE_TIMEOUT', int );

Sets the number of seconds before a SQLite transaction may timeout in error.

To set SQLite retries (default: 3):
define( 'EAC_OBJECT_CACHE_MAX_RETRIES', int );

Sets the maximum number of retries to attempt on critical actions.

To set delayed writes (default: 32):
define( 'EAC_OBJECT_CACHE_DELAYED_WRITES', true|false|int );

{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.

To set the default expiration time (in seconds) (default: 0 [never]):
define( 'EAC_OBJECT_CACHE_DEFAULT_EXPIRE', -1|0|int );

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 …

各版本下載點

方法一：點下方版本號的連結下載 ZIP 檔案後，登入網站後台左側選單「外掛」的「安裝外掛」，然後選擇上方的「上傳外掛」，把下載回去的 ZIP 外掛打包檔案上傳上去安裝與啟用。
方法二：透過「安裝外掛」的畫面右方搜尋功能，搜尋外掛名稱「{eac}ObjectCache – a persistent object cache using SQLite & APCu to cache WordPress objects.」來進行安裝。

（建議使用方法二，確保安裝的版本符合當前運作的 WordPress 環境。

1.3.0 | 1.3.1 | 1.3.2 | 1.3.3 | 1.3.4 | 1.4.0 | 1.4.1 | 2.0.0 | 2.1.0 | 2.1.1 | 2.1.2 | trunk |

延伸相關外掛（你可能也想知道）

Redis Object Cache 》一個由 Redis 提供支援的持久化物件快取後端。支援 Predis、PhpRedis (PECL)、Relay、複寫、哨兵、叢集化和 WP-CLI。, 若要調整連線參數、前綴的快取鍵或設定...。
Docket Cache – Object Cache Accelerator 》Docket Cache 是一個持久性的 WordPress 物件快取，以純 PHP 代碼的形式儲存。旨在為那些無法使用 Redis 或 Memcached 伺服器的人提供替代選擇。, 此外採用將...。
WP Redis 》 , 對於關注高流量、用於登錄用戶的速度或動態頁面加載的站點，高速而持久的物件緩存一定是不可或缺的。您還需要裝置能規模化跨多個應用程序實例，因此使用本...。
APCu Manager 》在 WordPress 管理員儀表板中準確地管理 APCu 統計信息。, APCu 管理器是一個功能完整的 APCu 管理和分析報告工具。它使您能夠監視和優化 WordPress 網站或網...。
SQLite Object Cache 》持久化物件快取可以提升您的網站效能。這個外掛使用了廣泛應用的 SQLite3 擴充套件。許多託管服務都提供了它。如果您的託管服務沒有提供 memcached 或 redis...。
Object Cache 4 everyone 》使用Memcached來進行對象快取以提高服務器性能，或使用磁盤支持進行對象快取，以達到更好的頁面速度和更少的資源和數據庫查詢次數。, 此外，插件可以自動檢測...。
atec Cache APCu 》總結：這個外掛提供了簡單卻有效的APCu物件快取和頁面快取功能。, , 問題與答案：, <ul>, <li>這個 WordPress 外掛提供了什麼功能？</li>,...。
atec Cache Info 》簡介：此外掛提供 PHP 快取功能的基本統計數據，包括 OPcache、WP-object-cache、APCu、Memcached、Redis 和 SQLite-object-cache。, , 問題與答案：, , 問題...。
Simple Cache 》Simple Cache是在使用其他主要快取外掛進行網站開發時感到沮喪後建立的。它承諾如下：, , 非常簡單的一鍵安裝。只有開關，沒有繁雜的設置。, Simple Cache使...。
Cache Warmer 》如果您已設置任何緩存解決方案，請瀏覽您的 WordPress 網站以熱門（建立）緩存。, 設置, , 配置緩存熱身頁面和深度；, 選擇將所有公共站點文章（任何類型）添...。
WP File Cache 》這個外掛實現了物件級持久性快取，可以作為 WordPress 內置的 WP_Object_Cache 的替代品使用。, 與 WP Super Cache、Hyper Cache 和其他外掛不同，WP File Ca...。
Object Cache for APCu – ZapCu 》總結：Object Cache for APCu通過使用APCu擴展，在WordPress中實現持久化物件緩存。它可以通過將物件緩存在內存中來減少數據庫查詢，從而加快頁面加載速度和...。
Tribe Object Cache 》輕鬆快速地添加可跨環境運作的物件快取支援。您只需啟用此外掛程式，然後立即建立您的安裝以支援以下任何一種（如果它們在伺服器上可用）：, , APC, Memcache...。
Memcached Redux 》這個外掛會更改著名的 Memcached WP Object Cache 後端，使其實際使用 Memcached 類別（而不是 Memcache 類別）。實現了 wp_cache_get_multi() 和 wp_cache_s...。
SnapCache 》總結：SnapCache 通過提供由 Memcached 支援的快速可靠的持久物件快取，加快 WordPress 的速度。它大幅減少了數據庫負載，加速頁面生成，在高流量下提升可擴...。

文章

文章