Yac Object Cache

Yac uses the Yac PHP extension as the backing store for the WordPress object cache.

Unlike Memcached or Redis, Yac stores data in shared memory inherited by every PHP-FPM worker on the machine. There is no cache server to install, no socket to configure, and every cache read is a hash lookup in local memory — typically microseconds, with no network round trip and no global lock.

Highlights

• Fast. A cache read is a shared-memory hash lookup — the status page measures a 0.005 ms round trip. On a production site (laruence.com, PHP 8.1-FPM, 8 cores), full homepage renders ran ~20% faster than the classic Memcached drop-in: 141.6 vs 118.7 req/s at 20 concurrent users, +18-20% across 20-100 concurrency, zero failed requests.
• No external server. The cache lives in shared memory (mmap/SysV), fork-inherited by FPM workers.
• Lock-free. Per-slot CAS arbitration; throughput scales with worker count. No global lock.
• Self-deploying. Activating the plugin writes object-cache.php to wp-content/.
• Simple keys, simple flush. Keys are stored verbatim while they fit Yac’s 48-byte limit; wp_cache_flush() calls Yac::flush() and wipes the entire shared memory on the machine — know that before you flush.
• Graceful degradation. If Yac is unavailable (extension missing), the drop-in falls back to a per-request in-memory cache and WordPress keeps working.
• Single-node focus. Keys carry no per-blog prefix; installs sharing one PHP pool isolate via YAC_OCACHE_KEY_PREFIX. Multisite blogs share one namespace.
• Entry inspector. On the admin page, click any top-entry key to see the deserialized value, padded size, expiry and — on newer yac builds — last access, hit count and whether the value is embedded in its slot; or delete the entry.

Best fit

Yac is a local cache. It is ideal for single-node or few-node WordPress installs where all PHP workers run on one machine. On large multi-server clusters with strict cross-node consistency needs, a network cache (Memcached/Redis) may suit better.