🔥 Limited Time Offer!  Â·  Get your VPS for £1 for the first month
Claim £1 VPS →
🚀 New: Enterprise hosting solutions — Visit UK Speed →

Press Esc to close · Enter to search

Tutorials

How to Benchmark Your UK VPS: CPU, NVMe & Network with sysbench, fio & Geekbench 2026

How to Benchmark Your UK VPS: CPU, NVMe & Network with sysbench, fio & Geekbench 2026

The fastest way to benchmark your VPS and prove a provider’s numbers are real is to run the same open-source tests they run and read the output yourself. Marketing pages love round figures, but a reproducible benchmark you control turns “high-performance” into hard data. This guide walks UK developers, sysadmins and buyers through benchmarking CPU, memory, NVMe disk and network on a live VPS, with the exact commands and how to compare providers fairly.

What Is a VPS Benchmark?

A VPS benchmark is a controlled test that measures the real, delivered performance of your virtual server rather than the theoretical capacity of the underlying hardware. Because many virtual machines share one physical host, the throughput you actually get depends on the hypervisor, how heavily the host is packed, and how well the provider isolates each tenant. A benchmark cuts through the spec sheet and tells you what your workload will really experience.

Broadly, four things matter. CPU performance decides how fast PHP, Laravel or game-server logic executes. Memory bandwidth affects caching and in-memory databases. NVMe disk speed drives database queries and WooCommerce checkouts. Network throughput and latency shape download speeds and responsiveness for your visitors. A complete benchmark touches all four, and the hardware behind them is worth understanding too, which we cover in our guide to enterprise hardware explained.

Why Benchmark Your VPS

The single best reason to benchmark your VPS is trust. Anyone can print an impressive number on a pricing page, but only a test you run on the actual server you were sold can confirm it. Benchmarking also helps you right-size a plan, catch a noisy host before it hurts production, and settle the endless “is provider A really faster than provider B” question with evidence instead of opinion.

It is equally useful after the fact. If your site’s response times drift, a benchmark tells you whether the server changed or your code did. Pairing periodic benchmarks with ongoing observability, such as our Prometheus and Grafana monitoring setup, gives you both a baseline and continuous visibility.

What You Need to Benchmark Your VPS

You need very little to benchmark your VPS properly. Root or sudo access, a clean Debian or Ubuntu VPS with nothing heavy running, and a handful of free tools cover everything in this guide.

  • sysbench — CPU and memory tests
  • Geekbench 6 — cross-platform CPU scores you can share publicly
  • fio — flexible NVMe disk IOPS, throughput and latency testing
  • Ookla speedtest CLI plus ping and mtr — network throughput and latency

Run the tests on an otherwise idle server, and ideally repeat them at a few different times of day. A benchmark taken while your own cron jobs are hammering the disk tells you nothing useful.

How to Benchmark CPU with sysbench

How to benchmark your VPS CPU with sysbench single-core versus multi-core events per second
sysbench reports events-per-second for single and multi-core — single-core is the number that drives WordPress and PHP.

sysbench is the quickest way to get a repeatable CPU figure. It works by finding prime numbers up to a limit, so more primes found per second means a faster processor. Install it and run the single-core test first.

sudo apt update && sudo apt install -y sysbench

# Single-core CPU test
sysbench cpu --cpu-max-prime=20000 --threads=1 run

# Multi-core CPU test (uses all vCPUs)
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

The number to read is events per second. In the single-thread run it reflects per-core speed, which is what most PHP and WordPress requests actually depend on. The multi-thread run scales that across every vCPU and tells you how well the server handles parallel work. Example output (illustrative values only):

CPU speed:
    events per second:  1450.28   # example figure, not a measured result

General statistics:
    total time:         10.0012s
    total number of events: 14506

Higher events per second is faster, full stop. A modern AMD EPYC core with DDR5 memory should post a strong single-core figure and scale cleanly on the multi-core run. If you want the memory bandwidth number too, sysbench covers that as well.

# Memory bandwidth test
sysbench memory --memory-block-size=1M --memory-total-size=20G --threads=$(nproc) run

This reports throughput in MiB/sec. Fast DDR5 memory shows a clearly higher figure than older DDR4 platforms, which matters for object caches like Redis and for read-heavy databases.

How to Run Geekbench on Your VPS

Where sysbench gives you a raw internal figure, Geekbench gives you a standardised, cross-platform score that anyone can compare. This is what makes it so useful for a trust piece: Geekbench 6 uploads every run to a public browser.geekbench.com URL, so you can share proof of a result rather than just asserting it.

Download the Linux tarball, extract it, and run the binary. It needs internet access and a few minutes to complete.

# Replace the version number with the current release from geekbench.com
wget https://cdn.geekbench.com/Geekbench-6.3.0-Linux.tar.gz
tar -xf Geekbench-6.3.0-Linux.tar.gz
cd Geekbench-6.3.0-Linux
./geekbench6

Geekbench produces a Single-Core and a Multi-Core score plus a shareable results link. For WordPress, PHP and most web workloads, the single-core score is the number that matters most, because a typical request is handled by one core at a time. The multi-core score matters more for concurrent traffic and parallel tasks. Save the results URL: it is the cleanest way to compare two providers side by side.

How to Test NVMe Speed with fio

Testing NVMe speed with fio: random read IOPS, sequential throughput and average latency
fio reveals the three NVMe numbers that matter: IOPS for databases, throughput for large files, and low latency for responsiveness.

fio is the industry-standard tool for storage testing, and it is where cheap “SSD” plans and genuine enterprise NVMe part ways. Install it, then run a random read test, which is the pattern that databases and busy CMS sites generate most.

sudo apt install -y fio

# 4K random READ IOPS + latency
fio --name=rr --rw=randread --bs=4k --size=1G --numjobs=4 
    --iodepth=32 --runtime=30 --time_based --direct=1 --group_reporting

# 4K random WRITE IOPS + latency
fio --name=rw --rw=randwrite --bs=4k --size=1G --numjobs=4 
    --iodepth=32 --runtime=30 --time_based --direct=1 --group_reporting

# Sequential throughput (large blocks)
fio --name=seq --rw=read --bs=1M --size=1G --numjobs=1 
    --iodepth=16 --runtime=30 --time_based --direct=1 --group_reporting

Three numbers come out of these runs, and they mean very different things:

  • IOPS — input/output operations per second. This is the headline figure for databases and WooCommerce, where thousands of small reads and writes dominate. High NVMe IOPS is the mark of good storage.
  • Throughput — megabytes per second, reported by the sequential test. It matters for large files: backups, media, big imports.
  • Latency — how long each operation takes, shown by fio as average completion latency (clat) in microseconds or milliseconds. Lower and, crucially, more consistent latency means a more responsive server.

Enterprise NVMe should return very high IOPS with low, tightly consistent latency, while a slow or oversold disk shows modest IOPS and latency that spikes under load. If you want to see how much this gap matters in practice, our NVMe vs SSD real benchmark breaks it down for real WordPress and WooCommerce workloads. One safety note: keep the --size value modest so the test file never fills the disk, and delete the fio test files when you are done.

How to Measure Network and Latency

Network testing has two halves: how much bandwidth you have, and how quickly packets travel. The Ookla speedtest CLI covers bandwidth and reports idle latency alongside it.

# Install the official Ookla CLI (see speedtest.net for the repo steps)
speedtest

# Round-trip latency to a UK target
ping -c 5 bbc.co.uk

# Full path and per-hop latency
mtr -rw bbc.co.uk

The speedtest run gives you Download and Upload in Mbps or Gbps plus an idle latency figure. ping returns round-trip time to a London-area target such as bbc.co.uk, and mtr shows the full route hop by hop so you can spot where delay creeps in.

For a UK audience, latency from London is often more important than raw bandwidth. A server physically in the UK with a well-peered network answers a British visitor in single-digit to low double-digit milliseconds, and that responsiveness feeds directly into your time to first byte, as covered in our sub-100ms TTFB guide.

Interpret and Compare Your Results

Mapping benchmark metrics to workloads and comparing VPS providers fairly
Match each metric to your workload — and compare fairly: benchmark the real VPS, run it three times, and watch CPU steal time.

Raw numbers only help once you map them to the workload you actually run. Use this table to decide which metric to weight most heavily.

MetricToolMatters most for
Single-core CPU scoresysbench / Geekbench 6WordPress, PHP, Laravel, game servers
Multi-core CPU scoresysbench / Geekbench 6Build servers, parallel and concurrent workloads
Memory bandwidth (MiB/s)sysbenchRedis, caches, in-memory databases
NVMe IOPS + latencyfioDatabases, WooCommerce, busy CMS sites
Sequential throughput (MB/s)fioBackups, media, large imports
Network latency (ms)ping / mtr / speedtestUK visitor responsiveness and TTFB

So a WordPress or Laravel buyer should care most about single-core CPU and NVMe latency. A team running database-heavy or WooCommerce workloads should weight NVMe IOPS and memory bandwidth. If your CPU choice is still open, our comparison of AMD EPYC vs Intel Xeon explains why per-core performance often beats raw core count for web hosting, and your database choice interacts with those disk numbers too.

Best Practices for Fair Benchmarks

A benchmark is only as honest as its method, and this is where the trust angle lives. Follow these rules and your results will hold up to scrutiny; ignore them and you are just generating noise.

  • Test the real VPS, not the host. Benchmark the actual server you were sold, not a provider’s marketing figures or the bare-metal host it sits on.
  • Run each test at least three times and take the median. A single run can catch a lucky or unlucky moment; the median smooths that out.
  • Test at different times of day. A shared host that is quiet at 3am can be busy at peak, and only varied timing reveals it.
  • Watch CPU steal time. Check the st column in top or vmstat 1. High CPU steal time means the hypervisor is making you wait for a core, a classic sign of a noisy neighbour or an oversold host.
  • Keep the configuration identical. When comparing providers, match the OS, kernel, tool versions and test parameters exactly, or you are comparing apples with oranges.
  • Do not fill the disk. Use bounded fio test files and clean them up afterwards so you never risk the server or skew the result.
# Watch CPU steal time live (the 'st' column)
vmstat 1

# Or check the %st field in top's CPU line
top

Once you have a clean method, the comparison becomes genuinely useful. Run these same tests on a UK Speed VPS and compare: the AMD EPYC CPUs, DDR5 memory and enterprise NVMe are exactly the components these benchmarks are designed to expose, and the whole point of this guide is that you can verify it rather than take our word for it.

Conclusion

Benchmarking is the difference between believing a performance claim and proving one. With sysbench, Geekbench 6, fio and a couple of network tools, you can measure every dimension that matters and compare providers on equal, reproducible terms. The numbers only mean something when the method is fair, so run each test more than once, watch for steal time, and always test the server you actually pay for.

If you want a confident baseline to measure against, run these tests on a UK Speed VPS and compare the results with whatever you are using today.

  • Install sysbench, fio and the Ookla CLI on a clean VPS.
  • Record single-core CPU, NVMe IOPS and latency, and London round-trip latency.
  • Run each test three times and keep the median.
  • Save your Geekbench 6 results URL so you can compare providers openly.
Share this article:
↑
1
Powered by Joinchat