High performance is not a specification, it is an adjective, and the only way to know whether a VPS deserves it is to run four benchmarks on a trial instance before you migrate anything onto it.
The specification sheet cannot tell you. Two providers advertising four vCPUs, 8GB of RAM and NVMe storage can differ by a factor of three in real throughput, because the specification does not say whether the cores are yours, whether the disk is throttled after a burst, or how oversubscribed the host is.
The good news is that testing takes about twenty minutes and costs the price of one month on a small instance, which is less than the time you will spend arguing about whether the application is slow.
Table of contents
- Start with steal time, because it invalidates everything else
- CPU: single-core matters more than the core count
- Disk: the burst that runs out
- Network: throughput, latency and where the users are
- A representative test beats a synthetic one
- When the answer is that you do not want a server
- How this fits the rest of the stack
- FAQ
Start with steal time, because it invalidates everything else
Before any benchmark, check whether you are getting the CPU you paid for. Steal time is the percentage of time your virtual CPU was ready to run and the hypervisor scheduled a different tenant instead.
# Install if needed: sysstat on most distributions.
vmstat 1 10
mpstat -P ALL 2 10Read the st column. Under 1% is healthy. Between 1% and 5% is a busy host you will occasionally notice. Sustained above 10% means the machine is oversubscribed and no benchmark you run afterwards is measuring your capacity, it is measuring the gap left by your neighbours.
Check it more than once, and at different times of day. Contention is bursty, and a Tuesday morning reading tells you nothing about Saturday night.
If steal time is high on a trial instance, stop there. You have your answer and the rest of the testing is beside the point.
CPU: single-core matters more than the core count
Most web application work is a request handled by one thread. That means single-core performance sets your latency, and the core count only sets how many requests you can handle at once.
A quick, dependency-free single-core check:
# Prime sieve, single thread. Lower is better.
time openssl speed -evp aes-256-gcm 2>/dev/null | tail -3
# Or with sysbench, which reports a clean events-per-second figure.
sysbench cpu --cpu-max-prime=20000 --threads=1 runThen run the same test with threads equal to your vCPU count. On a dedicated-core plan, throughput should scale close to linearly. On a shared plan it will not, and the gap between the two is the practical measure of what you actually bought.
Also read the processor model, because generations differ substantially:
lscpu | grep -E 'Model name|MHz|Socket|Core|Thread'A provider running current-generation server processors and one running hardware from several years ago will both advertise four vCPUs. The per-core difference between them is real and it is not on the pricing page.
Disk: the burst that runs out
Disk is where most VPS performance disappointment lives, especially under a database. The number that matters is random read and write IOPS at small block sizes, and whether that number is sustained.
# Random read, 4k blocks. Note both IOPS and the 99th percentile latency.
fio --name=randread --ioengine=libaio --direct=1 --bs=4k \
--iodepth=32 --size=2G --readwrite=randread --runtime=60 --time_based
# Random write matters more for a database write path.
fio --name=randwrite --ioengine=libaio --direct=1 --bs=4k \
--iodepth=32 --size=2G --readwrite=randwrite --runtime=60 --time_basedThe trick is the runtime. Run for 60 seconds and again for 10 minutes. If the ten-minute figure is dramatically lower, you have found a burst allowance that decays, which is the disk equivalent of burstable CPU and produces exactly the same nasty surprise a week after launch.
Watch the 99th percentile latency as much as the IOPS average. A disk that averages well but has a long tail produces intermittent slow queries that are miserable to diagnose, because the average on every dashboard looks fine.
Network: throughput, latency and where the users are
Two separate things get called network performance and only one of them is under the provider’s control.
Throughput is the port speed and whether it is shared. Test it against a known-good endpoint:
iperf3 -c <a public iperf server> -t 30
# And in the other direction:
iperf3 -c <a public iperf server> -t 30 -RLatency to your users is geography, and it is the number that actually shows up in page load times. Ping from where your audience is, not from your laptop:
mtr --report --report-cycles 50 your-server-ipThe report shows per-hop latency and packet loss, which distinguishes a genuinely distant server from one with a bad route. A provider with a datacentre near your users but poor peering can be slower than a more distant one with good transit, and only a traceroute will tell you which you have.
A representative test beats a synthetic one
Benchmarks establish the ceiling. What you actually care about is whether your application is fast on this hardware, and those are different questions.
Deploy something close to real: your actual application, a database with a realistic data volume, and a load generator producing traffic that resembles your traffic. Then watch the numbers that matter to a user.
# A simple sustained load, reporting the latency distribution.
wrk -t4 -c100 -d5m --latency https://your-trial-host/some/real/pathRead the 99th percentile rather than the mean. Averages hide precisely the behaviour that makes users complain, and the tail is where oversubscription and disk throttling show up first.
Run it for at least five minutes, ideally longer. Short tests live entirely inside every burst allowance the provider offers, which is why a quick test so often looks great and the production experience does not.
When the answer is that you do not want a server
There is a version of this exercise where you do the benchmarks, find a genuinely fast machine, and then spend the next year patching it, renewing its certificates, rotating its logs and rebuilding it after a failure. The hardware was never the expensive part.
It is worth asking what you are buying the raw performance for. If the answer is a workload with a specific hardware need, a VPS is right and the tests above are how you pick one. If the answer is a web application and a database, the performance question is largely a plan-size question and the interesting variable is how much operational work comes attached.
On RunxBuild the ladder runs from a $4 Dev plan through to larger plans with more vCPU and RAM, with autoscaling between a floor and a ceiling you choose, and the patching, certificates and deploy history come with it rather than as separate work. The services documentation covers the supported runtimes.
How this fits the rest of the stack
Performance testing tells you what a machine can do; it does not tell you what the whole stack will cost once the database, the storage, the backups and the egress are included, and that total is usually the number that decides things. The RunxBuild hosting calculator puts those line items together so you can compare a managed shape against a self-managed one on the same basis rather than on instance price alone.
Useful related references:
- High-Performance On-Premises S3 Storage Platforms: MinIO, Ceph, and SeaweedFS
- VPS SSD Storage: What You’re Actually Getting, When It Matters, When It Doesn’t
- Can Cloudways Host Next.js Server-Side Rendering: A Managed VPS Can Host Anything If You Operate It, but the Real Question Is Whether You Should
- Services on RunxBuild
FAQ
What actually makes a VPS high performance?
Dedicated rather than shared CPU cores, current-generation processors, local NVMe storage with sustained rather than burst IOPS, and a network with good peering to your users. The specification sheet covers none of those directly, which is why measurement on a trial instance is the only reliable answer.
How do I check if my VPS is oversubscribed?
Watch steal time with vmstat or mpstat over several minutes and at different times of day. The st column shows the percentage of time your vCPU was ready to run but the hypervisor scheduled another tenant. Sustained double digits means contention no application tuning will fix.
Why is my VPS fast in benchmarks but slow in production?
Usually a burst allowance running out. Short benchmarks fit entirely inside the burst window for CPU and disk, so they measure the peak rather than the sustained rate. Rerun the same test for ten minutes or more and compare against the sixty-second figure.
Does more RAM make a server faster?
Only if you were short of it. RAM does not speed up a machine with headroom to spare; it prevents swapping and lets the operating system cache more of your working set on disk. If your database working set fits in memory, adding more changes nothing measurable.
Is NVMe always faster than SSD on a VPS?
Local NVMe is generally faster than network-attached SSD, but the provider’s throttling policy matters more than the underlying technology. A throttled NVMe volume can be slower in sustained use than an unthrottled network SSD. Measure sustained IOPS rather than trusting the storage label.