WordPress Object Cache Hit Rate: Significance and Meaningful Target Values

What the WordPress Object Cache Stores

The WordPress Object Cache stores data under a key and within a group. If WordPress requests the same value again, it can retrieve it from the cache instead of performing the underlying work again. This includes, for example, data that would otherwise have to be read from the database or recalculated.

The built-in Core implementation is, by default, request-bound: It stores its entries for the duration of a single request. This means that a subsequent page view does not automatically have access to the previously stored values. Nevertheless, the cache can prevent repeated accesses even within a single request.

A drop-in can replace the core implementation with a Persistent Object Cache replace. This allows appropriate entries to be retained beyond individual requests. Redis is one possible backend option, but it is not a requirement for WordPress; other backend approaches are also possible. Even with a persistent drop-in, certain groups can still apply only to the current request.

Transients are another way to store data that is needed for a limited time. With a persistent object cache, they can be stored there instead of in the database. Their expiration time does not indicate a guaranteed minimum availability: a value may disappear sooner. Application code must therefore account for the possibility that a transient may be missing and be able to regenerate the value if necessary.

This distinction is crucial for evaluating the hit rate later on: Accessing the local cache during a request and accessing an external backend are not necessarily the same metric. Therefore, first check which implementation is actually being used and which data it stores persistently.

Distinguishing Between the Object Cache and the Page Cache

When a page is loaded, a Page Cache serve a page response that has already been generated. If the request is fulfilled there, it does not have to go through the same WordPress application path as an uncached request. The Object Cache, on the other hand, works within the application with individual cached data items, not with the entire page response.

Imagine a publicly accessible article page: If its response is stored in the page cache, it can be served immediately. If, on the other hand, WordPress has to generate the page, the object cache can help with repeated data accesses. The amount of work this actually saves depends on the request, the cached entries, and the specific implementation.

This has implications for interpretation: A good object cache rate only describes the cache hits that have been recorded. It does not directly indicate how many visitors are already receiving a pre-generated response from the page cache or how quickly the entire website responds. With extensive page caching, the benefits of the object cache become particularly evident in the remaining WordPress requests.

Browser and opcode caches also serve other purposes. The browser cache stores resources locally on the visitor's device; a PHP opcode cache stores compiled PHP code. Neither of these replaces the storage of individual application data in the object cache nor the delivery of a complete response from a page cache.

The Constant WP_CACHE This alone does not enable a Redis object cache. For a persistent object cache, you need a suitable implementation and its supported configuration. You can find an additional example of how multiple layers interact in the post on AccelerateWP Cache Engine.

What Hits and Misses Tell Us

A Hit occurs when a requested entry is found at the cache level being considered. A Miss means that it cannot be found there. The hit rate is calculated by dividing the number of hits by the total number of hits and misses: Hits / (Hits + Misses) × 100. If there are neither hits nor misses, the rate for that time period is undefined.

An error is not automatically a technical error. An entry may still be missing during the first access; even after it has expired, it may need to be reacquired or regenerated. What matters is what consequences such failed attempts have in the specific process and whether it makes sense to repeat the access attempts at all.

WordPress's core method counts cache hits and misses in its own implementation. However, a drop-in can replace this implementation. Therefore, it’s not possible to reliably deduce from the core counting method what a plugin’s metrics capture: For the version you’re using, check which page views and which time period its metrics cover.

Redis reports with keyspace_hits and keyspace_misses successful or unsuccessful key lookups in the Redis keyspace. Even a failed EXISTS-A call can count as a foul. This Redis Hit Rate Therefore, it is not automatically equivalent to a WordPress or plugin quota.

If a Redis instance serves multiple websites or applications, its counters may collectively reflect traffic from all of them. Without appropriate, separate telemetry data, a global quota cannot be reliably attributed to a single WordPress website. For any comparison, you should therefore document which level and which instance the numbers actually describe.

Carefully check the measurement range and access

Before taking any measurements, determine which object cache implementation WordPress is using. If WP-CLI is available and you have access to the WordPress directory, you can run a read-only audit there using the following command:

wp cache type

The result helps in assessing the implementation, but does not prove that every relevant access is stored persistently. WordPress allows a drop-in to replace the core cache; at the same time, individual groups may not be stored persistently. Therefore, be sure to note the drop-in or plugin used and its version.

Check the documentation for the specific version to see which accesses are included in the displayed hits and misses, and over what time period they are counted. A plugin metric can only be meaningfully compared to another metric if the measurement scope and counting method are known. It is particularly important to know whether the metric describes a single request or a longer time window.

For Redis, provided you have a connection and the necessary permissions, you can query statistics and memory information in read-only mode from a Redis CLI session. The following commands intentionally do not include any credentials:

INFO stats
INFO memory

Document the Measuring range: Which instances or nodes were queried, and which other websites or applications use them? Global Redis counters cannot be easily attributed to a single website when they are shared. Check the output for sensitive operational information before sharing it; neither a flush nor a load test is required for this inventory.

If you don't have access to the Redis CLI, ask your hosting provider about the available metrics and their scope. Even a dashboard is only a useful reference if it's clear whether it shows the same instance, individual nodes, or already aggregated values.

Calculate the Redis Hit Rate Over a Given Interval

Redis statistics are count values, not a definitive statement about a specific measurement period. For an interval analysis, read the values for keyspace_hits and keyspace_misses at the beginning and end of the same time window, from the same instance. Make a note of both times and the corresponding instance so that the readings match.

Next, subtract the initial value from the final value for each counter. The Interval Hit Rate is calculated as: ΔHits / (ΔHits + ΔMisses) × 100. The symbol Δ represents the respective difference. If both differences are zero, no lookups were counted in this window; in that case, the ratio is undefined rather than zero percent.

An illustrative calculation, not an actual measurement: If hits increase by 900 and misses by 100, this results in 90 percent out of a total of 1,000 counted lookups. This does not mean that pages are 90 percent faster, nor that exactly 900 database queries were saved. Redis counts key lookups; their significance for the application depends on the specific access.

If one of the counters decreases between readings, the simple difference calculated using this fraction is not valid. This can be caused by a restart or a reset of statistics. Restart the measurement window or split it at the break point based on reliable operating data, rather than substituting a negative value into the formula.

If there are multiple nodes, first calculate the differences for each relevant node over the same time period. Then add up the hits and misses separately and use those totals to calculate the overall ratio. An unweighted average of the individual percentages treats a node with few lookups the same as one with many; this can significantly distort the overall picture.

Keep track of which nodes are actually included and what role they play in the environment. An overall rate calculated in this way describes only the selected counters and their users; it does not, on its own, result in a specific WordPress Object Cache quota.

Measurement Report and Redis Metrics

In addition to hits and misses, other Redis counters help with classification. Here, too, differences within the selected time period are more meaningful than isolated total figures. The following table distinguishes between the significance of the values and the conclusions that cannot be drawn from them alone.

An increase of expired_keys may be a reason to take a closer look at lifespans and access patterns. However, it does not show whether an entry was needed again shortly after it expired. Likewise, evicted_keys to consider this in the context of the configured storage limit and replacement strategy, rather than immediately concluding that storage capacity needs to be increased.

A useful Test Report Specify the start and end of the time window, the instance or node, the two counter differences, their sum, and the calculated ratio. Also note whether the instance is shared and whether a restart or reset occurred during the window. This ensures that measurements remain traceable later on.

Simultaneously record the request type in question and an appropriate latency metric, as well as database load and error rate. For example, distinguish between public page views and requests from logged-in users if relevant data is available. The Redis quota alone does not reveal which of these request types benefited from a hit.

For later comparison, the time period, nodes, and request mix should be as similar as possible. Also, note any relevant changes and noticeable warm-up phases. Where data is missing or a shared instance does not allow for assignment, this limitation should be noted in the log rather than included in a seemingly precise conclusion.

Cold Start, Online Store, and Static Website

After a restart or deployment, required entries may initially be missing. Such misses are to be expected while the cache is being populated; the hit rate may subsequently increase with repeated accesses. Values from the Cold and Warm Phases You should consider these separately so that a long-term average doesn't obscure either the initial costs or the subsequent performance.

Dynamic requests are particularly interesting in the context of an online store or a logged-in area: A page cache does not necessarily handle every shopping cart or account request. Therefore, compare request types that are as similar as possible and pay attention not only to the hit rate but also to their response times and the database load. A high Redis hit rate alone does not indicate whether the shopping cart is displayed quickly and with correct content.

In contrast, for a predominantly static website, a large portion of page views may already come from the page cache. A persistent object cache primarily affects the requests that WordPress actually processes. Therefore, assess separately whether these remaining requests benefit from the cache and whether the effect impacts the entire website.

If you use Redis in conjunction with other websites or applications, their accesses are also included in the instance counts. Without appropriate, separate telemetry, the global quota cannot be reliably attributed to any single website. Also document which nodes are being tracked: Otherwise, a change in the quota could just as easily be due to different usage patterns or a change in the measurement scope.

Investigate Unusual Values and Errors

A low rate is, at first, an observation, not a diagnosis. Possible explanations include a high number of first-time requests, short lifetimes, or a request distribution with keys that are rarely reused. Check whether the request mix or the measurement window has changed before adjusting memory or cache settings.

The Counters expired_keys and evicted_keys provide additional information: The first counts expired keys, while the second counts keys that have been evicted due to memory limitations. Their differences are specific to the Redis instance and must align with its configuration and usage. A large number of expired keys does not necessarily indicate an incorrectly chosen TTL, nor does it prove that a longer lifespan is advisable; in fact, it can compromise the timeliness of stored data.

For custom extensions, use wp_cache_get the parameter $found Important: It distinguishes between a value that has been found and one that has been saved false from an entry that was not found. Before performing group-related actions, you should use wp_cache_supports Check whether the specific backend supports the desired feature. A replacement drop-in may differ from the core implementation.

Warning: A careless cache flush can affect more entries or applications than intended and skew the next measurement due to a cold start. Determine the scope of impact and obtain approval before performing any deletion actions. Additional considerations regarding the Troubleshooting a Slow WordPress Object Cache help to include any potential cache overhead in the analysis.

Set Your Own Meaningful Target Values

A universal minimum quota of 90 percent is not a sound technical requirement. It makes more sense to have a site-specific target range, which aligns with the expected access distribution and the application's needs. Redis recommends evaluating the observed rate in the context of the specific access pattern; a percentage alone does not explain WordPress performance.

First, record a representative baseline measurement that includes the time period, measurement range, number of requests, and rate. To do this, record response times for important request types, database load, and error rates. Identify cold starts separately and take into account typical differences between periods of low and high traffic, rather than treating a randomly favorable window as the normal state.

Next, plan a specific change and, once it has been approved, test it in a suitable test environment first, if possible. Next, compare similar time periods and request mixes: Do the quota and number of lookups change, as well as latency or database load? This makes it easier to distinguish the effect from a mere shift in access patterns.

Even a high hit rate can mask a few particularly costly misses. Conversely, a moderate hit rate doesn't have to be a problem if relevant queries are answered quickly and accurately. The additional operational overhead for Redis or another persistent backend isn’t automatically justified by a better quota alone; take into account hosting support, costs, and potential failure scenarios.