When evaluating a VDS, the useful question is not “What is the highest number I can obtain?” It is “Does the system deliver predictable service under a documented workload, and can another operator reproduce the observation?” This guide builds a small Linux baseline around three signals that expose different failure modes:

• CPU steal time, which can reveal scheduling contention outside the guest
• disk p95 and p99 completion latency, which exposes slow tail operations hidden by averages
• network delay variation and loss, measured without saturating an unknown path

The method is intentionally vendor-neutral. It produces evidence, not a universal pass/fail score.

Why common benchmark results mislead

Virtual infrastructure has layers. The guest kernel sees virtual CPUs, virtual block devices, and virtual network interfaces. Below them may be a hypervisor scheduler, shared storage, caching, rate limits, and a physical network used by other tenants. A single benchmark run collapses all of those changing conditions into one number.

Several effects can make that number look better or worse than normal service:

1. Warm caches: repeated reads may come from RAM or a storage controller cache rather than the underlying media.
2. Burst allowances: CPU, disk, or network limits may permit a short burst before enforcing a sustained rate.
3. Queue depth: an unrealistic queue can maximize throughput while producing latency that would hurt a database.
4. Remote endpoint choice: a public test server can be overloaded or reached through a different path each time.
5. Noisy timing: five quiet minutes at noon do not describe the same host during the evening peak.

That is why the baseline below records context, runs for minutes rather than seconds, and is repeated in separate time windows.

1. Freeze the test conditions

Do not benchmark a production disk or run stress tools while latency-sensitive customer work is active. Use an expendable instance or a maintenance window, keep at least 20% of the filesystem free, and remove the temporary test file afterward.

Install the required tools using your distribution packages: sysstat, stress-ng, fio, jq, iperf3, and mtr. Before every run, capture the environment:

mkdir -p "$HOME/vds-baseline"
cd "$HOME/vds-baseline"

{
  date --iso-8601=seconds
  uname -a
  lscpu
  free -h
  lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,ROTA,DISC-MAX
  df -hT
  fio --version
  iperf3 --version
} > environment.txt 2>&1

Also record the instance size, region, image, filesystem, advertised limits, and whether other workloads were running. Keep the same image and test parameters when comparing providers or dates. Change one variable at a time.

Run the complete baseline at least three times in each of three windows: quiet, normal, and expected peak. One sample is an anecdote; repeated distributions are a baseline.

2. Observe CPU steal instead of trusting a CPU score

Linux reports %steal as time in which a virtual CPU was ready to run but the hypervisor did not schedule it. On a KVM-style guest, recurring steal during CPU demand can indicate host contention. Zero steal does not prove an uncontended host: some virtualization platforms do not expose it, and frequency throttling or host-level limits can appear elsewhere.

First observe an idle period:

LC_ALL=C mpstat -P ALL -o JSON 1 300 > cpu-idle-mpstat.json

Then create a controlled five-minute load while collecting the same metric in a second terminal:

# Terminal 1: monitor every vCPU
LC_ALL=C mpstat -P ALL -o JSON 1 330 > cpu-load-mpstat.json

# Terminal 2: use all visible vCPUs for five minutes
stress-ng --cpu "$(nproc)" --cpu-method matrixprod \
  --timeout 300s --metrics-brief |& tee cpu-stress.txt

Do not report only the final Average: line. Look for the shape of steal time: its median, upper percentiles, longest burst, and whether one vCPU is consistently worse. A brief scheduling event and repeated ten-second clusters have different operational consequences even if their averages match.

A simple extraction for the aggregate all row is:

jq -r '.sysstat.hosts[0].statistics[]."cpu-load"[]
  | select(.cpu=="all") | .steal' cpu-load-mpstat.json \
  | sort -n > cpu-steal-percent.txt

awk '{v[NR]=$1} END {
  p50=int((NR-1)*0.50)+1
  p95=int((NR-1)*0.95)+1
  p99=int((NR-1)*0.99)+1
  printf "steal p50=%.2f%% p95=%.2f%% p99=%.2f%%\n", v[p50],v[p95],v[p99]
}' cpu-steal-percent.txt

The JSON layout can vary between major sysstat releases, so inspect one sample before automating the parser. Preserve the raw file; it is the source of truth.

Avoid declaring that every value above a fixed percentage is “bad.” The meaningful threshold depends on the workload. For a latency-sensitive service, even short steal bursts may matter. For a batch worker, completion time and sustained throughput may matter more. Correlate steal bursts with application latency before blaming the host.

3. Measure disk tail latency with fio

Storage throughput and storage responsiveness are different properties. A device can deliver many megabytes per second while a small portion of operations waits hundreds of milliseconds. Databases, package managers, and control panels often feel that tail.

Use a regular file on the filesystem you actually want to test. Do not point fio at a raw device containing data. Create a dataset larger than trivial caches, using direct I/O:

TESTFILE=/var/tmp/vds-fio.bin

fio --name=prepare --filename="$TESTFILE" --size=4G \
  --rw=write --bs=1M --ioengine=libaio --iodepth=16 \
  --direct=1 --end_fsync=1

Start with a latency-oriented random-read workload at queue depth 1. This resembles a single thread waiting for each small read rather than a synthetic throughput contest:

fio --name=randread-qd1 --filename="$TESTFILE" --size=4G \
  --rw=randread --bs=4k --ioengine=libaio --iodepth=1 --numjobs=1 \
  --direct=1 --time_based=1 --runtime=300 --ramp_time=30 \
  --percentile_list=50:95:99:99.9 --output-format=json \
  --output=fio-randread-qd1.json

Next run a modest mixed workload. A 70/30 read/write ratio is not “the standard”; it is simply a documented second probe. Replace it with a trace-informed ratio if you know the application:

fio --name=randrw-qd8 --filename="$TESTFILE" --size=4G \
  --rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio \
  --iodepth=8 --numjobs=1 --direct=1 --time_based=1 \
  --runtime=300 --ramp_time=30 --percentile_list=50:95:99:99.9 \
  --output-format=json --output=fio-randrw-qd8.json

Extract completion-latency percentiles in nanoseconds from the JSON rather than copying the bandwidth headline:

jq '.jobs[0] | {
  read_iops: .read.iops,
  read_p95_ns: .read.clat_ns.percentile["95.000000"],
  read_p99_ns: .read.clat_ns.percentile["99.000000"],
  write_iops: .write.iops,
  write_p95_ns: .write.clat_ns.percentile["95.000000"],
  write_p99_ns: .write.clat_ns.percentile["99.000000"]
}' fio-randrw-qd8.json

Compare p50, p95, and p99 together. A growing p99-to-p50 ratio is often more informative than a small change in average latency. Run iostat -xz 1 alongside fio and preserve it too; queue size, utilization, and device latency help explain a poor result.

Delete only the known test file when finished:

rm -- "$TESTFILE"

4. Separate network jitter from bandwidth

Jitter is delay variation, not low bandwidth. Testing at line rate can create the very queueing delay you then report as a defect. Use an iperf3 server you control, pin its location, and test at a rate safely below the expected link limit. Ideally use two targets: one nearby to expose the access path and one in another network to expose transit behavior.

Collect five minutes of RTT samples without DNS lookup:

TARGET=203.0.113.10   # replace with your controlled endpoint

ping -n -i 0.2 -c 1500 "$TARGET" \
  | awk -F'time=' '/time=/{split($2,a," "); print a[1]}' > rtt-ms.txt

awk 'NR>1 {d=$1-prev; if(d<0)d=-d; print d} {prev=$1}' \
  rtt-ms.txt > ipdv-ms.txt

The second file contains absolute successive RTT differences, a practical form of inter-packet delay variation. Calculate percentiles for both files:

for file in rtt-ms.txt ipdv-ms.txt; do
  sort -n "$file" | awk -v name="$file" '{v[NR]=$1} END {
    p50=int((NR-1)*0.50)+1
    p95=int((NR-1)*0.95)+1
    p99=int((NR-1)*0.99)+1
    printf "%s p50=%.3fms p95=%.3fms p99=%.3fms samples=%d\n", \
      name,v[p50],v[p95],v[p99],NR
  }'
done

Then use UDP iperf3 at a declared offered rate, for example 50 Mbit/s, and capture its jitter and loss in both directions:

iperf3 -c "$TARGET" -u -b 50M -t 120 -O 10 --json > udp-forward.json
iperf3 -c "$TARGET" -u -b 50M -t 120 -O 10 -R --json > udp-reverse.json

jq '.end.sum | {jitter_ms, lost_packets, packets, lost_percent}' \
  udp-forward.json udp-reverse.json

Treat ICMP results as supporting evidence, not a verdict; routers may deprioritize echo traffic. If a run degrades, use mtr -ezbw -c 300 "$TARGET" to compare paths, but do not assign blame to the first hop showing loss unless that loss continues to later hops.

Turn measurements into a defensible comparison

Create one row per run, not one row per provider. Include timestamp, host region, workload state, CPU-steal p50/p95/p99, disk read and write p50/p95/p99, RTT percentiles, IPDV percentiles, UDP loss, and tool versions. Report the median run plus the worst observed window. Keep raw outputs so someone else can audit the summary.

The final interpretation should distinguish capacity from consistency:

• CPU throughput with low steal can still vary because of clock policy.
• High disk IOPS with unstable p99 latency may be poor for synchronous work.
• High network throughput with loss or high IPDV may be poor for voice, games, or clustered systems.
• One degraded remote route does not prove a weak virtual machine.

A useful benchmark is a controlled experiment with enough context to be repeated. Once the method is stable, the numbers become comparable. Until then, a large score is only a screenshot.

Disclosure: This article was prepared by the EniyiSunucum team, operator of AS215068. It presents a vendor-neutral test method and contains no benchmark result or performance claim for the company. Company information: EniyiSunucum.