Immich Caching: How Warm Data Changes Repeated Requests

Repeated Immich requests become faster when models, database pages, thumbnails, and client assets remain warm enough to avoid earlier loading work.

The second search is not necessarily proof that the server gained capacity. It may reuse data prepared by the first request, so meaningful testing must identify which state persists and report cold and warm behavior separately.

The First Request Pays for Missing State

After a restart or long idle period, an Immich request may need code paths, model weights, database pages, and thumbnail files brought into active memory. It can also trigger connection setup and client asset retrieval. Later requests skip some of that work, even though their visible query is identical.

A user report measures roughly five seconds for a first smart search and about half a second for an immediate repeat while GPU memory rises as the model loads. The numbers are configuration-specific, but the observed sequence demonstrates why first and repeated searches represent different system states.

Record the exact cold condition: full container restart, machine-learning service restart, cleared client state, or defined idle interval. These conditions are not interchangeable. A result labeled only “cold” cannot reveal whether the delay came from model residency, server page cache, connection setup, or client-side reuse.

Warmth Exists at Several Independent Layers

There is no single Immich cache switch that explains every repeated request. The operating system can retain file pages, PostgreSQL can reuse hot data, the machine-learning process can retain a loaded model, and browsers or mobile apps can reuse thumbnails and application assets. Each layer has a different lifetime.

A cache-warming overview explains the general distinction: a warm cache serves retained data with less delay, while a cold cache must fetch from a slower primary source. In Immich, that primary source may be persistent storage, and the “data” may be media, database pages, or model files.

Use selective resets. Repeat in the same browser, then a fresh client; restart only the machine-learning service, then the application; finally reboot the host. The first reset that restores the long delay identifies the layer whose retained state contributed most, although several layers may compound.

Warm Results Can Hide a Capacity Boundary

A small set of repeated searches can keep exactly the needed pages and thumbnails resident. That benchmark may look excellent while a broader family library exceeds memory and causes frequent misses. Capacity is exposed when the working set changes, another service evicts data, or a restart removes transient state.

The ZimaSpace data-path explanation separates database selection from media display, which prevents a warm thumbnail from masking a slow query or a cached query from masking slow file delivery. Time the result identifiers and the displayed assets independently when diagnosing repeated-request gains.

Rotate among several queries and timeline regions instead of repeating one item indefinitely. Include a representative idle interval and a competing workload. A server has useful capacity when acceptable latency persists across the expected working set, not merely when one hot path remains resident.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Report Cold, Warm, and Disturbed Runs Together

Build a three-part protocol. First run the endpoint after a documented cold condition. Second repeat it immediately without changing inputs. Third introduce the expected disturbance—idle time, another container, or a wider query set—and repeat. Capture median and slow-tail latency rather than a single stopwatch value.

A first-search support thread reports a ten-to-fifteen-second initial delay followed by nearly instant repeats, reinforcing the need to preserve both distributions. It does not establish a universal Immich duration; model choice, accelerator, memory, storage, and release can all change the gap.

Conclude with two numbers and one boundary: typical warm latency, typical cold latency, and the event that loses warmth. If cold behavior violates the household’s target, keep necessary state resident or improve that loading path. If only artificial cold tests fail, document the accepted operational condition.