![NVMe Hosting Performance Speed Tests [Solved] for Beginners](/images/blog/nvme-hosting-performance-speed-tests-solved-for-beginners.jpg)
You signed up for "NVMe hosting" because the sales page promised blazing speed. But how do you know the server actually uses NVMe? More importantly, how fast is it really compared to older SATA SSD or spinning-disk hosting? I'll show you how to run your first speed test, interpret the results, and spot when a host is overselling.
What NVMe means in plain English
NVMe stands for Non-Volatile Memory Express. It's a storage protocol designed for flash memory that connects directly to the CPU over PCIe lanes instead of going through the older SATA or SAS controllers.
Think of it like this: SATA is a narrow two-lane road built decades ago for spinning hard drives. NVMe is a sixteen-lane highway purpose-built for solid-state memory. The flash chips themselves might be similar, but the path to your application is vastly wider and shorter.
In practice, NVMe drives deliver sequential read speeds of multiple gigabytes per second and can handle hundreds of thousands of random I/O operations per second. A SATA SSD tops out around 550 MB/s sequential and maybe 100k IOPS. Spinning disks? Measured in hundreds of IOPS at best.
Why hosting performance tests matter
Many shared-hosting and budget VPS plans advertise "NVMe storage" but never specify how the drives are configured or how many tenants share the same physical device. You might have an NVMe drive in the server, but if fifty other accounts hammer it simultaneously or the hypervisor throttles disk I/O, your application won't see NVMe speed.
Running a benchmark gives you three things:
- Proof the underlying hardware is actually NVMe (not SATA relabeled).
- A baseline to compare against when your site slows down later.
- Ammunition for a support ticket if the speed is far below what NVMe should deliver.
Tools you need
You need SSH access to your server or VPS. Shared cPanel accounts without shell access can't run disk benchmarks directly; you're stuck trusting the host's word or watching application-level metrics like WordPress admin load time.
For VPS and dedicated servers, the two standard tools are dd for quick sequential tests and fio for detailed workload simulation. Almost every Linux distribution includes dd out of the box. You'll install fio separately.
Your first sequential write test with dd
Log in via SSH and run:
dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct
This writes a 1 GB file to disk using direct I/O, bypassing the operating system's write cache. Direct I/O is critical—without the oflag=direct flag, Linux caches the write in RAM and reports impossibly high speeds that don't reflect real disk performance.
You'll see output like:
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.823 s, 1.3 GB/s
That's 1.3 GB/s sequential write. Clean up the test file:
rm testfile
Now test sequential read:
dd if=testfile of=/dev/null bs=1M iflag=direct
Oops—testfile no longer exists. Write it again first:
dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct
dd if=testfile of=/dev/null bs=1M iflag=direct
rm testfile
Real NVMe should show read speeds above 1 GB/s. SATA SSD will cap around 500 MB/s. Spinning disks struggle to hit 150 MB/s.
What the dd test doesn't tell you
Sequential throughput is only half the story. Databases, PHP sessions, and mail queues perform thousands of small random reads and writes. A drive can have fantastic sequential speed but choke on random I/O if the controller or firmware is poorly tuned.
That's where fio comes in.
Installing and running fio
On Debian or Ubuntu:
sudo apt update && sudo apt install fio -y
On CentOS, AlmaLinux, or Rocky:
sudo yum install fio -y
Create a simple test file:
nano random-read-test.fio
Paste this configuration:
[random-read]
ioengine=libaio
direct=1
bs=4k
rw=randread
size=1G
numjobs=1
runtime=30
time_based
group_reporting
Save and exit (Ctrl+O, Enter, Ctrl+X). Run it:
fio random-read-test.fio
After thirty seconds, fio prints a summary. Look for the line starting with read: IOPS=. NVMe typically delivers tens of thousands of IOPS for random 4K reads. SATA SSD might show 10k to 30k. Spinning disks report a few hundred.
Testing random writes
Random writes are harder on SSDs than reads because of wear-leveling overhead. Edit the test file:
nano random-write-test.fio
Change rw=randread to rw=randwrite:
[random-write]
ioengine=libaio
direct=1
bs=4k
rw=randwrite
size=1G
numjobs=1
runtime=30
time_based
group_reporting
Run it:
fio random-write-test.fio
Write IOPS will usually be lower than read IOPS. A good NVMe drive under light multi-tenant load should still hit five-figure IOPS. If you see three-figure IOPS, either the disk is SATA or the hypervisor is heavily throttling you.
Mixed workload test
Real applications rarely do pure reads or pure writes. Try a 70% read, 30% write mix:
[mixed]
ioengine=libaio
direct=1
bs=4k
rw=randrw
rwmixread=70
size=1G
numjobs=4
runtime=30
time_based
group_reporting
The numjobs=4 simulates four concurrent workers, closer to how a busy web application behaves. Save as mixed-test.fio and run:
fio mixed-test.fio
This test stresses the I/O scheduler and shows whether the host's disk subsystem can handle parallel requests. If performance collapses compared to the single-job tests, the storage backend or hypervisor has contention problems.
Interpreting latency numbers
Besides IOPS and throughput, fio reports latency percentiles. Look for the clat (completion latency) section. The 99.00th percentile line tells you the worst-case delay that 99% of I/O operations stay under.
For NVMe, sub-millisecond 99th-percentile latency is normal under moderate load. If you see multi-millisecond or double-digit millisecond latencies during a simple test, something is wrong—oversubscribed storage, failing drive, or broken hypervisor I/O throttling.
In support tickets I handled, latency spikes were often the smoking gun when customers complained about "random slowness" that didn't show up in CPU or RAM graphs.
When the numbers don't add up
You paid for NVMe but dd shows 300 MB/s and fio reports 5k IOPS. Three common causes:
- SATA SSD mislabeled as NVMe. Some budget hosts use SATA drives and hope customers won't test. Check
lsblk -d -o name,rota,disc-granto see drive type, though this can be faked in VMs. - Aggressive hypervisor throttling. The physical drive is NVMe, but your VM is capped at a fraction of its capacity. OpenStack and Proxmox let admins set per-VM IOPS limits.
- Oversubscription. Fifty VMs share one NVMe drive. When everyone runs backups or batch jobs simultaneously, performance tanks.
If the host won't explain the gap, consider moving. Life's too short for slow storage.
Baseline your production workload
Synthetic benchmarks tell you the ceiling, but your application's actual I/O pattern matters more. If you run WordPress, the database does small random reads. Mail servers do lots of fsync-heavy writes. Object storage buckets do large sequential operations.
Run iotop during normal traffic to see which processes hit the disk hardest:
sudo iotop -o
The -o flag shows only active I/O. Press a to toggle accumulated mode, which sums I/O over time instead of showing instantaneous rates. This helps you identify the chattiest services.
Once you know your workload profile, tune the fio test to match it—adjust block size, read/write ratio, and queue depth to mimic your app. That custom benchmark becomes your regression test whenever you suspect storage problems.
What to check first if performance drops later
Speed changes over time. Three months after your initial test, the server feels sluggish. Re-run the same fio tests and compare.
If the numbers are similar, the storage is fine—look at CPU, RAM, network, or application code. If IOPS or latency got significantly worse, check:
- Disk space: Run
df -h. SSDs slow down when nearly full because the controller runs out of free blocks for wear leveling. - Noisy neighbors: If you're on shared or cloud hosting, another VM might be monopolizing I/O. There's often little you can do except complain to support or migrate.
- Drive health: Run
sudo smartctl -a /dev/nvme0n1(installsmartmontoolsfirst). Look for reallocated sectors, wear indicators, or error counts.
Proof in thirty seconds
Run the dd sequential write test and the fio random read test. Together they take under a minute and immediately show whether you have real NVMe, SATA SSD, or spinning rust. Armed with those two numbers, you can compare plans, challenge marketing claims, and troubleshoot performance issues with data instead of guesswork.