Cyclone vs. the classic file cache — the numbers
The raw head-to-head medians behind the benchmark write-up, plus the interactive charts. Two machines: a laptop with a fast NVMe SSD (the conservative case) and a workstation on realistic virtualized storage. 1 GB caches, median of repeated runs on quiesced machines.
Head-to-head
| Scenario | Machine | Cyclone | File cache | Winner |
|---|
Higher is better for throughput; lower is better for latency and on-disk footprint. Notice the same scenario's advantage grows on the slower (workstation) storage — and that the file cache wins exactly one row: over-provisioned + idle, on the laptop's fast NVMe/APFS SSD.
Concurrency scaling
Realistic mixed workload, under pressure
Latency distribution (CDF) · before & after
Workstation, in-process RAM tier off. Read-bound = the working set is memory-resident; under pressure = physical memory capped at 512 MB, so reads fall through to disk. A curve further left and standing up straighter means faster reads with a tighter tail — the gap between Cyclone and the previous build widens under pressure.
Advantage vs. disk speed
Every headline result as a Cyclone/file-cache ratio, both machines side by side. The slower disk (darker bars) widens the gap in every pair.
Eviction janitor · 100k files
Staying inside the cap
Size-to-RAM (memory pressure)
Read-path rework · before & after
A later, controlled re-measure of just the read path (2026-07-14): concurrent reads made lock-free, one per-write sync dropped. Same 64-core workstation, the in-process RAM tier turned off — mod_pagespeed's default serve config, with reads coming straight from the mapped volume — physical memory swept to create pressure, average of two runs. This is a different configuration and a different build from every chart above — compare bars only within this chart, not across sections. Faded bars are the previous Cyclone; solid bars are the reworked build.
The machines
We-Amp B.V. · Cyclone Cache