A persistent object cache can avoid repeated database work, but every cache operation also has a cost. A remote Redis service with network latency, oversized cached values or frequent evictions can make simple pages slower while complex pages improve.
Compare the same request paths with controlled measurements rather than assuming object cache is always beneficial.
Clarify what object cache does
Object cache stores WordPress objects, query results and plugin-generated values between requests. It is not the same as full-page cache: PHP still runs and assembles the page.
A cached homepage may show no difference because full-page HTML bypasses PHP entirely. Logged-in pages, API requests, search and checkout can reveal object-cache behaviour more clearly.
Confirm the active drop-in at wp-content/object-cache.php and the service it connects to. Do not edit or remove the drop-in without a rollback and knowledge of the owning plugin.
Build representative comparisons
Choose public cache misses, logged-in dashboard tasks, WooCommerce catalogue queries and any route reported slow. Record several samples with object cache healthy.
In staging or a maintenance window, disable it through the provider’s supported method and repeat under similar data and load. Compare total response time, database query time and external cache time.
One fast request after disabling is not proof. Cold database caches and warmed object values make sequence important.
Measure connection latency and errors
If Redis or Memcached is on another host, small network delays multiply across many operations. Review plugin diagnostics and server logs for timeouts, reconnects or authentication failures.
From an authorised server, provider tools can measure round-trip latency and service health. Do not expose the cache port publicly or weaken authentication to run a test.
Configure conservative timeouts so a cache outage does not hold every PHP request for seconds before falling back.
Look for huge values and abusive groups
A plugin can cache a large array and retrieve or serialise it on every request. Inspect cache metrics by key size or group where supported, taking care not to log sensitive values.
Common warning signs include very large options, complete API responses, unbounded query combinations and a unique cache key per visitor.
Repair the owning plugin or key strategy. Increasing cache memory may postpone eviction but does not correct an unbounded design.
Check eviction and memory pressure
When the cache reaches its memory limit, eviction policy determines which keys disappear. A low hit rate with constant eviction can add cache overhead while still sending work back to MySQL.
Review used memory, evicted keys, hit/miss ratios and uptime over a meaningful period. A service restart resets counters, so note the observation window.
Do not run broad key-list commands on a busy production cache. Use non-blocking statistics and provider tooling.
Separate persistent from non-persistent data
Some values are unsuitable for sharing across requests or sites. In WordPress multisite, prefixes and database numbers must prevent collisions. Authentication, nonce or session-related data requires correct expiry.
If only one plugin or group misbehaves, configure a supported non-persistent group or repair its caching logic rather than disabling object cache for the whole installation.
Flushes should be scoped. An entire Redis database may serve more than one application.
Verify failure behaviour
Temporarily simulate service unavailability only in staging. WordPress should fail gracefully to database-backed operation rather than produce a fatal error or multi-second timeout.
After any configuration change, test public misses, admin editing, forms, scheduled tasks and checkout. Monitor MySQL load as well as PHP response time; moving latency from Redis to the database is not an improvement.
Request an assessment when metrics show reconnects, evictions or large values, or when only particular routes regress. Provide sanitised timing and cache statistics; do not share keys, passwords or customer data in the initial enquiry.