How to Measure Jellyfin Performance Without Mistaking Cache for Capacity

Eva Wong

IceWhale author

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

How to Measure Jellyfin Performance Without Mistaking Cache for Capacity

Jellyfin benchmarks become misleading when a warm filesystem or metadata cache is treated as proof of cold-start hardware capacity.

The second library open or repeated stream can reuse data already in memory, while the first run may wait on storage, metadata, and process setup. Both states are useful, but they answer different questions. Run cold and warm tests as separate cases with the same media, client, quality, and competing workload so cache reuse does not masquerade as extra hardware capacity.

Cold and Warm Runs Answer Different Questions

A cold test reveals the cost of fetching state from storage and reconstructing working sets, while a warm test shows repeat behavior after useful data is resident. Averaging the two hides the mechanism.

Repeated reads can avoid storage work while data remains in the Linux page cache.

Record the first run after restart separately from two repeated runs. Do not discard the cold result just because the warm result is more flattering.

Metadata Benchmarks Are Especially Cache-Sensitive

Poster grids, search, and library pages can revisit the same small files and database pages repeatedly. These workloads often show a larger warm-cache effect than a long sequential media stream.

Moving Jellyfin container data away from slower media disks changes the cold path directly; one NAS setup keeps Jellyfin app data on SSD while media remains on sleeping HDD storage.

Time a named library open and search after restart, then repeat them. If the gap is large, include both numbers in any storage comparison.

Background Jobs Can Pollute the Comparison

A scheduled scan, thumbnail task, backup, or another container can evict useful pages or consume storage queues between runs. A “cache result” is only interpretable when the competing workload is known.

Jellyfin exposes library work through scheduled media scans, so background maintenance should be held constant instead of being allowed to change between benchmark runs.

Run one controlled benchmark window with heavy tasks paused, then a second with normal services active. The home media-server workload map is useful for deciding which overlap belongs in the real acceptance test.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

Capacity Is the Repeatable Worst Normal Case

Hardware capacity should describe the workload the server can sustain under expected conditions, not the fastest cached result or an artificial worst case nobody experiences. The test needs a named scenario and pass criterion.

The USE method ties capacity to resource saturation and errors rather than one elapsed-time number.

Define pass conditions for startup, search, and playback, then repeat cold and warm cases after each change. Call the system improved only when the relevant case improves consistently.