How to Test VPS Disk Performance Without Misleading Yourself

Buying or tuning a virtual private server usually involves a disk benchmark at some point, whether to compare plans or to diagnose slow page loads. The catch is that most quick tests measure something other than the storage you actually care about. This guide explains where naive benchmarks go wrong and how to run a VPS disk benchmark that reflects reality.

Why Naive Tests Report the Wrong Number#

The most common mistake is measuring memory instead of storage. Linux buffers disk writes in RAM through the page cache, so a simple dd if=/dev/zero of=testfile command can complete in memory almost instantly. The kernel then flushes the data to disk quietly in the background, long after the stopwatch has stopped. Testers see an impressively large number, assume it reflects the SSD or NVMe device underneath, and end up comparing memory bandwidth across providers.

The fix is to force data to reach physical media before timing ends. The dd utility supports this with synchronization options such as conv=fdatasync, which waits until data is committed before reporting, and oflag=direct, which bypasses the page cache entirely. Even then, dd performs only sequential operations, so it tells you how the volume handles large streaming writes and nothing about the small scattered operations that dominate database and content management workloads.

The Three Metrics Worth Measuring#

A complete picture of storage performance requires three distinct numbers, because they answer different questions.

Sequential throughput, reported in MB/s, describes how fast the volume moves large contiguous blocks of data. This matters for backups, media transfers, and log archival, but high sequential speed does not make a website feel responsive.

Random IOPS counts how many small, scattered read and write operations complete each second, typically measured with 4KB blocks. This is the metric that matters for relational databases such as MySQL and PostgreSQL, and for dynamic platforms like WordPress that issue many small reads per page load.

Latency measures the delay between issuing a request and receiving completion confirmation. Even when throughput looks adequate, high latency causes queues to pile up and produces lag that users can feel.

How Virtualization Changes the Picture#

Two properties of VPS environments complicate interpretation. First, many providers grant temporary burst performance, letting a volume run fast for the opening seconds of a workload before throttling back to a baseline rate. A short test captures only the burst window; running each workload for 30 to 60 seconds reveals the sustained level you actually live with.

Second, your instance usually shares physical storage with other tenants, either a local NVMe array carved up by the hypervisor or a network-attached backend such as Ceph or a cloud block volume. Neighbor activity on that shared hardware affects your results. Running the same benchmark at different times of day, and repeating it several times before drawing conclusions, gives you a sense of the variance rather than a single misleading snapshot.

Running a Reproducible Benchmark with fio#

The Flexible I/O tester, fio, is the standard tool for this work because it supports direct asynchronous I/O, configurable block sizes, queue depth, and mixed read/write ratios. Install it from your distribution's package manager, and use its documented job-file options rather than copying shell scripts from forums, so you know exactly what was measured.

For a random 4KB read test that bypasses the page cache, use direct=1 with the libaio engine, set iodepth to control how many requests are in flight, and run for a fixed duration rather than a fixed amount of data. For sequential throughput, switch the block size to 1MB and the pattern to sequential. Point each run at a test file large enough to avoid sitting comfortably in cache, and delete the file afterward so it does not consume space on a small instance.

Keep conditions consistent between runs: same file size, same runtime, same queue depth. Changing one variable at a time is what makes results comparable across plans or providers.

Interpreting Results Calmly#

Treat any single benchmark as a sample, not a verdict. Match the numbers to the workload you actually run: a mostly static site leans on sequential reads and caching, while a busy database cares about random 4KB IOPS and latency. If results swing widely between runs, that swing is itself useful information about shared infrastructure. Record your configuration alongside your numbers so the test can be repeated later, and be skeptical of any result that looks faster than the underlying hardware could plausibly deliver, because it usually means something was cached.