How it works

mycache is a native PHP extension written in C++ that replaces network-based object caching (Redis/Memcached) with a local, ultra-low-latency cache in RAM. It integrates with WordPress as a drop-in object-cache.php and is designed for WooCommerce-heavy workloads.

1) WordPress calls wp_cache_*

WordPress and WooCommerce read and write objects through the standard wp_cache_get(), wp_cache_set() APIs. mycache keeps full compatibility via a drop-in.

2) Drop-in routes to the extension

The drop-in stores values in-request (memory) and, when available, persists them using the native extension functions (mycache_get, mycache_set, etc.).

3) The extension uses RAM-backed storage

Persistent objects are stored as small files in a RAM-backed directory (typically /dev/shm), avoiding TCP, network jitter, and external services.

The core idea: “shared memory files”

mycache persists each cached entry as a compact binary file in a directory that lives in RAM (for Linux typically /dev/shm). This keeps reads and writes local and fast.

  • No Redis, no Memcached, no sockets, no TCP overhead
  • Low latency under load (ideal for WooCommerce)
  • Atomic writes (safe across processes)
  • Per-entry TTL and garbage collection
Where data lives
  • Default: /dev/shm/mycache (configurable)
  • Multi-tenant: separate directories per host / site
  • Fanout: subdirectories to keep filesystem operations fast
  • Security: controlled permissions (chmod_mode, SGID on dirs)

Fast key → file mapping

Keys are hashed (FNV-1a 64-bit) and mapped into a fixed number of subdirectories (fanout). This avoids performance issues caused by huge single directories.

  • Fanout: power-of-two, typically 256 (configurable)
  • Path: base/subdir/mc-<hash>.bin
  • Header: includes TTL (expire timestamp) and key length
  • Verification: key is stored in the file and checked on read

Atomic writes and safe concurrency

Writes are performed atomically using a temporary file and rename. Reads use shared locks, updates use exclusive locks. This keeps cache consistent even with high concurrency.

  • Write path: mkstemp → write → fdatasync → rename → fsync(dir)
  • Read lock: flock(LOCK_SH)
  • Update lock: flock(LOCK_EX) (e.g., incr/decr)
  • Crash safety: a partial temp file is never served

WordPress drop-in integration

mycache ships with a WordPress-compatible object-cache.php drop-in. It routes standard WordPress object cache calls to the extension while maintaining an in-request cache for maximum speed.

  • Drop-in: wp-content/object-cache.php
  • Supports multisite and global groups
  • Optional igbinary serialization (if available)
  • Optional compression for larger objects
Production-friendly behavior
  • Negative miss cache: short-lived caching of “not found” to reduce repeated IO
  • Fallback mode: if the extension is missing, it runs in non-persistent (in-memory) mode
  • Namespaces: fast flush via namespace bump (no full directory wipe required)
  • Per-blog prefix: isolates cache between sites in multisite setups

Configuration (INI)

mycache can be configured globally in php.ini or per-request via ini_set(). The drop-in uses this to safely bind each host to its own cache directory (multi-tenant isolation).

Setting Default Meaning
mycache.dir /dev/shm/mycache Base directory for RAM-backed cache files
mycache.fanout 256 Number of subdirectories (power-of-two, up to 4096)
mycache.chmod_mode 504 (octal 0770) Directory / file permissions (dirs get SGID for group inheritance)
mycache.max_bytes 0 Total size limit (0 = unlimited); best-effort eviction above the limit
Tip: on shared hosting, use a private RAM-backed cache directory inside your account if /dev/shm is restricted.

Key operations

  • mycache_set(key, value, ttl) — store a value with optional TTL
  • mycache_get(key) — read a value (returns null on miss)
  • mycache_exists(key) — fast existence check
  • mycache_delete(key) — delete a key
  • mycache_flush() — full flush (drop-in may prefer namespace bump)
  • mycache_gc(ttlGrace) — remove expired / invalid entries
  • mycache_incr/decr(key) — atomic numeric updates (file-locked)
  • mycache_stats() — JSON stats for observability

Why it’s fast in real WooCommerce traffic

WooCommerce generates a high volume of repeated object reads (options, product data, lookups, sessions). mycache reduces database pressure and removes network latency from the caching layer.

No TCP round-trips

Cache reads are local filesystem operations in RAM-backed storage. This eliminates socket overhead and tail latency.

Lower DB contention

Fewer repeated SQL queries for options, transients, lookups and computed objects. Especially impactful on busy product catalog pages and checkout flows.

Safe under concurrency

Atomic writes + file locks keep data consistent across multiple PHP-FPM workers, even with high parallel traffic.

Want to deploy mycache in production?

Check pricing, pick a plan, and install the drop-in. You’ll get updates and technical support with an active license.

View pricing Installation guide