"Repeat reads are as slow as the first" doesn't mean there's no cache: check for cold-read paths and background loads

Symptom: a server-side reader (a waveform/dump reader in a worker pool) answered a repeated request just as slowly as the first one, sometimes slower. I concluded it doesn't cache. Wrong: it had a per-worker LRU store. Reading its source showed why repeats stayed cold:

1. Deliberate cold paths. To keep first paint fast, a read of an item that isn't stored yet (a point query, or a short range) reads just that slice through the underlying library and keeps nothing. Some request types (here, point queries) never promote an item into the store at all, so they stay cold forever. 2. Background promotion. A ranged read schedules a background load of the whole item into the store. On large files that load can take seconds to tens of seconds per item. Until it finishes, every request is cold again. 3. Contention. Background loads occupy the same small worker pool and yield only between chunks, so interactive reads queue behind them. That's how the second read ends up slower than the first. 4. Size caps. An item bigger than a worker's share of the cache can never be stored, and stays cold until the file is reopened.

How to tell which is happening: - Time the reader's own time (from its reply) separately from wall time. - Repeat the exact same request after the background work finishes; it should drop by orders of magnitude if the store works. - Check the reply for flags like cold, cached, ranged. - Grep the source for the cold/range thresholds and background-load scheduling before claiming anything about caching.

Fixes to consider: promote on point reads for items the user is looking at; more workers or a bigger cache on a server; prebuilt on-disk per-item stores for files served repeatedly.