Operators should be able to measure the performance of the disks Blaze runs on, using an I/O profile that matches Blaze's RocksDB usage, so they can tell whether their storage is fast enough — before going into production and when diagnosing performance problems.
Currently the only guidance is a manual fio recipe in docs/performance/disk-perf.md, which requires shell access and an extra tool.
The measurement should be:
- runnable as a job from the admin UI (create, watch progress, cancel, see results),
- triggerable via a new system-level
$disk-perf FHIR operation following the async request pattern (so blazectl can gain a subcommand for it, like $compact),
- self-contained (in-process Java NIO, no external tools required).
The benchmark runs three phases against a temporary file on the volume of a selectable database directory (index by default):
- Sequential write — emulates compaction/flush I/O (default 4 GiB file, 1 MiB chunks).
- Random read — emulates index/resource point reads: concurrent readers, direct I/O, block size taken from
DB_BLOCK_SIZE (default 16 KiB).
- Append + fsync — emulates WAL appends of the transaction and resource stores.
Outputs are raw numbers (sequential write throughput, read IOPS, read throughput, read latency p50/p95/p99/max, fsync rate, fsync latency p50/p95/p99) plus a 0–100 score, computed from per-dimension sub-scores normalized against reference values of a good local NVMe SSD, and a rating (excellent / good / acceptable / insufficient).
Operators should be able to measure the performance of the disks Blaze runs on, using an I/O profile that matches Blaze's RocksDB usage, so they can tell whether their storage is fast enough — before going into production and when diagnosing performance problems.
Currently the only guidance is a manual
fiorecipe indocs/performance/disk-perf.md, which requires shell access and an extra tool.The measurement should be:
$disk-perfFHIR operation following the async request pattern (so blazectl can gain a subcommand for it, like$compact),The benchmark runs three phases against a temporary file on the volume of a selectable database directory (index by default):
DB_BLOCK_SIZE(default 16 KiB).Outputs are raw numbers (sequential write throughput, read IOPS, read throughput, read latency p50/p95/p99/max, fsync rate, fsync latency p50/p95/p99) plus a 0–100 score, computed from per-dimension sub-scores normalized against reference values of a good local NVMe SSD, and a rating (excellent / good / acceptable / insufficient).