Improve cache hit/miss tracking in the Cache panel for cache.get()

[Harsh3006]

Background

The Cache panel currently estimates cache hits and misses for cache.get() calls based on the returned value. However, Django's cache.get() API does not expose whether a returned value came from the cache or was returned as the caller-provided default when the key is missing.

For example, a cached None and a missing key with default=None are indistinguishable from the return value alone. The same ambiguity exists when a cached value is equal to the supplied default.

The accuracy trade-off

One way to distinguish these cases is to use a unique sentinel object as the default value for cache.get(). Django's cache framework recommends this pattern when callers need to distinguish a missing key from a cached value of None. This allows the caller to determine whether the key was missing.

However, this changes the arguments passed to the user's cache call. Other instrumentation or observability tools may be wrapping the cache backend and observing those arguments, in which case they would see the internal sentinel instead of the application's original default value. This could cause unexpected behavior or make debugging difficult.

Because of this, using the sentinel approach by default isn't considered appropriate.

Possible direction

One option would be to make more accurate tracking an opt-in setting. The default behavior would remain non-invasive, while users who want more accurate statistics could explicitly enable the more intrusive instrumentation with the associated compatibility considerations documented.

Before pursuing this, we'd like to understand whether more accurate cache hit/miss statistics would be useful enough to users to justify maintaining such an option.

Discussion

Have you encountered situations where inaccurate cache hit/miss statistics made debugging or performance analysis difficult? Would an opt-in mode for more accurate tracking be useful to you?

If you have ideas for achieving accurate tracking without modifying the user's cache.get() call, we'd also be interested in hearing them.