Benchmarks

Results

• PutFS on ZFS (HDD+SSD) is 3–4x faster than MinIO on XFS/SSD-only for concurrent reads
• PutFS writes are 2–6x faster than MinIO regardless of MinIO's filesystem
• PutFS directory listings are much faster than MinIO
• PutFS uses 30x less memory
• Large sequential reads are equal across all configurations
• MinIO wins on bulk parallel uploads (mc mirror vs putfs sync)

Small file random reads (10K files, 1K–100K, wrk, 30s)

PutFS is 3–4x faster on concurrent small file reads. nginx serves files via sendfile directly from ZFS ARC – Python is never involved.

Single-file write latency

PutFS is 2–6x faster than both MinIO configurations across all file sizes.

Bulk upload (10K files, 1K–100K)

MinIO's mc mirror wins on bulk parallel uploads – Go's native concurrency outperforms Python's threaded putfs sync. The gap has narrowed significantly since switching from sequential curl to threaded sync.

Large file sequential read (1 GB)

Nearly equal – all systems are memory/cache-bound on large sequential reads.

Directory listing

PutFS is 8–390x faster on listing. The near-constant ~10ms regardless of dataset size comes from streaming os.scandir results directly to the client. MinIO's listing performance degrades linearly – its internal metadata overhead dominates.

Memory footprint (idle)

PutFS uses 30x less memory.

Summary

Test setup

Both PutFS and MinIO ran in docker on the same server. PutFS with the best possible ZFS setup for this hardware (HDD mirror, SSD special vdev, SSD SLOG, SSD L2ARC). MinIO was tested on its recommended setup (single disk XFS on SSD, noatime,nodiratime). PutFS small files land on the ZFS special vdev (SSD), making the SSD-vs-SSD comparison fair.

Tuning

• PutFS:
  • nginx, no access logs
  • granian, unix socket, uvloop
• MinIO:
  • MINIO_API_REQUESTS_MAX: "0"
  • MINIO_SCANNER_SPEED: "fastest"
  • MINIO_BROWSER: "off"
  • GOMAXPROCS: "0"

Hardware

Note: Special vdev was not mirrored. SLOG and L2ARC on SATA SSD, not NVMe.

Running

All benchmark scripts live in benchmark/. See the benchmark README for details.

cd benchmark
make putfs     # PutFS benchmark
make minio     # MinIO comparison

Extract results as CSV:

bash benchmark/analyze.sh benchmark/results/putfs

Implementation comparison (Python / Go / Rust)

The repository includes Go and Rust ports of the app server alongside the reference Python/Starlette build – the HTTP API is identical, only the language differs. This benchmark isolates the app-server hot path (PUT / DELETE / LIST; in production GET/HEAD are served by nginx sendfile, never the app) by running each server bare on localhost (no nginx, no auth) and driving it with wrk.

Parallel PUT throughput (4 KB objects, wrk)

Directory listing (wrk, keep-alive)

• Listing – Rust wins decisively: 1.26M–2.71M keys/s, ~1.7–2.0× Go and ~5–10× Python, widening as the directory grows.
• Writes – Rust wins at mid concurrency, Go at high, c1 a wash. Rust leads c10 PUT (~1.6× Go); Go takes c100 (~1.9× Rust); at c1 the two are tied (~8.5k req/s). Rust offloads each PUT's temp-file open and rename syscalls to a thread pool (mirroring Python's anyio.to_thread), which costs it only at high fan-out.
• Both ports are ~5–13× Python on writes (depending on concurrency). Python is stable but its per-line async listing tops out ~240–270k keys/s regardless of dataset size.

Measured on an Intel Core i7-1360P (16 threads), 30 GB RAM, Debian forky/sid (kernel 7.0.10); bare servers on localhost, page cache, mean of three wrk runs. Different machine from the ZFS rig used for the MinIO comparison above.

make build-rust build-go     # build the native binaries (repo-root Makefile)
cd benchmark && make impls   # benchmark python + go + rust
make analyze-impls           # side-by-side CSV