fio documentation treats bandwidth, IOPS and latency as separate metrics; one sequential MB/s test does not represent real application performance.
Evaluate NVMe vs SATA SSD using IOPS, latency, queue depth and fio instead of MB/s alone; measure VPS storage performance correctly.
fio documentation treats bandwidth, IOPS and latency as separate metrics; one sequential MB/s test does not represent real application performance.
VPS storage performance depends not only on the physical drive but also on storage backend, RAID, cache, network storage, host density and I/O limits.
NVMe is a low-latency PCIe storage protocol, but your VM does not have to access the physical device directly. Ceph, ZFS, RAID, LVM, qcow2, network storage or throttling can sit in between.
Instead of assuming NVMe means fast, measure the I/O pattern your application needs. WordPress/MySQL can care about small random I/O and fsync, backups about sequential throughput and databases about tail latency.
MB/s measures transferred volume, IOPS counts operations per second and latency measures completion time. A disk can show high large-block throughput while performing poorly on 4K random I/O or p99 latency.
Queue depth dramatically changes results. High QD32 IOPS may not reflect latency-sensitive PHP/MySQL requests. Include low queue-depth tests too.
Writing fio directly to a raw block device can destroy data. Use a test file in a filesystem with enough free space. Even file-based tests can affect production I/O, so avoid peak hours.
fio --name=randread --filename=/tmp/eka-fio.test --size=1G --bs=4k --rw=randread --iodepth=1 --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting
fio --name=randrw --filename=/tmp/eka-fio.test --size=1G --bs=4k --rw=randrw --rwmixread=70 --iodepth=8 --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting
fio --name=seqread --filename=/tmp/eka-fio.test --size=2G --bs=1M --rw=read --iodepth=4 --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting
IOPS and bandwidth are obvious, but completion latency and percentiles can explain user experience better. A p95/p99 latency far above average can indicate queuing or inconsistent storage performance.
Repeat the same test at different times. Consistency on a virtual server is often more valuable than one record-breaking run.
For WordPress/WooCommerce, small random mixed I/O and low-queue latency matter. Media/backup workloads care more about sequential throughput. Databases can care about fsync and tail latency. Game servers may notice spikes during world saves.
| Metric | What it tells you | Sensitive workload |
|---|---|---|
| Sequential MB/s | Large-file throughput | Backup / media |
| 4K Random IOPS | Small-I/O capacity | CMS / DB |
| p99 Latency | Tail latency | DB / API |
Do not buy based on one benchmark, port label or CPU brand. Repeat tests at different times, avoid destructive storage tests on production data, and verify provider resource/fair-use policies in writing.
It has higher potential, but virtualization, limits and storage backend can change results; benchmark the actual VM.
Raw-device write tests can destroy data. File-based tests are safer but can still impact production I/O.
Share your software stack, concurrency, storage/database load and target region; size the server around the real bottleneck rather than RAM/core labels alone.