A common complaint goes like this: "The public site is fast, but the moment I log in, everything crawls." Editors wait several seconds for the dashboard, saving a page feels like a gamble, and the site slows down for everyone during busy publishing hours. The public site is fast because anonymous pages come from a page cache. Logged-in pages cannot, so every one of them is built from scratch, often with hundreds of database queries. An object cache is how you make that work cheap.
What an object cache does
WordPress and Drupal repeatedly ask the database the same questions while building a page: site settings, menus, user permissions, taxonomy terms, the results of expensive queries. An object cache stores those answers in memory. The next time the same question comes up, on the same request or a later one, the answer comes back in well under a millisecond instead of a trip to the database.
Redis is an in-memory data store that both platforms support well as an object cache. It is shared by every web server, so when a site runs on several servers behind a load balancer, they all benefit from each other's cached results.
How to tell whether you need one
- Logged-in pages take noticeably longer than public pages, even on a quiet day.
- The database server's CPU climbs when editors are active.
- A debugging tool shows hundreds of queries on a single admin page. In WordPress, the Query Monitor plugin shows this in the admin bar. In Drupal, the Webprofiler module that comes with Devel shows the same.
- WooCommerce, membership, intranet, or other sites with many logged-in users feel slow in general.
How it connects to each platform
WordPress uses a drop-in file, wp-content/object-cache.php, usually installed by a Redis object cache plugin. Once it is active, WordPress core, themes, and plugins that use the standard cache functions all store results in Redis automatically. Transients, which plugins use for temporary data, move there too. With the widely used Redis Object Cache plugin, wp redis status from WP-CLI confirms the connection.
Drupal uses the Redis module with a few lines in settings.php to make Redis the default cache backend. Drupal's cache bins (render, data, discovery, and others) then live in memory instead of database tables, which also stops those tables from growing large.
Signs it is working, and signs it is not
| Metric | Healthy | Worth a look |
|---|---|---|
| Hit ratio | High and stable | Low, or falling over time |
| Evictions | Rare | Constant: the cache is too small for the workload |
| Memory used | Comfortably under the limit | Pinned at the limit |
| Admin page time | Clearly faster than before | No change: the drop-in or module may not be active |
Configuration mistakes to avoid
- Several sites sharing one Redis without separate prefixes. Two sites can read each other's cached data, which produces baffling bugs such as the wrong menu or settings appearing. Every site needs its own key prefix or database.
- No eviction policy. When memory fills, Redis should drop the least recently used keys. Without that policy, writes start failing.
- Treating the cache as storage. Anything in an object cache can disappear at any moment. Code must always be able to rebuild it from the database.
- Not flushing after a deployment that changes data structures, which can leave stale cached objects that no longer match the code.
Is Redis enough on its own?
No. It is one layer of three. A CDN and page cache serve anonymous visitors. The object cache speeds up everything that cannot be served from the page cache, especially logged-in users. The database still has to be well indexed underneath. On a busy site, adding the object cache is often the single biggest improvement for editors, but it does not replace the other two.
A quick before-and-after test is the best proof: time a few admin pages, enable the object cache, and time them again. The difference on a busy site is usually obvious without any tools.
How eWay operates it
eWay provisions and manages Redis as part of the hosting environment, using Amazon ElastiCache for Redis on AWS or Azure Cache for Redis on Azure. eWay sizes it for your workload, sets key prefixes and eviction policy correctly, installs and configures the platform integration, and monitors hit ratio, memory, and evictions. Failover, patching, and version upgrades are handled for you. You never run or patch the cache yourself.
What to include in a support ticket
- The severity you would assign, P1 to P4 (see severity levels and response times)
- Which pages feel slow, and whether you are logged in when it happens
- Rough timings, such as "the dashboard takes eight seconds"
- Any recent plugin or module changes
eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: page caching and CDN behavior and database performance and read replicas. Learn more on our WordPress and Drupal pages.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article