Server caches, reuse and invalidation
Server caches retain reusable application results, with keys and invalidation determining whether those results remain suitable for a later request.
A server cache keeps a result that may be reused instead of recalculated or fetched again. It can hold artwork, a query result, analyzed media information or another expensive derived value.
This is an application-level decision. The operating system's page cache is a separate mechanism that reuses stored bytes below the application.
A cache key defines which requests are equivalent
Suppose a fictional cache stores a library listing under the key Movies. Two users have different library permissions. Reusing one user's listing for the other would be wrong if the key omitted the relevant user and policy context.
A better key must represent the inputs that determine the result. The exact design can use identity, query parameters, data generation and other applicable state.
| Reuse condition | Why it matters |
|---|---|
| Same relevant query | A differently sorted or filtered request needs another result |
| Same applicable user/policy context | Access and user state can change the content |
| Same underlying data generation | A new item can invalidate an old list |
| Acceptable age | A result may be intentionally allowed to be somewhat stale |
A high hit rate is useful only when the reused result is suitable.
Invalidation connects a change to stored results
An original generation model is:
Library generation G1 -> cached result for G1
New item committed -> library generation G2
Request for current G2 -> old G1 result is not a current-generation hit
An application can invalidate entries on changes, give them a lifetime, check a version or combine these methods. A restart often clears in-memory caches, but it does not prescribe how every on-disk cache is rebuilt.
A cache miss also does not automatically mean failure. It can trigger the ordinary computation or storage lookup that produces the result.
Regenerable data have a documented role
Generated thumbnails can have a supported rebuild path. User history and settings are persistent state with a different recovery role. A directory's name or a file's small size is insufficient to classify it.
For Emby, warm and cold operation can have different response times because of reusable application results as well as storage caches. Distinguish those layers before interpreting an improvement after browsing the same title twice.
See Also
- Storage caches: reusable reads and deferred writes
- Library databases, identities and indexes
- RAM, reclaim and memory pressure